Hi derek.wailes1, you are welcome We are glad to have helped with this fix.

This fix has already been released in JIRA 6.4.1 which is available for download at http://www.atlassian.com Hope you can upgrade your instance soon

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Thank you for fixing this painful bug. Look forward to seeing it released.

I forgot about that little treasure until you mentioned it . I remember when I first encountered this that it gave me the ambiguous option to "Retain" because "some" issues couldn't be moved automatically.

As an admin about to pull the trigger on a move operation like this, this is a VERY scary and non-helpful message. How do I know which ones were retained, and which ones were not? What information isn't being retained? Will it still be in the history? I would much rather things be moved and unchanged and sort out how that breaks things (like the assignee not having permission to access the issue) than have things be changed and not know what.

I think a good JIRA implementation would have checks in place for this type of issue. For example, the manager of projects in our JIRA instance has a dashboard that shows them issues which haven't been touched for X time. This provides a very easy way to catch issues where the assignee is not following up on things. This could be due to the assignee ignoring the system, not understanding the system, or not having access.

In other areas, the bulk operation utility does a great job of letting the user know what is going on. I'd love to see this part upgraded to match.

I agree with a warning to highlight the risk, but I feel like this is simply a responsibility that comes with having the permission to do bulk re-assignment of issues.

Fair point.

In addition, I now realise that by default if at least one issue has an "invalid" Assignee, then Bulk Update will want to change all the issues
( Unless you tick "Retain" which means "retain values when possible, but change ones that need to move".
Presumably the "Retain" option should be on by default, or the checkbox removed with "retain" as hard-coded behaviour ???
But that is another issue for another day ... anyone know if this is already raised somewhere? )

And finally given that we "force" a change rather than "suggest" a change, this does seem drastic.

So I have come around to thinking that we don't do any checks at all on Reporter or Assignee.
Reporter already works like this due to JRA-9604.

I think any issues regarding "the user may not have access to it after..." are not really an issue. The current solution we have requires us to change the reporter/assignee AND move to another project. This runs the exact same risk of the original user not having permissions in the new project, and it's not obvious who was the reporter/assignee before the change.

As for the issue with the assignee potentially being inaccurate, this is an obvious issue when changing reporter in any bulk operation. I agree with a warning to highlight the risk, but I feel like this is simply a responsibility that comes with having the permission to do bulk re-assignment of issues. However, if the permission is too "wide-reaching" for these specific cases, perhaps the permission needs to be split? Though, I know Atlassian tries to minimize how many permissions there are in JIRA.

Let me try to clarify this behaviour so that we can better understand it and consider all implications of the proposed change:

• JIRA is not explicitly checking if the assignee / reporter is inactive
• What we check is if the said user has permission to be an assignee in the new project (or has permission to create issues in the new project)
• This is to stop the Move operation from being a backdoor to break the permission rules, or from putting the issue into a "bad state"
• Now, it so happens that an inactive user has NO permissions, even though she can belong to groups
  So the permission check will always fail.

So when thinking about changes in behaviour, we need to consider how it affects permission checks in general, not just the inactive user case.

With that in mind, lets consider the ramifications of this change:

Reporter

I have to agree with the sentiment of other commenters here: the reporter is the reporter and should remain intact as part of the audit trail.
(Well actually we also track a separate "creator" field now, but lets not get into that ...)
I think it is mostly harmless to move an issue and leave the reporter intact except under one edge case:
What if the reporter is still active and can view the issue in the current project, but will not be able to view the issue in the new project?
This is very likely to be undesired.
Checking that the reporter has create permission in the new project is overkill.
But if the reporter has browse project permission in the old project but not in the new project ... it is probably a mistake to move the issue?
Best solution would be that the UI shows a warning and lets the admin decide to continue or not.

Assignee

This one is a bit trickier than Reporter in my mind.
If the issue is resolved and you move it to another project then it seems to make sense to leave the historically correct assignee despite permission settings.
But what if the issue is unresolved? Perhaps the assignee is no longer able to see the issue, and so no-one will actually try to fix it?
Other users that can see the issue will see that it is already assigned, so they will happily wait for it to get fixed, not realising that the assignee doesn't even know about it.

In summary, I agree with the general sentiment of the proposed change but I think that the desired behaviour is a bit subtle.
Just removing the permission checks will throw out the baby with the bath water.

Did JRA-9604 not fix this at least for reporter in 6.3?

Thank you Klaus (and support). It is good see that Atlassian are taking some time to improve the administration experience.

Hi all,
after further review of the current behaviour, we agreed it is not the ideal solution for this functionality.
The proposed solution in the description should be the one implemented by JIRA.

It is now part of the bugfix backlog and will be addressed according to the guidelines described here: https://confluence.atlassian.com/display/JIRA/Bug+Fixing+Policy

For additional information, you can see the issues that we are planning to look at in the short-term on this filter: https://jira.atlassian.com/browse/JRA-38772?jql=project%20%3D%20JRA%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20%22Awaiting%20Development%22. (and JRA-34148 is now part of this list)

Regards,
Klaus

Then there must be the option. Simple really. It important that it is fixed. Currently its a pain.