We also have a tool which is compliant to labor law in our country and that's why we need to sync the worklogs to Jira. But setting the author of the worklog to something else is not possible. I'm currently completely stuck with that using the REST api. Also the Java API allows that via a custom REST endpoint, but because of security reasons we have to move away from a custom plugin for that.

This can also allow nice integrations like slack commands to allow users to log their own times..

I fully agree with franck, please add that functionality!

A project administrator can already update and delete worklogs of other users. So why can't he create worklogs for them?

This is a must to ease administration and sync with other tools.

Just add the name or key of the user in the RestAPI "Add Worklog" parameters and check that the caller has the permission "Edit All Worklogs" on the project. Set the author to the user passed in parameter, and the updateAuthor to the user calling the API.

Everybody will be pleased...

very ugly

We are still using sudo for Jira to get this functionality. Thanks David!

https://marketplace.atlassian.com/plugins/com.jirasudo.jira-sudo

Hey, This is from 2012 right? The endpoint for adding work logs offers the possibility to write an author but for me, it doesn't log the work log as the given author. So am I doing something wrong or is this still not implemented?

Hi @LeeCorrell unfortunately it doesn't work for cloud, the API the plugin uses is not exposed in that environment.  Sorry!

@DavidErickson, does that plugin now work for Cloud?  We'd be interested, too.

We found this Add-on very useful. It's commercial but has a reasonable price tag and supports current Jira versions.

https://marketplace.atlassian.com/apps/1217264/log-work-as-another-user-for-jira?hosting=server&tab=overview

Our idea was to start writing Jira numbers in our meeting descriptions. (as we do it in every git commit) A tool would retrieve all calendar events from anyone in the company (using Google Calendar API), and from the Jira number found in the description, log work in the associated Jira item. The goal is to be able to better know how much time we spend on a specific epic and features.

The tool needs to be able to log work, for anyone, in any Jira item.

I see https://marketplace.atlassian.com/apps/1214103/log-work-utilities?hosting=server&tab=overview can do this but it's a plugin so it uses the Java API.  Too bad it is unsupported and breaks my v7.x server installation.

FWIW, I'd +1 the author and updateAuthor fields of the body being used if the authenticated user is an admin.

Patrick-
Happy to help diagnose, can you please send me an email directly to david@jirasudo.com?

Thanks!

Hi David Erickson,

We have been using your plugin with succes but since we updated our Jira server (to 7.9.2) it doesn't anymore.

