Working with project roles effectively

[Konrad Garus]

I'm building an add-on that has some functionality crossing multiple projects, without necessarily specifying the projects upfront. For example a user may enter any JQL they like, and then we use it to query JIRA and do something with the data.

Now, I need to implement role-based authorization. For example, let the administrator say that the query needs to be further narrowed down to "Developers". When Jimmy uses the addon, he should only see issues that match the JQL, and only for projects where Jimmy is a Developer.

How can I achieve it?

First, I need to show a list of roles to the administrator. It means my read-only add-on has to request full ADMIN scope in order to GET /roles (ACJIRA-424, 8 months old now). It sure sounds bad for an add-on to claim it only wants to read data from your JIRA, but then ask for full ADMIN scope. Another way is to loop over all projects with GET /project/XXX - but that means 100 API calls for a client with 100 projects!

Second, I need to know in what projects a user has the configured role. There doesn't seem to be an API call for it. Pulling this data means looping over /project/XXX/role/YYY - that is 100*10 API calls for a client with 100 projects and 10 roles.

To make things worse, there don't seem to be any webhooks for project-role assignment. It means I either blindly make numerous API calls frequently to discover the updates, or do it less frequently at the cost of showing stale data to my users.

Am I not seeing something? Are there better ways to achieve it?

https://ecosystem.atlassian.net/browse/ACJIRA-424

[Robert Massaioli _Atlassian_]

When Jimmy uses the addon, he should only see issues that match the JQL, and only for projects where Jimmy is a Developer.

I think that the fundamental problem here is that you really want to perform JQL searches that are restricted by a role. We have an open issue for that in the JIRA backlog: https://jira.atlassian.com/browse/JRA-11611

Second, I need to know in what projects a user has the configured role. There doesn't seem to be an API call for it. Pulling this data means looping over /project/XXX/role/YYY - that is 100*10 API calls for a client with 100 projects and 10 roles.

I think this is valid, as a result I have raised the following issue: https://jira.atlassian.com/browse/JRA-59679

To make things worse, there don't seem to be any webhooks for project-role assignment.

I'm not entirely sure why you want this? Can you please explain it in more detail here: https://ecosystem.atlassian.net/browse/ACJIRA-811

I know that this does not answer your questions fully but, if we discuss more in those issues then we may be able to prioritize those in the future.

[Konrad Garus]

Thank you so much for the answer.

It may be worthwhile to add some background:

• I want users to be able to configure a query that possibly spans 100 or 5,000 issues.
• Then I want to pull these issues and do some transformations on them.
• Then I want every logged in user to see just the issues he is authorized for. Jimmy may see 150 of the 5,000 issues, Jack 200 (of which some may overlap with Jimmy), and so on.

That is a lot computation to happen in real time when someone loads the page. Query JIRA in a loop to pull all the query results for the user (by the way, server cannot impersonate user in any way right?), then do the transformations... Every time anyone loads the page.

Doesn't seem like a good thing, neither for us, nor for Atlassian. So we wanted to extract the query once (perhaps every hour?), then present the results ready for consumption to addon users.

As it is now, the choice seems to be:

• Pull project/role assignments and do the authorization on our end (webhook would help here so we don't pull projects too often, because it takes PROJECTS*ROLES API calls).
• Query live from the client side (way too slow/unresponsive/bad UX for our use case).

[Robert Massaioli _Atlassian_]

In your use case you are doing a lot of data processing, so client side is clearly not an option. However, I still think that, were those issues to be solved, your use case would be much easier to accomplish.

However, for now, I would reccomend your pull approach and try and make it work as best as you can. Please consider even using entity properties and jql search on entity properties to get the issues / data that you need.

Documentation on entity properties: https://developer.atlassian.com/static/connect/docs/latest/concepts/hosted-data-storage.html