The reporter keeps changing when I move issues between projects

[tominwood]

Hi,

We are currently using JIRA to track and manage defects raised by multiple teams. Each team has a JIRA project - and users are generally permitted to raise issues within their own projects. Issues can be moved between projects to reflect whoever currently has responsibility for each particular issue.

When an issue is moved between projects the reporter changes (for some reason). It is important for us that the reporter remains the same irrespective of which project the issue resides within.

I would appreciate any help or explanation that anyone can provide of why this is happening - and how to stop it happening. As I cannot seem to determine the problem / solution by myself.

Thanks,

Tom

[Kai Honsel]

Hi Tom

We have the same setup and experienced the same problem. The user that moves an issue must not only have the move issue permission in the source project, but also the create issue and modify reporter permission in the target project. After we added the modify reporter permission on the target project, the reporter was not changed anymore. Hope that works for you, too!

Regards,

Kai

[itay cohen]

hi

i use the jira 6.1.7 I try to move ISuue by useing Bulck oprten and the Reporter is Canghe

but if I Move not by the Bulck oprten the Reporter is NOT Canghe

[itay cohen]

hi

i use the jira 6.1.7 I try to move ISuue by useing Bulck oprten and the Reporter is Canghe

but if I Move not by the Bulck oprten the Reporter is NOT Canghe

[Shawn Cady]

Ran into this same problem on our side. It seems that if the creator of the original ticket (from project X in your example) does NOT have the Create Issue Permission on the target project (Project Y), then the move issue wizard will allow you the option to change the Reporter. If the reverse is true, the Move Wizard will NOT allow the Reporter to be changed regardless of these other settings. The person doing the move must also have the Move Issue Permission in Project X and the Modify Reporter Permission in Project Y.

*Interestingly, Jira will allow a User without the Create Issue Permission in Project Y (e.g they have it in Project X) to remain selected as the Reporter (not sure that is intended).

Wow, that's confusing, but I think it is accurate based on our experimentation.

[Dave C]

Hi,

I have tried to recreate this and I haven't been able to experience the same problem - I was able the move the issue without having to change the reporter. If I use the example Tom provided:

1. Susan Jones creates an issue in Project X
2. Frank Smith moves the issue from Project X to Project Y
3. Frank chooses a reporter other than Susan Jones on the Move Issue: Update Fields screen (step 3 of 4)
4. Tom Inwood doesn't know who reported the issue

Does the administrator (in this case Frank Smith) have the Modify Reporter permission? If so the user in the browse user picker should default to the current reporter on the Move Issue: Update Fields screen. The administrator can then click Next and the reporter will not change.

In the example I tested with, Susan Jones had create permissions to Project X and did not have create or browse permissions on Project Y.

If you would like assistance, please raise a support request at https://support.atlassian.com and reference this thread. Also, I have closed off https://jira.atlassian.com/browse/JRA-26883 at this stage as I don't see it as a bug and it appears to be a support request. However, if this situation changes we'll definitely reopen the ticket.

Cheers,
David.

[Jeremy Largman]

I can see a couple ways around this:

1. Keep the issue in the original project, and simply change the assignee when the responsibility changes.
2. Allow create issue permission in the destination project. I realize this introduces the problem of incorrectly filed issues - you can use the 'message field' (JIRA toolkit) custom field to put a notice about where to create issues, or use links like https://jira.atlassian.com/secure/CreateIssue.jspa?pid=12290&issuetype=1&Create=Create when linking externally, to avoid incorrectly filed issues.
3. Use a custom field to preserve the original reporter, and copy it in. You can use the JIRA Suite Utilities for this.

I realize those are all workarounds, and it's not matching what you're expecting JIRA to do out of the box. I feel like I'd be misleading you if we opened a feature request; we're unlikely to change this design. I suspect other customers would not necessarily agree that in all cases, allowing a reporter to persist in the reporter field after moving to a project where they don't have 'report issues' permission is not a permission/security issue. There are use-cases out there where it would be considered a security hole.

[tominwood]

Hmmm. None of those are not work arounds are very satisfactory

1. We already have lots of projects set up with specific functions. These projects are full of issues and are being used by lots of people

2. Like many customers, we use limit users' permissions within each project - so if Frank Smith is a "Manager" or Project X should be able to create issues in Project X, however, if he is only a "basic user" of Project Y then we don't want him creating issues in Project Y. This is a pretty standard requirement - and many, many customers would expect that you could limit user's abilities on a project by project basis (rather than just exposing key functions to all users as a workaroud)

3. We could do this - but it slightly undermines (and replicates) a default JIRA field that cannot be hidden or removed from the JIRA UI (as far as I can see). This would create confusion when these fields differ.