We are running v 1.0.2 of you plugin.(says this should support up to 7.10.#)

We use this code: (php)
curl_setopt($ch, CURLOPT_HTTPHEADER,['Accept: */*', 'Content-Type: application/json', 'sudo: '.$sudo_name] );
 
Do you have an explanation why this previously working code does not anymore.
 
Thx
 

Hi Amish-
I'm not 100% clear on what you are asking, if you can share more detail I may be able to help. But in general, if there is an API call that the target user could call to accomplish what you want, then this plugin will allow you to make that same call on behalf of that other user.

Hi David, 

Does your plugin also allow the visibility tag to work as right now it does not work when you use a different user? 

Amish I confirmed support for 7.5.0, it should be ready for you to try out.

David, thanks, I must have missed your earlier comment on Sudo for JIRA.

I will look into that and have a talk to our JIRA administrator about the possibility of trialling it. Seems we're on 7.0.0 which is a bit dated too...

Thanks for that, I will wait for you to do that and then give it a try. I need to add comments to issues as a different user than the one authenticating to request. 

I can fix that, give me a couple of hours

Hi David,

Thanks for that, but I'm using JIRA Server 7.5 and your add-on doesn't support it.

Peter and Amish, another small plug for my app Sudo for Jira I built it for exactly this use case, check it out.  Full REST API access triggered using any user you'd like.

Has anyone found a workaround for this? I need to use this to integrate with GitBlit. 

Add another very keen for this functionality. We're using JIRA for planned/project type activities but we still have a signficant amount of time spent on operational issues which is logged in our ticketing system. Our time reporting is desired from a single system though and the preference for this is JIRA.

I'm writing a script at present to reflect the time from the ticketing system into JIRA stories, but of course without the ability of an API user to impersonate my team members, this time will get logged against the API user rather than the team members performing the work. The best I can do is add the user's username as a comment against the time.

I understand there are security implications, but surely this can be mitigated by making the option disabled by default and only a JIRA administrator can override this and enable it for specfic users, and possibly even restrict it to specific IP addresses (although I know IP's can be spoofed).

I want this function

I am +1 to log work for another user via REST API

Thank you for the explanation. I am sorry for wrong accusation.

It's weird though how REST API and JSON importer each have a part of what we want but neither has a full set (see JIRASERVER-64427).

zan.dragan206251178 we introduced separate issues to track requests for Server and Cloud back in March. My previous comment was made several months before that. Apologies for the confusion.

Hi Dave,

I somehow fail to see the relation of posting some fixes on JIRA Cloud in the JIRA Server issue tracking. Not to mention those fixes are not actually resolving the issue since we (customers who have already paid for your product and expect to get full fledged functionality with it) would have to buy or develop an add-on in order to "get" your fix.

Limiting certain actions to JIRA administrator is a viable way and not that hard to implement, in my honest opinion.

Regards,
Žan

Hi everyone,

Since November 2016 we have supported the JWT Bearer token authorization grant type for OAuth 2.0, which allows integrations built on Atlassian Connect that are installed in JIRA Cloud instances to make impersonated API requests (including logging work and commenting). This provides add-ons with the ability to make server-to-server requests in a secure manner, with clear authorization from an administrator.

We don't have any plans to go further on a generic ability to "impersonate users" with REST API calls with basic authentication right now.
Dave Meyer
Senior Product Manager, JIRA

Hi Dave

Do you have an update on this please?

We have been able to create issues on behalf of other users for a while now using the REST API and was a little surprised to find that this is not possible when creating a comment.

The feedback that we are getting from our users tells us that they do want the author of comments set to the person who made the comment and at the minute I can't see a way of doing this.

Thanks

Scott

Apologies for the slow follow up on this. Just want to reiterate that I absolutely understand the end result of what you're trying to accomplish – it's definitely valid. We're interested in developing some implementation of service accounts (description of its implementation by Google here), however we can't fit it into our roadmap right now. But it's something we will certainly look to add in the future.

Regards,
Dave Meyer
Senior Product Manager, JIRA

We have the same scenario as most of the people that commented before - we collect time sheets using an external application and do a bulk log to JIRA, instead of users doing it themselves. While AC-1080 (impersonating the user for certain actions) would be one way to solve this, we at our company believe that this should be solved otherwise.

As per Peter's example above, if the API allows to specify author/updateAuthor, it naturally looks like one could provide any JIRA user ID. This does not work that way and had us scratching our heads for a while when we did the integration. Now, obviously, users posting worklogs for other users could lead to highly confusing scenarios. So, the way we see this:
1) the feature (logging worklog as another user) should be limited to administrators or some worklog specific permission
2) to keep the audit trail, another field "createdByUserID or something similar should be added to the worklog entries. This would be immutable and tied to the login under which the entry was created.

This kind of API documentation isn't really very helpful. You leave us having to guess which attributes actually do something and which are just part of the internal state of an object.
So does the example include all the attributes that are allowed to be updated?

Hi Dave,

so, the problem doesn't solved, but glossed over.
Our situation: we collect the spend of time without JIRA, because of we are using a really good product for it. It's collect the worktime exactly and parse to job automatically. After this we don't like that the user write the worklogs manually into the JIRA issues. So, the spent times per workers we have in another system (and database). We would like to load these times into JIRA, because the REST API offer it (add workload entries).
The users would like to see directly in JIRA the spend time amount.

We using now the JIRA v6.1.6 and it's allow the POST with author and updateAuthor fields without error, but the JIRA store another value. For example:

{
	"author":
		{
			"emailAddress": "somebody"
		},
	"updateAuthor":
		{
			"emailAddress": "somebody"
		},
	"comment": "",
	"created": "2016-05-03T12:41:16.297+0200",
	"updated": "2016-05-03T12:41:16.297+0200",
	"started": "2016-05-03T12:41:00.000+0200",
	"timeSpent": "1h"
}

