Authorize API from function called by async event queue

Forge Forge Platform and Tools
1

I’m trying to use the authorize API from within a function that was called by an async event queue. The authorize function works just fine a synchronize resolver function. The overall goal is to make sure the user has view permissions on a set of issues returned by a jql query. Running the JQL query in the original synchronous resolver is sub-optimal b/c the query result may be several thousand issues and there’s downstream processing that must occur, which is why I’m using an asynchronous event queue to do the processing.

Here’s the code

const response = await authorize().onJira([{
        permissions: ['BROWSE_PROJECTS'],
        issues: batchIds
      }]);

The exception is

PROXY_ERR: Forge platform failed to process runtime HTTP request - 401 - AUTH_TYPE_UNAVAILABLE
    at handleProxyResponseErrors (webpack://jira-dashboard-gadget-custom-ui/node_modules/@forge/api/out/api/fetch.js:83:1)
    at <anonymous> (webpack://jira-dashboard-gadget-custom-ui/node_modules/@forge/api/out/api/fetch.js:28:1)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  status: 401,
  errorCode: 'AUTH_TYPE_UNAVAILABLE'

I have also tried calling the below

const requestBody = {
          accountId: userAccountId,
          projectPermissions: [{
            permissions: ["BROWSE_PROJECTS"],
            issues: batchIds,
            projects: [10039]
          }]
        };
        
        this.logger.info('Permission check request body:', JSON.stringify(requestBody, null, 2));

        const response = await api.asUser().requestJira(route`/rest/api/3/permissions/check`, {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json'
          },
          body: JSON.stringify(requestBody)
        });

        const result = await response.json();
        this.logger.info(`Permission check response status: ${response.status} ${JSON.stringify(result, null, 2)}`);

        if (!response.ok) {
          this.logger.error(`Permission check failed with status: ${response.status}`);
          return false;
        }

This call only runs when you use asUser. It will not work with asApp irrespective of whether it’s called from a synchronous resolver or an async resolver. You cannot seem to use asUser within an async event resolver either.

Suggestions?

2

That is correct. Refer to FRGE-805 and also watch ROADMAP-48

Also refer to this forum thread where the topic was last discussed.

Suggestions?

Well, since the Get bulk permissions endpoint will only ever return 1,000 results in a single search, you’ll just have do multiple, sequential requests to get those “several thousand issues” that you’ll have to process thereafter.

Why not just start with a more specific search that represents a set of Issues the user needs to view for a particular context or scenario… which will return a much smaller dataset?

3

Thanks for directing me to those links! Super helpful. The /rest/api/3/permissions/check only works in the asUser context and does not work in the asApp context, so my only choice is to make these calls up front during the synchronous call, but 25 seconds is likely not enough time for large calls where 10k issues are returned. To put this in context, the data is for a burndown chart, so I just need to view the issue history. I suppose I could create a synchronous API that checks like 5k at a time and returns the answer to the client. Then the client calls the other API to kick off the full calc after it’s validated it. That said, that’s not a great design b/c in theory a client could skip the up front checks and just go straight to the other API.

4

Personally speaking, if your organisation is storing 10,000+ Issues in a single project (ID=10039) and you want to show the burn-down rate of every single one of those issues since the project was started in one, single chart, then you have created the problem.

IMHO, the scope of the chart is too big and that is the root cause of the problem.

5

Really appreciate you pointing out the prior threads and your time and certainly appreciate that everyone has their opinions on what should / shouldn’t be in a burndown chart. My goal is to build something that’s scalable and usable by a wide variety of people for a wide variety of purposes, so I don’t want to artificially constrain it.