-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
4
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
When changing an issue type scheme for a project some issues need to be moved to a new issue type.
Currently the assignee field checks if the assignee is assignable in the destination (project and issue type). During the issue type migration the project is the same.
At the moment, if a user was assignable and then lost these permissions, during the move operation the assignee would need to change. This could mean that a lot of issues need to be mdified.
We should consider to never force the assignee to change if the issue is staying in the same project.
At the moment, the reporter field checks for the create issue permission, and requires the reporter field to change if some of the existing reporters do not have this permission. Note, that when doing an issue type migration (changing an issue type scheme) the project stays the same.
We should consider to never force the reporter to change if the issue is staying in the same project or if the user doing the move has the Modify Reporter permission (in teh destination project).
If we do not decide to do the above, then at least present a list of issues and assignees and reporters that have to change during the move (or issue type migration).
- relates to
-
- Closed
-
- Gathering Interest
- mentioned in
-
Page Failed to load
[JRASERVER-16476] Do not force changing the assignee or reporter when keeping the issue in the same project during the move or bulk move operation or issue type migration
Stephen Diamond
added a comment - This is particularly important in our company. We have started undergoing a clean-up of issue types after several years of unnecessary proliferation and I am currently trying to consolidate several issue types together. For example we used to have multiple defect types that I want to regroup under a single type.
However, when converting older projects that include employees who are no longer part of our organisation, I am unable to retain them as assignee or reporter, which is still relevant to some of our reporting. Even reactivating the accounts and ensuring that they can be assigned to an issue, the issue migration is overriding the values with those used during the migration (the retain values check box seems to do nothing for these fields). I am forced to manually restore the reporter/assignee fields, which is not feasible when dealing with over a thousand issues over a dozen different projects.
Stephen Diamond
added a comment - This is particularly important in our company. We have started undergoing a clean-up of issue types after several years of unnecessary proliferation and I am currently trying to consolidate several issue types together. For example we used to have multiple defect types that I want to regroup under a single type.
However, when converting older projects that include employees who are no longer part of our organisation, I am unable to retain them as assignee or reporter, which is still relevant to some of our reporting. Even reactivating the accounts and ensuring that they can be assigned to an issue, the issue migration is overriding the values with those used during the migration (the retain values check box seems to do nothing for these fields). I am forced to manually restore the reporter/assignee fields, which is not feasible when dealing with over a thousand issues over a dozen different projects. As IssueType migration is losing the custom field data which is not mapped to the new issueType of the same project and same issueId
@Wouter- it's the last fail safe scenario, though almost every time migration of issueType works fine, but sometimes if a custom field is left out which is present on the earlier scheme, what approach would you take to sync the custom field data with the latest prod backup to the one present on the new scheme.
hi, Guy Eden, use REST API to sync the data 
thats what i do if i migrate to a new scheme and since i am using Loads of custom fields then there might be a chance that a custom field might be left out.
Guy Eden
added a comment - This is really important.
I have just moved nearly 200 issues to a new project, and now need to manually go through each one to ensure the reporter is correct. No idea why we can't retain the original value.
Guy Eden
added a comment - This is really important.
I have just moved nearly 200 issues to a new project, and now need to manually go through each one to ensure the reporter is correct. No idea why we can't retain the original value. It's a very critical feature, which needs to be implemented ASAP. Being an JIRA admin I can say that the whole user experience while migrating issue scheme is pretty confusing and annoying.
re: integrity of data - we're cleaning up some tickets and editing one field - however the reporter has left the organisation since they reported it. This is not permitted as an error is thrown stating that the reporter is invalid.
If the reporter value does NOT change, it should not re-attempt to validate it.