Hello!
I would need to add worklogs to JIRA issues in JIRA cloud using the REST API:
…but if done this way the author will be the owner of the API key. Is it possible to log a worklog for a JIRA user based on email or a ID that can be fetched using the worklog author email address?
-Kim
That will not be possible via API tokens & Basic auth. Perhaps OAuth 2 (3LO) or a Forge app would suit your scenario?
Hi,
It is not possible to do with a Forge App too. Forge doesn’t support “user impersonation” and REST API doesn’t accept “worklog author” as a parameter. Only connect apps can do this. This is one of the important features Connect has but Forge doesn’t have. Situation is the same for adding comments too.
Yes, you are correct that user impersonation is not possible with OAuth 2 or Forge.
I disagree that means user impersonation is required to write work logs or comments as different users. OAuth 2 is always in a user context, so it can read/write “asUser” for whoever has granted the app authorization. Forge can switch between “asApp” or “asUser”. It’s not “impersonation”, it’s always in context of the current user. That means an app can use a “pull” model (app reads from source and writes to Jira) for the data, rather than “push” (app is sent data externally for example via a web trigger), to write as the current user. Both are valid ways to avoid using API Tokens.
I stipulate that not all scenarios can leverage a “pull” model. So I understand that some scenarios will require “user impersonation”. But we would need to hear more from @KimHalavakoski about what that scenario is.
Hi @ibuchanan ,
Thanks for the information. But I may be missing something here. Let me to explain our situation and maybe you can help us to solve our issue here. We have a timesheet application. At the end of a period, a team leader/project leader check users’ worklogs and they may need to add some missing worklogs or fix some of the existing worklogs. To implement this, when current(logged in) user is “Project Leader” we need to able to register a new worklog for any project member:
As far as I can see, both of them are not a solution to our problem. If there is a way to do this, I really appreciate your help here. Because this is an important feature for us. It is in use in our DC app for years and our customers are really using it.
You’re not missing anything, for your scenario. You’ve built your app around user impersonation. And, I did agree that Forge/OAuth 2 don’t do that.
But, if you were just starting out now and Forge were a constraint, I could see a user-centric way to make Forge’s “asUser” fit. Rather than write updates directly to worklogs, maybe each user has to accept the proposed adjustments. The mental model would be the Project Leader is making a “pull request” on those work logs and the actual user still has to accept them. In that case, your app might be storing some temporary values in Forge Storage (where the “author” doesn’t matter), and then deferring the writes until you have the actual user in the app.
On one hand, this is far more tedious than your current flow. I’m sure that experience with real customers taught you the “Project Leader” is the best solution. On the other hand, my scenario is still realistic (even if not as marketable). There are certainly some customers (but likely fewer) who would want the audit logs to show exactly who entered which work log and when. My point being, the auth models have real-world value and impact, which is why I don’t think it’s appropriate to advocate Connect for all time entry use cases. And why I think you’re right for your own case: you don’t have what you need to use Forge yet.
Hi all,
my request is related to yours but I am not even using a Forge App. I am trying to use curl with basic authentication to see the summary of my issue to obtain some sort of login-success, but it seems I don’t have this privilege even.
…atlassian.net/rest/api/3/mypermissions does not return me even anything
eventually I would just log work to my issue and nobody knows which permissions (where) need to be granted.
Cheers 