Opened 20 years ago
Last modified 23 months ago
#525 closed enhancement
Batch Modification Functionality — at Version 7
Reported by: | anonymous | Owned by: | Christopher Lenz |
---|---|---|---|
Priority: | normal | Milestone: | 1.0 |
Component: | ticket system | Version: | 0.7.1 |
Severity: | major | Keywords: | review batch-modify |
Cc: | pkou@…, rjack@…, mat@…, david@…, erikand@…, garyo@…, chad@…, dgynn@…, meeker.brian@…, itamarost@…, osimons, ethan.jucovy@…, leho@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
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.
Change History (7)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Milestone: | → 0.9 |
---|
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.
comment:3 by , 20 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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.
comment:4 by , 19 years ago
Milestone: | 0.9 → 1.0 |
---|
comment:5 by , 19 years ago
Component: | general → ticket system |
---|
comment:6 by , 18 years ago
Cc: | added |
---|
comment:7 by , 18 years ago
Description: | modified (diff) |
---|
#2623 has been closed as a duplicate of this one.
Thanks for the references, and presenting the idea. Seems cool.