-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
8
-
By default, JCMA only migrates the filters of single-project Agile boards, and the quick filters from those boards. But it can also migrate all filters & boards, if some dark features are active.
Some applications also need to migrate many JQL queries.
The transformation rules should be exactly the same as those JCMA already does. (In general, this involves mapping custom field ids in references such as “cf[12345]”, option IDs in clauses, and—most importantly—users into account IDs.) It is nearly impossible for app vendors to re-implement all of this correctly, and the functionality already exists in JCMA.
This REST endpoint
is only relevant for converting Cloud to Cloud JQL, and may cause errors if display names are different and do not match.
Consider the following example:
On the source Jira server instance, there is a user with the display name John Doe, the username jdoe, and the email address jdoe@example.com.
The same user has an Atlassian account with the same email address, but with the display name Jonny D. and the account ID 123-456-789.
Note that the username is server-only, the account ID is cloud-only, and the display names are different. The email is the same, and JCMA uses this to map the server user to the cloud account.
On the server, there can be JQL queries like assignee = "John Doe" or reporter = jdoe. (These are very common, because of how autocomplete works on Jira server.) During migrations, we want these to be mapped to assignee = 123-456-789 and reporter = 123-456-789.
To clarify, JCMA already does this if the JQL query is part of a Jira saved filter.
We already have 2 similar Suggestions but of limited feature set
MIG-809JCMA does not update custom field names in migrated filters
- MIG-315 Create an API to convert user references stored in JQL to AAID during the migration