How to change reporter

[Jochen Betz]

While I can change the reporter of an issue in a software project, this seems not to be possible in a service management project when a ticket has been created via the portal.

How to achieve this?

Reasoning: People who are NOT responsible for a problem but want to report it would otherwise be reluctant or not report issues at all anymore. As soon as they report it, they'll be in the loop all the time and some consider them as contact person; which they are not.

[Joseph Chung Yin]

@Jochen Betz -

As of now, customers cannot raise issues on behalf of some other users.  See the following KB article for your reference -

https://support.atlassian.com/jira-service-management-cloud/docs/raise-a-request-on-behalf-of-a-customer/

Only when a user who also have JSM agent license can submit request issue as someone else.

My recommendation would be that the reporter also share the issue with someone else, so the true reporter is added as the Requested Participant of the issue for update information and add his/her comments to the issue via the portal.

Hope this also helps.

Best, Joseph Chung Yin

[Susan Waldrip]

Hi @Jochen Betz , in addition to @Vitalii Rybka 's suggestions, I'd offer that you can also add the Reporter field to both Edit and View operational screens in the right-hand section of the screen. Since the Reporter field is on the Edit screen, you can then edit it. The reporter still shows up in the main section but it's not editable.

[Susan Waldrip]

Hi @Jochen Betz , I must not understand your request because I'm using JSM (we don't have Jira software/platform). Would you please post a screenshot of your screen so we might provide better suggestions?

[Jochen Betz]

Sure I can, but there is nothing different from your screen shot except that reporter cannot be changed.

• As you can see on the left, it's a service project
• In the center you can see that the issue was created via portal (which is not clear because not visible on your screenshot)
• As you can see on the right reporter is available and pinned to the issue
• Even the name pixeled, clicking on it, it cannot be changed.

BTW: Person logged in and reporter are the same person aka me which is admin of the project.

[Susan Waldrip]

Did you add Reporter to both Edit and View operational screens (or the Edit/View screen, if that's your configuration)? If so, then I'd suggest contacting Atlassian support at https://support.atlassian.com/contact, they should be able to see if anything's going on w/ your instance and provide a solution.

[Jochen Betz]

Yes, because they use both the same screen.

@Susan Waldrip Can you confirm you are using a service project? Are you using Jira Cloud or on-prem?

[Susan Waldrip]

Hi @Jochen Betz , I am using JSM Cloud, Standard version. Your best bet is probably to contact Atlassian support at https://support.atlassian.com/contact and have them look into your configuration. I hope you get this figured out soon -- and if you do, please post the solution here!

[Susan Waldrip]

Hi @Jochen Betz , I just came across one more thing you might check: in the Permission Scheme for your project, make sure you and others are included in the "Modify Reporter" permission or it won't matter what else you set, you won't be able to change the Reporter. If you've already addressed that, then my previous comment about getting more help with this still applies, and good luck.

[Jochen Betz]

Thanks @Susan Waldrip , that was the first thing I checked. All people have permissions to change the reporter in the project.

In fact, it is worse than I thought - It's only people with a service agent license which can make modifications to the ticket at all. So it looks like an artificial limitation of Atlassian to service projects to me.

[Vitalii Rybka]

Hey Jochen! I've run into this exact issue before - it's super frustrating. In JSM, once a ticket comes through the portal, the reporter field gets locked down pretty tight compared to regular Jira projects.

Here's what I found works: You can usually change the reporter if you have admin permissions by going into the issue and editing it directly (not through the portal view). Sometimes you need to do it through the backend issue editor rather than the front-end portal interface.

Another workaround I've used is creating a custom field for "Actual Reporter" or "Original Contact" so you can track who really needs to be in the loop versus who just submitted it. Then you can update your notifications and workflows to use that field instead.

Your reasoning is spot-on though - people definitely stop reporting issues when they get bombarded with follow-ups for problems that aren't theirs. It's one of those JSM quirks that can really hurt your reporting culture if you don't work around it.

[John Funk]

Hi @Jochen Betz  - It sounds like what you are really looking for is the ability for a customer to raise the issue on behalf of someone else. You can vote for and follow that request here: 

https://jira.atlassian.com/browse/JSDCLOUD-4102

However, don't expect that to get done anytime soon. In the interim, I would add a custom text field to capture the person they are raising the request for if it is not them. Be sure to give clear instructions that it must be a valid email address. 

Then create an automation rule to copy the value to the Reporter field. 

[Jochen Betz]

Yes and no. 

NO: Because we WANT people to report problems albeit they don't want to be the contact person because i.e. they are not related to the problem in any way but see that something is wrong but they don't know who is. In that case we WANT them to report and later we change it (which I cannot even as service agent - this MUST be possible!) 

YES: In the case above when he knows who should take care of it.

Adding another field does not solve the "NO" case above. Because the reporter will still get all the questions/mails and stuff. Adding something to fix something is in general a bad engineering/human approach. It's better to remove things - in this case restrictions. Yeah, we could add even more unnecessary stuff to automate something...

Voting for an issue at atlassian? ... not intending to work that long in my life to see it become closed (not even saying fixed); more likely because "not implemented".
Sorry for that permission, but reality proofs it.

And looking at the exact issue you are referring to... 9 years seriously? Nowadays SW companies don't even exist that long anymore.
And still..... nothing happened: UNASSIGNED

That's what Atlassian calls "We listen to our customers". Well "Listen" yes, act? No.

[John Funk]

Then why not just use automation to change it to an internal user, i.e. Agent when the issue is created? Can you not change the reporter on any JSM project with any value in it? 

[Jochen Betz]

Because a) I can't change reporter at all and b) how should I know in which case to change the reporter and when not?

