That's very much needed. We have several integrations where agents from other systems write comments from there

and they get as commenter some Jira helper and it is quite confusing

@Tushar Wagh 

Is there any updates on this ?

I doubt there will be any update on this as EOL is nearing: https://www.atlassian.com/migration/assess/journey-to-cloud

One year more and we will have 10th anniversary. :tada

Tell me, why can't i wrote my own email handler posting comments on behalf different users? Can't do this , can't do that - this product is disappointing as f*&^ !

Ps. I am not going to buy email handler plugins since they are billed per seat!

I don't believe that Atlassian will ever add this feature because the current way to get around it is to purchase licenses for all users. If they added this functionality that would no longer be necessary.

That said, this basic missing functionality was a deal breaker for us. We wanted to make our own in house issue tracking system using the Jira Api, but we ended up creating our own api because of this problem. Extremely frustrating.

I have app that integrated with jira,

the user of my app can't comment on Jira via my app from their own name, because I does not have their passwords in domain

I need this feature asap

We have fully integrated JSD into our Magento 2 application. We sell Magento extensions and use the integration to directly support our customers in our website without them having to worry about any internal systems we use. It simplifies things for our customers and simplifies it for us aswell because customer tickets are created in JSD and automatically added to our KANBAN board. 

This being said, we can create a request ticket on behalf of a customer just fine. The customer creates an account in our shop and as soon as the customer wants to raise its first request, a customer in JSD is created and the request is raised.

It only seems logical that i can use the customers accountId, which we get in the response from creating a new customer, to create a comment on his or hers behalf. It really baffles me that this is impossible at the moment, as this seems 100% logical follow-up behavior which is in line with being able to create a ticket on behalf of this customer in the first place. If you can create a request on behalf of the customer, why cant you work with that request on behalf of that same customer to create things like comments?

I really need to be able to provide "raiseOnBehalfOf" in the request headers for comments and possibly the other request endpoints aswell, so that this works in line with the request creating.

Not having this feature already costed us a lot of support because customers file complaints against us, complaining how we respond with their texts in their name. Simply because when we create the comment, the only way for us to create a comment is under our own name. It also costed us money because when the comment is raised under our own name, the ticket is transitioned but no notifications are being sent to us and this causes the customer to wait for support or answers until we notice it. If this process takes to long, the customer wants a refund which happened on multiple occasions.

Can you please give this priority, it has 303 votes and i'm more than willing to pay a few hours of support to get this implemented, if that's what it takes to get this to progress faster. This problem is affecting us as a company for about a year now so i would love to get this feature implemented

@jacqueline Sudo for Jira is continuing to be updated, but as was indicated earlier in the thread, it is not currently compatible with the Cloud version of Jira.

This function is an absolute basic requirement for all companies that use their own customer portal and only pass the issues backwards via the api. Currently you can only use the plugin sudo for jira, which is no longer updated. This function is a must, if you already have the create ticket on behalf of function, why is such a mandatory api function missing?

Thanks for suggestion but unfortunately we use Jira Cloud which doesn't appear to be supported.

@lee we use sudo for Jira to do this:

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

Should work as long as the user info is still in your Jira instance

We would like this feature also to be able to migrate data from our current provider, to JIRA. We are re-creating historical issues but cannot create the comment by the original author.

We need this too ... This could be the thing that pushes us to integrate zendesk instead of Jira sevice desk to be honest

This would indeed be very helpful. 

We would also like to get this feature as it would enable us to better integrate our Incident Bot (let it add comments with the actual user who made the comment)

I agree. Surely this is a simple request to implement and one that needs pushing up the priority list rather than langushing in the gathering interest state.

https://community.atlassian.com/t5/Jira-Service-Desk-discussions/Servicedesk-API-Create-request-has-raiseOnBehalfOf-comment-has/td-p/1174114#U1174125

The ServiceDesk API would allow for tighter integration with existing branded portals if you add a commentOnBehalfOf attribute... after 6 years this should deserve some time in a sprint away from the backlog... it shouldn't require too many story points to implement right?

This would be great

Any updates on this? I am trying to make a comment on behalf of a User without changing he's password.

Has anyone got a workaround for this?

Thanks

As many people commented here, we are also using the REST Api to integrate Jira Server with another system and we are dealing with the same problem.

Moreover, we are using (or trying to use) the Java jira-rest-java-client-api library, so in case we use David Erickson's "Sudo for Jira" plugin, which seems pretty good, we should either dismiss that library or use it halfway (only model classes) because we would need to modify request headers manually to make it work.

Is there any plan on finally adding this functionality?

This is definitely NOT working on the REST API for Cloud unless I am sorely mistaken, because I cannot get it to work for anything.

