We would like to use the recently added JQL custom functions feature. However, we have 2 concerns:
It looks like the architecture precomputations does not account for different user IDs. In our case (I’m working in Structure by Tempo) structure(structureID) should not return any issues for users who do not have access to the structure identified by structureID. However, the precomputation results seem to be shared across multiple users. Is it possible to have the ability to specify access to the function with the specific argument for the user?
Another concern: “There is a limit of 1,000 right-hand side values in the JQL fragment returned by custom functions.” — It could be a very valuable feature for our larger customers, but this limit would make this feature impossible to use for cross-company overview. Can we have an option to raise that limit for large customers?
Precomputations are stored in the global context, which means that for the given field/operator/arguments, there is a single precomputation stored. If we allowed to store precomputation in the user context, it would significantly increase the number of precomputations, which later may be problematic to keep up to date by an app.
structure(structureID) should not return any issues for users who don’t have access to the structure identified by structureID
The JQL search engine later processes results returned by the function. It includes the step of applying permission check - even if the function returns issues that the user doesn’t have access to, they will be later filtered out in the final query results.
Unfortunately, currently, there is no option to raise this limit. Would it be possible to pass additional arguments to your function to narrow results down or introduce some pagination to your function?
Re. 1. Checking issue access is not an option, because we need to check the access to the container of said issues. An issue, which is visible to the user, and that belongs to a structure that the user has no access to, must not be returned for security reasons.
If we allowed to store precomputation in the user context, it would significantly increase the number of precomputations, which later may be problematic to keep up to date by an app.
Do you mean that it would be hard to track on Jira side or on the app side? As for the app side, I see how we can do it, and the cost of this solution seems to be justified by the benefit it can bring to the end users.
Would it be possible to pass additional arguments to your function to narrow results down or introduce some pagination to your function?
Could you explain how pagination would work? You mean something like “LIMIT 1000” to see only the first 1000 results? Or is there an ability to send precomputations in chunks?
Re. 1. Checking issue access is not an option, because we need to check the access to the container of said issues. An issue, which is visible to the user, and that belongs to a structure that the user has no access to, must not be returned for security reasons.
Ok, got it. Have you considered returning a JQL fragment from your function that will be later dynamically processed by the JQL search engine? For instance:
issue.structure.id = id AND issue.structure_[id].allowedUsers = currentUser()
Of course, this is just an example since I don’t know how your structures are implemented, but the above snippet uses data stored in issue properties to determine if a user can see the issue. My main point is that the JQL function doesn’t need to return a list of issue keys. The result may be just a JQL fragment that the JQL engine will further process.
Do you think that such approach would be suitable for you?
Do you mean that it would be hard to track on Jira side or on the app side? As for the app side, I see how we can do it, and the cost of this solution seems to be justified by the benefit it can bring to the end users.
We have considered both Jira and app perspectives. Having precomputation for user context may introduce performance problems on the Jira side. At the same time, we are concerned that apps may be overwhelmed by the number of records that should be refreshed.
Could you explain how pagination would work? You mean something like “LIMIT 1000” to see only the first 1000 results? Or is there an ability to send precomputations in chunks?
I was thinking about passing an additional argument to the function to return subsequent pages if there are more than 1000 results.
The idea with the JQL fragment would work if we could specify constraints on the current user. But the permission model that we have is similar to Filters in Jira: we can allow access to groups and project roles, so “allowedUsers” issue properties wouldn’t work.
Having precomputation for user context may introduce performance problems on the Jira side.
We were thinking about reducing the update frequency to avoid making too many precomputation updates to maybe once in 5-15min. Do you think it could work?
At the same time, we are concerned that apps may be overwhelmed by the number of records that should be refreshed.
I think that our app will be able to handle this.
Could you explain how pagination would work? You mean something like “LIMIT 1000” to see only the first 1000 results? Or is there an ability to send precomputations in chunks?
I was thinking about passing an additional argument to the function to return subsequent pages if there are more than 1000 results.
I see. Does it mean that the user will need to “paginate” manually? Meaning, issue in structure("Foo", 1) OR issue in structure("Foo", 2) OR ... OR issue in structure("Foo", <n>)? I’m afraid that this wouldn’t work from the user experience standpoint. Also, if the users went all the way to specify 100-300 such clauses, then the end result would be the same as with a larger threshold, but with more precomputations.
As for larger limits — I don’t think that many customers would require that, so maybe it could be an option for larger customers?
The idea with the JQL fragment would work if we could specify constraints on the current user. But the permission model that we have is similar to Filters in Jira: we can allow access to groups and project roles, so “allowedUsers” issue properties wouldn’t work.
Ok, I see. Would it be possible to index some additional data based on your current permission model so it would be possible to create a proper JQL fragment that will be later correctly processed by the JQL search engine? It could be, for example, something like project roles stored in project properties.
We were thinking about reducing the update frequency to avoid making too many precomputation updates to maybe once in 5-15min. Do you think it could work?
To clarify, our concern is also about the size of precomputation storage on the Jira side. Precomputations stored per user context may cause significant growth of that storage, leading to performance degradation (especially for larger customers). Therefore, we decided not to allow to store precomputations per user.
I’m aware that there might be scenarios particularly challenging because of that limitation, but currently, we don’t offer an option for an app to change this behavior.
Regarding pagination and the limit of 1000 results returned by the function - it’s important to mention that, in general there is a limit in JQL search, which doesn’t return more than 1000 results. We decided to align the JQL function’s specification to that limit.
In general, we suggest to limit the number of returned results by passing additional arguments to the function.
Would it be possible for you to build the prototype based on the current shape of JQL functions, even if it doesn’t fulfill 100% of your requirements? We really appreciate your feedback, but currently, we are not planning to change the precomputation’s specification or the limit of the number of results. I will share this discussion with my team, but I can’t promise anything at this point.
It could be, for example, something like project roles stored in project properties.
I’m trying to wrap my head around this… Do you mean that if someone updates structure #42 to allow access to a project role R in project P, our app will add the following property to project P: allowedForStructure_42 = [R]? But what would the JQL fragment be like? There is no currentUserRoles() as far as I can tell. It would really help if we could make conditions on the current user in the query itself, but it’s not possible.
Even if our permission model was purely user-based (i.e. access is limited to specific users), consider a structure that contains issue A and is visible only to user U. U doesn’t have any relation to issue A. What would be the indexed value / JQL fragment that would work for U but not for another user V? I think that it’s impossible, because a JQL fragment expresses a condition on issues, so we can’t say “check if current user is U”, it can only check that some property of A or its project has U. But, again, U might have no relation to A or its project.
To clarify, our concern is also about the size of precomputation storage on the Jira side.
I understand. Do you think the LRU approach would work? This will mean that some queries might be slower, but this is the tradeoff.
Would it be possible for you to build the prototype based on the current shape of JQL functions, even if it doesn’t fulfill 100% of your requirements?
We are considering with our product team whether to implement this feature at all, given the constraints. With your help (thank you!), I’m trying to figure out if some of them can be worked around.
Do you think the LRU approach would work? This will mean that some queries might be slower, but this is the tradeoff.
Thank you for the suggestion! We will gather feedback and different ideas on how to improve the current design and discuss it with the team. Unfortunately, as I mentioned, I can’t promise anything now.
If you have any further questions, don’t hesitate to use this thread to contact us.