-
Bug
-
Resolution: Fixed
-
Low
-
None
-
5
-
Severity 3 - Minor
-
1
-
Issue Summary
When using the Rest API endpoint https://YOUR_INSTANCE.atlassian.net/rest/api/3/issuetype, all issue types with the scope information are used on Next-Gen projects, for example:
self: "https://YOUR_INSTANCE.atlassian.net/rest/api/3/issuetype/10156", id: "10156", description: "", iconUrl: "https://YOUR_INSTANCE.atlassian.net/secure/viewavatar?size=medium&avatarId=10321&avatarType=issuetype", name: "IssueTypeTest", untranslatedName: "IssueTypeTest", subtask: false, avatarId: 10321, scope: { type: "PROJECT", project: { id: "10144" } }
Once you move that Next-gen project to the trash, all issue types from that project are shown without the scope under them. This creates bias information, where the customer could get duplicated issue type names without knowing which one is from Classic projects.
Steps to Reproduce
- Create a Classic Issue type (example: IssueTypeTest)
- Create an Issue type with the same name on a Next-gen project
- Run the Rest API call to see the difference between them (the scope value): https://YOUR_INSTANCE.atlassian.net/rest/api/3/issuetype
- Move this Next-gen project to the trash
- Run the endpoint for step 3 again.
There is no direct way of knowing what is the Classic field
Expected Results
You can't fetch Issue types from Next-gen project that are on the trash.
Actual Results
You fetch Issue types that seem to be from Classic, but they aren't foundable on the UI.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available
- mentioned in
-
Page Loading...
[JRACLOUD-75176] Rest API shows Issue Types without scope for Next-gen projects moved to trash
This is a blocker for us - we cannot have any reliable automation around creating/re-using existing issue types, because if we match by name we get more than one issue type and if we use the wrong one (from a next-gen project), we'll get:
Cannot assign next-gen issue types to a classic project scheme: XXXXX.
For sake of consistency, I think the solution should be to either keep the scope while the project is still in the Trash OR the REST API should not return such issue types at all.
Thanks!
Petar P.
One solution would be to have the response differentiate 'vestigial' issue types from 'active' ones. For added goodness, provide a query parameter to return only active issue types.
On our App's settings page, we let the user select an issue type. Since there's no way to differentiate between active issue types and these vestigial issue types, the list of issue types that appear on our settings page does not match the list of issue types that appear on Jira's own issue types page.
Got bad issues with duplicated issue types when Next-Gen project was sitting in Trash. Only permanently deleting that project allowed me to continue use my instance.
The bug is affecting existing configurations that were working and it is hard to fix tons of configs just to overcome it, we decided to better lose all the data from trashed project than block the instance functionality.
This affects a plug-in our client is using (Exalate) and makes our configuration much less flexible since the workaround is to actually map issue types to their corresponding ID in Jira.
What was the fix?