-
Suggestion
-
Resolution: Low Engagement
-
0
-
8
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
As an example the reporter field may require a value during the bulk issue operation. The reason why the reporter field needs a value is that this field is required. When you check the retain option, the reporters are retained where possible. Depending on your configuration this may not be the case for all issues being moved. For those issue a new (reporter) value needs to be set and that's why the reporter field needs a value set.
JIRA could be a bit smarter & user-friendlier and not require a value in the case when all issues will be able to retain the original reporter. It could also inform the user that if the value is entered and retain option is checked, it will only replace or set the reporter value for the issues that will require it. It would seem that at the moment the current message does not give enough confidence to the users, they fear that all values will be replaced.
Please see linked JRA-14385 for more details about the origin of this issue.
- is related to
-
- Closed
-
- Closed
-
- Gathering Interest
[JRACLOUD-15181] Make bulk move operation more user-friendly during field update stage
Did Atlassian confirm that ? On JIRA 6 there is no way to bulk move issue between projects (where permission have been set) retaining the reporter ?
Sean Kamath
added a comment - Hi.
We just updated to Jira 6.2.7.
I made the sad face when I tried to move two tickets in a bulk move. No change from Jira 3. I guess 26 votes isn't enough to effect change over three major version.
"I believe. I believe. It's silly, but I believe."
Sean
Sean Kamath
added a comment - Hi.
We just updated to Jira 6.2.7.
I made the sad face when I tried to move two tickets in a bulk move. No change from Jira 3. I guess 26 votes isn't enough to effect change over three major version.
"I believe. I believe. It's silly, but I believe."
Sean Sean Kamath
added a comment - Been a while. I thought I would see if the REST API would allow me to move tickets more efficiently, only to run across the fact that there is no REST API to move tickets.
Still wishing . . .
Sean Kamath
added a comment - Been a while. I thought I would see if the REST API would allow me to move tickets more efficiently, only to run across the fact that there is no REST API to move tickets.
Still wishing . . . Sean Kamath
added a comment - Most of these tickets (all of them?) are not assigned. They flow unassigned from HelpDesk to our Department, then from our Department into the individual silo where the work will happen (HelpDesk filters to our Dept, supervisors filter from Dept to the individual groups), and then they sit until someone in the group takes the tickets, when they are assigned.
Thus, hard to move all the tickets assigned to an individual when the tickets are unassigned. 
I go back to my original assertion: It makes no sense to have different semantics/restrictions between moving an individual ticket and bulk moving 2 or more.
Sean Kamath
added a comment - Most of these tickets (all of them?) are not assigned. They flow unassigned from HelpDesk to our Department, then from our Department into the individual silo where the work will happen (HelpDesk filters to our Dept, supervisors filter from Dept to the individual groups), and then they sit until someone in the group takes the tickets, when they are assigned.
Thus, hard to move all the tickets assigned to an individual when the tickets are unassigned.
I go back to my original assertion: It makes no sense to have different semantics/restrictions between moving an individual ticket and bulk moving 2 or more. Still a bit confusing, but if you query JIRA for issues, sort them by assignee and then move issues assigned to the same person at the time - it won't complain. However, I can understand that with 300-700 engineers it may still be an issue...
Sean Kamath
added a comment - I concer with David Randolph.
We have projects that we don't want arbitrary people to be able to report to. So, tickets come in from the help desk, and we want the original reporter on the ticket to remain. Further, we then move the ticket out of the second queue into a third (a targeted team's queue). The upshot, the tickets flow from helpdesk to our department then to the group. From helpdesk to department is OK, since the helpdesk moves tickets one at a time as they come in. But for the dept to group, we supervisors want to bulk move ALL the tickets for our group into our group's queue.
Also, it makes NO sense that I can move a single ticket and retain the reporter, but when I do a bulk-move I must replace the reporter with someone in the "Reporters" role.
Sean Kamath
added a comment - I concer with David Randolph.
We have projects that we don't want arbitrary people to be able to report to. So, tickets come in from the help desk, and we want the original reporter on the ticket to remain. Further, we then move the ticket out of the second queue into a third (a targeted team's queue). The upshot, the tickets flow from helpdesk to our department then to the group. From helpdesk to department is OK, since the helpdesk moves tickets one at a time as they come in. But for the dept to group, we supervisors want to bulk move ALL the tickets for our group into our group's queue.
Also, it makes NO sense that I can move a single ticket and retain the reporter, but when I do a bulk-move I must replace the reporter with someone in the "Reporters" role. 
David Randolph
added a comment - JIRA needs an option to prohibit changing the reporter on such moves. We want reporter always to mean "original reporter." If an issue is being moved and this cannot be retained, we want to stop the move. There doesn't seem to be a way to do this. Even if no users have "Modify Reporter" permission, reporters can still be modified. In fact, if I take away "Modify Reporter" permission in our secure (restricted-access) projects, the reporter is always changed, even if the original reporter is a member of the target project. At least this is the behavior I see when I move a single issue (outside the bulk updater). We are using JIRA 4.0.
David Randolph
added a comment - JIRA needs an option to prohibit changing the reporter on such moves. We want reporter always to mean "original reporter." If an issue is being moved and this cannot be retained, we want to stop the move. There doesn't seem to be a way to do this. Even if no users have "Modify Reporter" permission, reporters can still be modified. In fact, if I take away "Modify Reporter" permission in our secure (restricted-access) projects, the reporter is always changed, even if the original reporter is a member of the target project. At least this is the behavior I see when I move a single issue (outside the bulk updater). We are using JIRA 4.0. 
Frank Stiller
added a comment - It would seem that at the moment the current message does not give enough confidence to the users, they fear that all values will be replaced
Exactly. There are a lot of required fields usually, either it should give you the feeling its for all fields the same or you need to explain, why this one single field is special.
Like Ray already commented, either a list of empty fields would be great (which maybe get updated/replaced) or the actually set elements which could not be retained would be great. The best thing would be to check whether all fields can be retained followed by the message that only empty fields will be overwritten (best followed by the issue keys which have been modified after bulk operation.
This behaviour cost me some days as i had some projects with quite a lot of customization and i didnt wanted to loose data and thats a lot of experimenting if you dont know what the system will retain.
Frank Stiller
added a comment - It would seem that at the moment the current message does not give enough confidence to the users, they fear that all values will be replaced
Exactly. There are a lot of required fields usually, either it should give you the feeling its for all fields the same or you need to explain, why this one single field is special.
Like Ray already commented, either a list of empty fields would be great (which maybe get updated/replaced) or the actually set elements which could not be retained would be great. The best thing would be to check whether all fields can be retained followed by the message that only empty fields will be overwritten (best followed by the issue keys which have been modified after bulk operation.
This behaviour cost me some days as i had some projects with quite a lot of customization and i didnt wanted to loose data and thats a lot of experimenting if you dont know what the system will retain. 
Hi everyone,
Thank you for bringing this suggestion to our attention.
As explained in our new features policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.
Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), this suggestion didn’t make it to the roadmap and we are closing it.
While this issue has been closed, our Product Managers continue to look at requests in https://jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.
Thank you again for providing valuable feedback to our team!