Yes, an update on this issue would be great. It does seem mad that this, simple change, has been made to the cloud version but not the server version.

Can we get a community update on this issue? I don't understand why it's taken 6 years for such an obviously useful feature.

I'm trying to syncrhonize comments between my companies main issue tracker and the Jira system we are using for Software, and this inability to set the correct author for comments makes it unworkable.

The problem was raised in 2013.  When will it be resolved?  From the comments I see that the SOAP API supported it, and the REST API does not.

Do we have anything similar for Jira service desk cloud , like we have for server version.

https://marketplace.atlassian.com/plugins/com.itlab.jira.plugins.extender/server/overview

Edit* Ha, just say that comment by Adam. The add-on works great. 

Not sure if this was already mentioned or not, we use "Extender for JIRA":

https://marketplace.atlassian.com/plugins/com.itlab.jira.plugins.extender/server/overview

This allows for API calls to include a "context_user". We use this to sync comments across multiple JIRA instances and issues, so that the user appears to have made the comment in multiple locations, while only needing to make the comment in one location. Seemed like visibility was also supported. The add-on was relatively inexpensive.

Good luck,
Jake 

I would really like to see this feature coming, too. 

My problem:

• Importers (JSON/CSV) support comment authors but not comment visibility.

• REST API supports comment visibility, but not comment authors.

Tricky situation ...

Any hints?

Hello,

if you are looking ability to execute all REST API on behalf of another user  please check my new plugin Extender for JIRA

Cheers

Same request here. We want to add comments from Rocket.chat, and that the author is the user from Rocket.chat, not the web hook user.

I still think, universal "comments" class should resolve many problems. what for different tabs under issude shold be supported by different methods? Standarisation is needed for this. for example, last time when CVS support was dropped, I've written my own integration with CVS. This simply monitor CVS service, and put all new commits, simple as JIRA comments with some formating. But this is mixed with other regular comments. Then why we cannot give customization comment classes? It should ensure compatiblity for long time and many JIRA versions. Another benefit, it will prevent us for building additional unneeded JIRA plugins, because this can be supported by external services based on REST. Last question, giving availability for putting comment author and insert time is security rish? In current implementation, yes. But is it a problem when we limit IP range for technical user? Is it problem to give advanced admin rights to technical user? In my opinion not. Then I'm waiting for implementation, and I hope like many purchasers, my investment won't be wasted.

Florian it is not just you. I feel the same way. We are also waiting for kanban backlog to server version.

Hi everyone,

Is it just me or is Atlassian constantly removing or delaying features for the server version of JIRA? I understand that the majority of Atlassian's users is happy with the cloud version but this must not mean that server users aren't able to accomplish the simplest tasks like adding comments in behalf of other users. It is ridiculous that we would need third party plugins to try to get these things done. If Atlassian wants server users to slowly bleed out or hit a blocker before they finally move to the cloud version just say so and we will happily move away to other products. Don't get me wrong, this would be a very painful thing to do but we are getting to the point where we are worrying about the future of the server products and need to make sure our investment won't be wasted.

Florian

This is kinda crazy - every other service desk out there has an API which allows you to create tickets and add comments as any user, surely this isn't complicated?

I understand that it is now available in cloud? But isn't available in Server?

With comment is many bigger problem. At now one, second, third plugin doesn't work with new jira, for example at last time kicked out is CVS integration. It would be nice, creating comment class, and silently assign default class 'comments' for 'comments' tab. when comment class is different, then different named tab should be displayed. Idea is, no additional plugin is needed for new JIRA integration, example for svn/cvs/testlink/some automation or any else.

of course setting creation time and creation author for comment is strongly recommended under REST api. It is not a problem with REST availability for all users (for paranoic, it can be hidden by web proxy based on apache or nginx), problem is priviliges scheme. there should be additional privige what allows setting time and author for comments.

At now this functionality is needed for currently available single tabbed comments.

This is my solution for the issue, let me know if it helps

https://bitbucket.org/manutd4913/jiraoauthhelper/src

@Seb Ruiz - we would love to use this feature (and the others enabled by AC-1080) - but without AC-1014 we can't look up a user (in our case - we need to find a user by email address but this flow is initiated by an indexed git commit on our server not a user interaction). We don't currently request ADMIN scope - we're really hoping that AC-1014 (or other enabler) can come along so we can search for users. 

I'd like to give a thumbs up to this feature as well. Currently importing issues with comments, and having the same set of problems. I'm using JIRA Cloud.

I know there are already tons of comments here, but I wanted to add my voice to the chorus.

Dave meyer, you promised it now deliever it

• JIRA 7.0 will ship without the SOAP and XML-RPC APIs
• The JIRA REST API will have functional parity with SOAP