[John Funk]

a) You have tried to change it by automation and that doesn't work either? 

b) How do you know when you should change it now? Do you just wait for someone to complain? 

c) Can you change the Reporter on other JSM projects? 

d) If there is an Agent in the Reporter field are you able to change it? 

[Jochen Betz]

a) why to use a hammer just because a screw driver is not enough? Again it's adding something unnecessary on top which should work out of the box. But no: I did not.

b) By talking with the reporter after he reported the ticket?

c) I only have one JSM project

d) No, that's what I said already somewhere else, even with a screen shot. I am the admin of the project, I am a service agent in the project and I am the reporter of the issue - and I can't change it. And to prevent e) No, I can't for tickets where I'm not the reporter neither.

[John Funk]

Your best bet is to open a support ticket and let Atlassian sort it out. Please update back here with the solution so future readers will know. 

Good luck to you. 

https://support.atlassian.com/contact/#/

[Jochen Betz]

Been there, done this... first reply 16.06. nothing since 

So as you say "best bet", but only a bet.

[John Funk]

You have a premium subscription and support only replied one time to you and never since???

If you give me the support ticket number, I will see if someone will intervene. 

[Jochen Betz]

Now to defense of their support: It wasn't there fault.

While I really did not get a reply since.... their mail (which was the 2nd) ended up in a spam folder - for what ever reason. That will trigger yet another ticket.. this time internally IT *argh*

So thanks for asking! 

[John Funk]

I am confused - is Atlassian Support working on it?

[Jochen Betz]

They had send a mail for a phone call appointment which ended up in SPAM

[John Funk]

So have you talked with them? Are they still working it? Have you responded? 

[Trudy Claspill]

Hello @Jochen Betz 

Addressing your last response to @Susan Waldrip about limitations on who can make changes to a JSM issue:

Only members of the Service Desk Team role will be able to make changes to the issues. If they have a JSM Agent license, then they will be able to make changes to most fields (that don't require specific permissions to change) assuming that Permissions have been granted to the project role correctly. If they have only a Jira (Software) license then they are restricted in what they can change.

For more information refer to https://support.atlassian.com/jira-service-management-cloud/docs/what-users-and-roles-are-there-in-jira-service-management/

Have you tried using the Permission Helper to see if that reveals any more information about why the Reporter can be changed by a specific user in a specific JSM issue? That tool is available to Jira Application Admins through the System settings.

[Jochen Betz]

Thank you @Trudy Claspill for the longer explanation and looking into the topic.

Let me roll up from the bottom:

Yes, I have used the permission helper. And even myself as admin and with service agent license can NOT change the reporter, albeit the permission helper says I should (all green)

But even if I could it's not our final goal, that we have to depend on service agents to make these changes. It's IMHO completely irrational to apply this restriction with service agent license - except for selling the latter one. I seriously have already considered to take all the hassle to move the whole project and move it to a software project because of that. The real blocker for that move is that it would be rather tricky to keep the same issue IDs. 


I guess, that  @Susan Waldrip did not mention that she has a service agent license. If she found a way otherwise, that would be great.

[Susan Waldrip]

@Jochen Betz , It seems like you've covered all the bases. I will post your question in the Community Champions forum to see if anyone can help you.

[Jochen Betz]

Thank you @Vitalii Rybka for your reply. I have admin permissions on the project, but as I wrote in my original post: This is only possible in a software project but not in a service management project. Albeit I see the field, I cannot change it - even for a ticket I created my self.
I assume you mean admin rights for the project? I'm the creator and admin of the project AND I even have a JSM license, so in case that's what you are saying, it's not working for me; can't modify it in what ever view.
This by the way would be an acceptable work around, to simply allow EVERYBODY (without a JSM license) to create issues in the behalf/name of others @Atlassian 


Same goes for what @Susan Waldrip says: It seems (to me) only to be possible for software project.
Adding an additional field as @Joseph Chung Yin suggested does not solve the problem, it adds just more complications. Engineers tend to fix problems by adding more; which IMHO is the reason why it does not work in the first place here. It feels pretty much that for this "special" kind of project Atlassian decided to castrate the project - that goes for several other things there, too.