Batch Modification Functionality

[anonymous]

The following is a request for enhancement.

I recommend that Trac implement batch modification functionality. This would allow users to modify several fields of several tickets that match a certain criteria in a single process.

Bugzilla 2.17.7 currently implements such functionality in the following way (see ​http://landfill.bugzilla.org/bugzilla-tip/):

• first, the user performs a query
• on the resulting bug list page, there is a link at the bottom of the page: "Change several bugs at once"
• on following that link, the same bug list reappears with a checkbox in front of each bug (this allows the user to hand pick a subset of the bugs to modify). This page also contains all the fields in a bug at the bottom of the page. Each of the fields contains a, "—do_not_change—" value by default.
• the user selects the bugs to batch modify
• the user modifies the fields needed to be changed in the fields at the bottom of the page
• the user clicks "commit"

Why would such functionality be useful? Here are some example scenarios:

• There's a milestone titled "Next Mainstream Loadbuild". Thus, when a designer closes an issue in the main stream / trunk, they don't need to know the number of the next loadbuild, they simply use the "Next Mainstream Loadbuild". Then, upon the next successful loadbuild, the loadbuild guy can do a batch modification, changing all issues that are closed and have a milestone of "Next Mainstream Loadbuild" to the actual build number. VERY USEFUL. The designers don't need to be intimate with every single possible build number / milestone.
• Another scenario: management has decided that all unresolved issues that were targeted to be addressed in load x are now to be targeted for load y. A batch modification would make this job a single task, as opposed to n tasks.

[daniel]

Thanks for the references, and presenting the idea. Seems cool.

[brianhv]

I think a more convenient UI would be to have a drop-down in every row for columns that the user wants to affect. For example, a priority-editing query would have drop-downs in the priority column for each row. That way, one ticket's priority could be lowered at the same time another's is raised.

[Christopher Lenz]

In my opinion, batch updates of tickets would be a good fit for the query module. How exactly the functionality is made available in the UI is up for discussion. I personally like the "edit each row via <select> or <input type=text>" better than the bugzilla approach.

[Christian Boos]

#2623 has been closed as a duplicate of this one.