But we still need this support as a general REST API requirement .

Hi steve.west819054216,

Could you email me at dmeyer@atlassian.com? Our team will be able to give you some guidance on upcoming impersonation capabilities for Atlassian Connect add-ons.

Dave

Please add this as well. We are creating a Connect Add-On and the author always shows as the connect add on user, not the user we specify who created this. I even set the context in the JWT to the user we would like to see and it does not work. The JWT mentions context as only from the product to Jira, not the other way around. You would think that the add-on would be able to specify who on behalf we are running on.

Currently trialling David Erickson's 'sudo' plugin (https://marketplace.atlassian.com/plugins/com.jirasudo.jira-sudo) which he mentioned before and it's working very well so far - not only for comments but other operations as well.
Pity that we have to resort to 3rd party plugins but at least there is a work-around available.

https://developer.atlassian.com/blog/2015/05/jira-soap-api-announcement/

> Here are the key details:
> * JIRA 7.0 will ship without the SOAP and XML-RPC APIs
> * The JIRA REST API will have functional parity with SOAP
> * JIRA's rpc-soap and rpc-xmlrpc modules will be removed
> * JIRA will not ship with the rpc-jira-plugin

If one could set the author using the SOAP API but not with the REST API, then there isn't functional parity. 30 March 2016 and still no way of adding comments to JIRA issues on behalf of another user.

This is important, please add.

I suspect that Atlassian's security architecture simply isn't capable of this.

Please fix this! It is obviously needed from importing from other systems.

The request has been posted in 2013. We are now in 2016, the feature is still highly demanded and still not there

David, thanks for the information. Unfortunately, I don't see how I'll manage to convince the IT dept to buy the plugin. Nonetheless, I'll keep in mind that it exists, maybe for another project.

Cheers.

Olivier: Thanks for the comments! I had the same reaction you did pricing wise to many of the addons I saw on the marketplace, which when I looked, were approaching or even exceeding Jira's cost itself. I explicitly priced this to be a tiny fraction of Jira's cost (less than 5% of Jira now as your user count scales). No current plans to open source it, since it took a fair number of my hours to figure out how to get it working in the first place, create the marketplace entry, and ongoing time continue to maintain it as Jira changes.

is the user also substituted for Issue creation/modification/deletion?

Yes, ANY API call you make can be changed to look like it originated from another user, including anything to do with issues. In our organization we have glue code that integrates Jira with Gerrit, so that issues in Jira get transitioned from "In Progress" to "In Review", and "Done", as well as having work logged, and comments on the issue pointing to the Gerrit change, happen all automatically, and by the correct user that did the work, rather than the bot account. Which is useful for reporting, amongst other things.

Let me know if you have any other questions!

Your local IT crew has some odd expectations I think. The add-on is priced relatively low, and so is JIRA! I've no connection with the add-on vendor

Hey David! The plugin you made seems to perfectly fit what i'm looking for. But the licensing fees through the marketplace made my local IT crew refuse its installation, along with the fact that they can't review the code. That's too bad.

I'm a bit ashamed to ask: any plan to opensource your code and/or make the plugin free of charge?

Another question: is the user also substituted for Issue creation/modification/deletion?

James- Totally agree, but if you want an immediate solution look at my addon above. Otherwise, expect that you'll be waiting for a very long time (if ever) for Atlassian to fix it.

I just finished changing some Jira SOAP API client code to use the new Jira REST API. The old Jira SOAP API client code to add a comment to an issue was calling the RemoteComment object's setAuthor() method. This method was generated by CXF from the Jira SOAP service WSDL.

Interestingly, the javadocs at https://docs.atlassian.com/software/jira/docs/api/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/beans/RemoteComment.html show no setAuthor() method for the RemoteComment object.

I verified that when adding a comment, the Jira SOAP API currently does allow you to specify an author other than the user whose auth token is being used to make the SOAP API call to add the comment. In other words, the JIRA SOAP API currently lets a user with admin privileges add a comment on behalf of another use by specifying an author in the RemoteComment object passed to the addComment method.

I think the existence of the ability to add a comment on behalf of another user in the Jira SOAP API has added to the expectation that the new Jira REST API would also support this functionality.

We have relied on this feature for years for internal workflow tracking. It's sudden removal causes us quite a bit of inconvenience.

There's an interesting discussion of this issue at https://jira.atlassian.com/browse/JRA-12522

For reference, see https://docs.atlassian.com/software/jira/docs/api/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/JiraSoapService.html#addComment(java.lang.String, java.lang.String, com.atlassian.jira.rpc.soap.beans.RemoteComment and https://docs.atlassian.com/software/jira/docs/api/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/beans/RemoteComment.html.