Hello!
We’re migrating our Connect app to Forge and have run into an issue with the jiraServiceManagement:portalRequestCreatePropertyPanel module.
With Connect, when we serialize properties using AP.jiraServiceDesk.RequestProperties().serialize(), the properties are stored directly under a key we control, like appData in the following example. Our customers rely on this in their Jira automations using Smart Values such as:{{issue.properties.appData.category.name}}
We have also documented these paths in our product documentation.
With Forge, using view.submit(), the properties are stored under the app’s UUID instead. So instead of:
{
"appData": {
"category": { "name": "Hardware", "id": 42 }
}
}
We get:
{
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx": {
"appData": {
"value": {
"category": { "name": "Hardware", "id": 42 }
}
}
}
}
This breaks all existing automations that use the Smart Values we’ve documented.
I tried creating entity property aliases via jira:jiraEntityProperties extractions, which do work for JQL searches, but the aliases don’t appear to work as Smart Values in automations.
Asking customers to update their automations isn’t really an option for us, since many have built workflows around these property paths.
Is there a way to configure Forge to store issue properties with a custom key, the same way Connect does?
Thank you!
Rodrigo