Opened 20 years ago
Last modified 22 months ago
#525 closed enhancement
Batch Modification Functionality — at Initial Version
Reported by: | anonymous | Owned by: | Jonas Borgström |
---|---|---|---|
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
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.
Note:
See TracTickets
for help on using tickets.