I really don't agree that the reporter field updating itself when you move issues between projects is logical - or desirable for your other clients. This would make sense if there was a "Report issues" permission - that related directly to "being a reporter in a specific project", however this permission doesn't actually exist. The create issue permission describes a user's ability to create issues within a project - and the move issue permission describes their ability to move issues from a project. If I have the correct permissions to move an issue from Project A to Project B, then what does it matter that the Reporter doesn't?? Surely, that's the whole point of having those separate two permissions! This is definitely a bug - or at least, an unintended consequence - and I don't see why you wouldn't commit to resolving it. If doing so would expose security holes, then I'd be interested to know what those holes could be? It doesn't seem likely to me.

[Jeremy Largman]

Reading your answer, I got convinced. What you're saying makes sense.

So I dug into it a little further, and now I think we're seeing something wrong. Check this out, from Managing Project Permissions:

Move Issues

Permission to move issues from one project to another, or from one workflow to another workflow within the same project. Note that a user can only move issues to a project for which they have Create Issue permission.

So actually, now I think you've got a different thing going on. You should have to implement the #2 suggestion above, for this even to work! Can you confirm this isn't happening?

We might need to switch this over to a support ticket and get a copy of your data or work with you through a screenshare. I think we've not yet diagnosed it correctly.

[tominwood]

We are using it in the way you describe.

Susan Jones has the Create permission for Project X. She creates an issue in this project.

Frank Smith is an administrator and has the Move permission for Project X and the Create permission for Project Y and Project Z.

Frank Smith moves an issue that Susan Jones created in Project X to Project Y (as he is permitted to do). When this happens, he is challenged (on the move screen) to choose a new reporter. He does this and selects an arbitrary reporter - and now Tom Inwood doesn't know who raised the issue. If the reporter had stayed the same, it wouldn't have meant that Susan Jones had done anything more than as was intended by our permission scheme - the reporter field is just a reference (unless you assign it some greater meaning using permissions). For instannce, we allow the reporter of an issue to edit their issues, no matter what project it resides within).

I guess I think of it like this: Imagine if you guys created a project for "Issues raised by important customers" - and defined the permissions so that people like me couldn't create issues directly in this project, but a responsible atlassian administrator could move an issue that I raised into this project if I was discovered to be an important customer. Mr Atlassian Admin is carrying out his weekly review and moves 60 issues into this new project - and JIRA requests that he choose a new reporter for all 60 issues. Now you don't know who raised them!

Anyway, I think you understand my point. I would be very grateful if you could investigate this issue... :)

T

[tominwood]

PS. I already raised an issue for this: https://jira.atlassian.com/browse/JRA-26883 :)

(Although I strongly believe that this is a bug - as opposed to me misusing JIRA)

[Jeremy Largman]

Ah, right, of course, a 3rd person is doing the moving. Sorry it took me so long to follow you! I see now, this is not a permissions issue.

Allright, last try - perhaps you could open the 'create issue' permission to the other projects, but hide those projects from the create issue dropdown. Let me know if this is of interest, I can check it and update it if its outdated:

http://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission

[tominwood]

I don't think that is an appropriate solution either... You are able to create issues from several different places (the top right hand corner link, the issues drop down, the project screens). I don't want to hack all of these pages (making the product more difficult to maintain and support). Also, we have a complex permissions scheme - and I don't want to have to amend permissions in more than once place.

I still can't see why this shouldn't be treated as a bug. No-one seems to be able to explain why the reporter should ever unexpectedly change when issues are moved between projects - it just doesn't make any sense at all! I can't understand why this should be a complicated issue to fix. We have paid for an unlimited user license for both Jira and Confluence (at a cost of $20000) - and I think it is reasonable to expect Atlassian to resolved ssues like this (or provide a genuine reason why not)

:(

[tominwood]

Still having this problem when users move issues between projects. The "Reporter" field is used to identify the person who raised the issue - so it really makes no sense that this should ever change (due to permissions or for any other reason). Why is this happening Atlassian?!?!?!?!?!?!?!?!??!?!?!!?!?!??!?!?!?

[tominwood]

I guess the answer is, that JIRA doesn't make much sense in the way that it manages the Reporter field.

[tominwood]

I guess the answer is, that JIRA doesn't make much sense in the way that it manages the Reporter field.

[Kai Honsel]

Hi Tom

We have the same setup and experienced the same problem. The user that moves an issue must not only have the move issue permission on the source project, but also the create issue and modify reporter permission on the target project. Since we added the modify reporter permission on the target project, the reporter is not changed anymore. Hope that works for you, too!

Regards,

Kai