Hi there,
As a follow-up to this topic, I’ve created this one to discuss with other developers and Atlassian staff about the impact of some scoped entities of next-gen projects like the Agility project.
Since the last weeks we are investigating some strange situations on Xporter for Jira Cloud related with “duplicated” issue types and role names when asking for Jira Issue Types and Project Roles.
Till now, looking on how the REST API design, it looked like those entity names were unique. Although, that’s not the case since Agility projects wildly appeared 
After reading the topic I mentioned before, I noticed that no one mentioned problems with Roles or any plan about changes on this entity. When an Agility Project is created, 4 new roles will be created exclusively for each project.
- Administrator
- Member
- Viewer
- atlassian-addons-project-access
This means the same “problem” will occur like the IssueTypes, Custom Fields and Statuses. When asking for Jira Project Roles we will get Roles with duplicated names.
How can this impact our apps? I will briefly explain our case. On Xporter for Jira Cloud we implemented our own Permission Schemes with the ability to define which issue types, roles and groups could export data from Jira Cloud.
Right now, we display n duplicated issue types and roles too, what causes some confusion to our users, due we don’t have any information that the Story issue type is related with a specific project. But that’s not the worst problem because our logic we used the role name as unique.
We were using /rest/api/2/project/<projectIdOrKey>/role in order to get the roles that are being used for each project. It returned the role name and the self url, so we used the role name to get the role id by searching on the Jira Project roles /rest/api/2/role. We needed to get the role actors for each project and we started getting some “404 - Not Found” errors because we provided the wrong role id (Wrong match on role names 
).
Of course we could parse the self url and we could get the role id easily, but it was something that we really didn’t expect.
After explaining this problem on the Atlassian Ecosystem Service Desk, Anne Calantog suggested to start using this (new?) endpoint /rest/api/2/project/<projectIdOrKey>/roledetails. We will get the same data format as we have on /rest/api/2/role.
Although, we are still searching for the best way to fit out permission schemes (in our case of course) on the next-gen projects. Also, it would be very important to receive some answers to this questions.
- Is there any date for rolling out the changes on the REST APIs related with retrieve project roles, issue types and other entities by project scope?
- There is an Atlassian Connect conditional called “entity_property_contains_any_user_role” that uses the role key or name stored on jira properties. Shouldn’t the role name be deprecated on this condition?
I’m sorry if I’ve missed something on this topic, but it’s something that can have impact so much things in a different way.
Please, be kind and complete this one with the problems you are facing or questions. Thank you
Kind regards,
Paulo Alves.
