Forge triggers, asUser().requestJira()

Forge Forge Modules and Product Triggers
#1

Hey @here,
is this correct that the asUser() requests are not available inside the functions triggered by events defined in the manifest part “trigger”?
e.g.:

 trigger:
    - key: my-key
      function: my-function
      events:
        - avi:jira:updated:issue

An attempt to trigger a asUser() request produces the following error:

  err: {
    message: 'Authentication required',
    name: 'NEEDS_AUTHENTICATION_ERR',
    status: 401,
    serviceKey: 'atlassian-token-service-key'
  }

asApp works just fine.

#2

We hit the same restriction in our testing for Codegeist, yeah. (See [FRGE-474] [Codegeist 2021] Forge feedback & bugs - Ecosystem Jira last paragraph)

3 Likes
#3

Yes, that behaviour is expected. What is the behaviour that you would like and the use case that requires it?

#4

Hey @kchan ,
well actually no current use case, it was just an attempt to track a user who triggered the action. The information about the user gets “lost” for the “background” tasks.

Think of an event which triggers another event, such a chain of events. So the observation is that the first event has the information about the user who triggered it, but the second (which gets triggered by the result of the first one) gets triggered by the app, and not by the user, thus carrying the app accountId on the event context.

This is a legit behavior and one that makes sense, yes. It’s just it would be really nice to pass the information about the initial user to the second (3rd, 4th etc.) events. One could think of it as a parent event context ( ppid :smile: ). It’s not a deal breaker for us, but would be a really nice to have the feature.

1 Like
#5

In our case, our Translation app will, in response to a comment created event, change the comment to add a translation to it. In another mode of operation, it’s adding the translation as a new comment on behalf of the user.
That first use case can also be achieved by the app having the ability to modify comments (which I think is blocked by FRGE-212), but that second one requires either the user context of the user that’s triggering the event to be available in event triggers, or requires general user impersonation to work.

2 Likes
#6

Good to see we are not alone there. :smiley:

Makes me hope this would be implemented later, maybe.

#7

That’s great, thanks for elaborating. I’ll pass this onto the team responsible for event triggers to see whether we can make something possible here.

1 Like