Getting the current user in a Forge JQL function

Dear Community,

It seems to me that it is only possible to request the Jira API from a JQL function with asApp(), not with asUser() (the latter results in an HTTP 401). This means that I cannot use /rest/api/3/myself for getting the ID of the user executing the JQL function, as this returns the technical user of the Forge app.

Is there any way to get at least the ID of the currently logged in user in a JQL function context?

The use case would be the following: I have a JQL function, one of its parameters is a User. As such, it would be convenient to be able to use nested queries that resolve to a User - most obviously “currentUser()”. Even if we cannot execute an entire JQL user clause from a user context, manually checking whether “currentUser()” was entered in place of the User argument, would immensely improve the function’s usability.

Now that I think of it a bit more… it seems to me that since Jira’s JQL function precomputation cache does not store the executing user as a key: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-jql-functions--apps-#api-rest-api-3-jql-function-computation-post , this architecture doesn’t allow for any JQL function which produces different results depending on the user context. I’m afraid this pretty much answers my question. This means, however, that there is an inconsistency between complete JQL queries and (Forge) JQL functions, since the former can produce user-dependent results, while the latter cannot. Does anybody know a workaround?

1 Like

Does calling useProductContext() work from there? https://developer.atlassian.com/platform/forge/ui-kit-hooks-reference/#useproductcontext

I’m on mobile and can’t test this right now. It may not work.

Hello Robert,

Unfortunately it doesn’t work, the returned product context in a JQL function is an empty object.

Hi @PeterVelosy,

As you already mentioned in your initial post, precomputations are stored in the global context. It means that there is no user information next to the precomputation record stored in a database. Also, precomputation is shared between users for the same function call (the same field, operator, and arguments). This was a design decision to limit the number of existing precomputations.

One of the possible solutions would be returning more general results from your function and letting the JQL engine return user-dependent results based on the transformed query after function processing resolves.

Best regards,
Łukasz