Dropping Connect cutomfields while migrating to Forge

Forge Adopting Forge from Connect
1

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

2

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?

3

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

4

@WendyG @rmassaioli can anybody provide some information about the usecase we have up here?

br,

SoftComply

5

any updates?