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.:
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 ). It’s not a deal breaker for us, but would be a really nice to have the feature.
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.