I get return a 201 response (created), but the stored worklog is the following (response body):

    {
        "self": "https://***.***.**/rest/api/2/issue/22360/worklog/166575",
        "author":
        {
            "self": "https://***.***.**/rest/api/2/user?username=peter.nagy",
            "name": "peter.nagy",
            "emailAddress": "peter.nagy@***.**",
            "avatarUrls":
            {
                "16x16": "https://***.***.**/secure/useravatar?size=xsmall&ownerId=peter.nagy&avatarId=12906",
                "24x24": "https://***.***.**/secure/useravatar?size=small&ownerId=peter.nagy&avatarId=12906",
                "32x32": "https://***.***.**/secure/useravatar?size=medium&ownerId=peter.nagy&avatarId=12906",
                "48x48": "https://***.***.**/secure/useravatar?ownerId=peter.nagy&avatarId=12906"
            },
            "displayName": "Péter Nagy",
            "active": true
        },
        "updateAuthor":
        {
            "self": "https://***.***.**/rest/api/2/user?username=peter.nagy",
            "name": "peter.nagy",
            "emailAddress": "peter.nagy@***.**",
            "avatarUrls":
            {
                "16x16": "https://***.***.**/secure/useravatar?size=xsmall&ownerId=peter.nagy&avatarId=12906",
                "24x24": "https://***.***.**/secure/useravatar?size=small&ownerId=peter.nagy&avatarId=12906",
                "32x32": "https://***.***.**/secure/useravatar?size=medium&ownerId=peter.nagy&avatarId=12906",
                "48x48": "https://***.***.**/secure/useravatar?ownerId=peter.nagy&avatarId=12906"
            },
            "displayName": "Péter Nagy",
            "active": true
        },
        "comment": "",
        "created": "2016-05-03T12:50:36.175+0200",
        "updated": "2016-05-03T12:50:36.175+0200",
        "started": "2016-05-03T12:41:00.000+0200",
        "timeSpent": "1h",
        "timeSpentSeconds": 3600,
        "id": "166575"
    }

So, you denied this possibility with an 400 error code in the latest version instead of give us a right solution. "Great!"

Thanks,
Peter

Hi Peter,

This is because author and updateAuthor are part of the general JSON representation of a worklog. But the implication of your comment is that JIRA should not accept POST requests if these attributes have values in the request body. If the remaining attributes, like comment and visibility are valid, then I don't think it's appropriate for JIRA to respond with a 400 or 403 error.

In our example request in the documentation, you can see that the author and updateAuthor fields are omitted and if you expand the schema, you can see that these fields do not have a standard string type.

Why include the author field in the create or update methods when this is an immutable property?

Hi Dave,

it's an error, because i can post these fields with value, but not these values will be stored.
So, the interface is wrong in this case from point of my view.

Best regards,
Peter

Hi pete756123722 and sadykowich,

The presence of the author and updateAuthor fields is not an error. The author field is the original user who created a worklog. Users with the 'Edit All Worklogs' project permission can edit worklogs created by other users, similar to how users with the 'Edit All Comments' project permission can edit comments created by other users. Both of these permissions are only granted to administrators by default. When a user edits a worklog after it has been created, that username is stored in the updateAuthor field. But obviously we still want to store the name of the user who originally created the worklog, so they are always in the author field.

This feature request seems to be requesting the ability to impersonate another user when POSTing to the worklog resource. I worry that this feature request misunderstands how worklogs work. Unlike the "Reporter" field on an issue, which is mutable and can be changed, a worklog author is immutable, similar to a comment.

Most scripted JIRA REST API requests are done via Basic Auth or session/token based authentication. It's not possible to impersonate another user – if you call the REST API with the credentials of User A, you can only act as User A. With AC-1080, we are investigating several flows for clients to request permission to impersonate users. There's a description of how this has been implemented by Google here. Once we are able to support this, add-ons will be able to offer this feature in JIRA Cloud.

However, I do not expect that we will change JIRA's REST API itself to allow you to change the author field for a worklog itself. It will continue to be set based on the API request.

Thanks,
Dave Meyer
Senior Product Manager, JIRA Platform

@Pete West: And yes, this is an error, because the REST request contains the author and updater fields...
The 3rd party stuffs are great, but not possible for us because of our provider. In an enterprise environment we are one of the many companies. So, we wait for the official support.

Bump for this feature. Why does the API include request fields for `author` and `updateAuthor` when these are not used?

Getting this working and in and on the marketplace ended up being a much bigger process than expected. My addon that has this functionality has finally been released at: https://marketplace.atlassian.com/plugins/com.jirasudo.jira-sudo

In a nut shell it allows admin's to perform REST calls on behalf of other users, great for automation setups where you are triggering off of commit messages or data coming in from other systems.

Yes, @dmeyer, this decision caused disappointed.

snip see below

Please give a vote to request solution!

Please support this, and the ability to set the user triggering the commands for all other REST related actions as well!

Yep.. interface bug! Persists in v.6.0.4

This isn't really good for other reasons. F.e. in this case the Folio works with the fake user...
So, we wait to the official patch, because it's an interface error.

We had to create a fake user that log time for others with a description including the name of the real user. Kind of ugly hack

francis@idalko.com: thank you for your help! Unfortunatelly the 3rd party suff not possible in our environment.
So, we would like an official support. But we think it is an error, because the REST request contains the author and updater...

yi-an, sadykowich
We have a simple add-on which provides such rest interface.
Send a mail to support at idalko.com - if interested.

Francis

We wait this feature also.
When will be officially supported?