nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Jochen Betz

As summary:

Key point: The reporter field was missing in the screen configuration. Meaning it was visible on the page when you view an issue, but in the configuration page it was not - and IMHO does not need to as it is a field which is always there, you can't remove it. So why add it either? All the other potential causes (at least as far as I'm aware of) has been already checked and discussed here.

All comments

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.

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.

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

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.

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.

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.

Trudy P 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.

Screenshot 2025-06-23 at 9.48.05 AM.png

Jochen Betz

Thank you @Trudy P 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.

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?

Jochen Betz

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management