In our Connect descriptor we have modules jiraIssuFields. e.g.
"jiraIssueFields": [
{
"key": "fieldname",
"name": {
"value": "Field Name"
},
"description": {
"value": "Created by App."
},
"type": "single_select"
}
These fields are by the system locked in connect and are deleted when user uninstalls the app.
Now in Forge we do not use anymore fields, thus few questions arise that perhaps Atlassian could answer:
- Can we just forget the entries from manifest if we jump from descriptor to manifest? (data is migrated separately by scheduler and placed into Forge storage thus the fields ill be mainly to keep history).
- What happens then with the app created fields? We’d like not to delete these from the system cause history is there in these fields.
- Or can we somehow make these connect fields unlocked before actual migration?
One option is to migrate these fields by the book, but would like to take as little waste as possible to Forge.
best,
Margus
Hi Margus,
You don’t drop them, you rewrite them. Each jiraIssueFields entry comes out of connectModules and goes back under modules as a jira:customField with the same key plus migratedFromConnect: true. That flag has to be set before you deploy, otherwise Forge can’t map the new entry to the original Connect field and the app “will fail to migrate data from the corresponding Connect issue field”. The field name doesn’t change.
Your example is single_select, which costs the most to move. No direct Forge equivalent, so it becomes an object field and your app owns the select UI. Two things your customers will see: setting a value used to take a bare option id and now needs {"id": 5} at minimum, and = doesn’t work on the root field any more, so customfield_10010 = "Apple" becomes customfield_10010.value = "Apple". Saved filters using the old form break. A parser expression covers the payload change, the JQL one you can’t hide.
What I couldn’t find written down is your actual question: what happens to the field if you take the module out and put nothing back. It isn’t on the issue field page, the Forge custom field page, or the adopting-forge set. I’d want that confirmed by Atlassian before dropping anything that holds history.
Has anyone had a straight answer on that?
Im also hoping Atlassian to say something about what will happen before I start testing it in dev. Would not want to waste dev environment if it breaks something really bad.
But all in all I do not need anymore connect custom fields and do not want to add forge customfield into manifest, thus question to Atlassian - what happens with modules (specifically fields - cause these are not just configuration but also contain user data) that are just removed from connectModules and not added back to forge modules.
br,
Margus
@WendyG @rmassaioli can anybody provide some information about the usecase we have up here?
br,
SoftComply
Hi @margus.nael,
Still not written down. I went back through the issue-field migration page today and it does not cover removing a module without re-declaring it, and it does not state the uninstall behaviour for app-created fields either. The question to Atlassian stands.
One line on that page matters before testing in dev though. “Once a module is migrated to Forge, it cannot be migrated back to Connect. Doing so is not supported and can result in undefined behaviour.” That is about the forward path rather than about dropping a field, but a migrated dev instance is not cheaply reversible.
Still watching this one.
@PhilShakhovskoy @tpettersen @ScottGangemi @rmassaioli @JoshuaTang @WendyG
Anybody comments ?!? to undocumented area before we start breaking things and causing lot of unneeded effort for both sides!
Margus
SoftComply
@PhilShakhovskoy @tpettersen @ScottGangemi @rmassaioli @JoshuaTang @WendyG
anyone? This topic will automatically close in 10 days. Do I need to send reminder every day or need to escalate it to linkedin? What happed to “all the support you need” for this migration?!?
Hi Margus,
Have you tried submitting a ticket to Developer Support?
Obviously, it would have been ideal for Atlassian to answer your question here, where everyone would benefit. But after three weeks without a response, that feels unlikely. An “Ecosystem Support Request” might be more successful. (If you haven’t tried that already.)
Heve not tried that because in documentation it says explicitly contact us here.
I am not a fan of dev support either, cause usually it takes so much energy to get the actual answer there. First they bounce all the tickets back ten times and you need to switch to caps lock and say same thing 10 times before somebody actually reads it.
The best course of action would be to raise an ecosystem support ticket for this.
I will also ask my team to review this thread but they will look for the ticket number. Sonif you could provide it here to connect the dots that would be great.