Edgewall Software

Changes between Initial Version and Version 7 of Ticket #525


Ignore:
Timestamp:
Jan 18, 2006, 10:36:07 AM (16 years ago)
Author:
Christian Boos
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #525

    • Property Status newassigned
    • Property Cc rhind@… added
    • Property Component generalticket system
    • Property Milestone1.0
    • Property Owner changed from Jonas Borgström to Christopher Lenz
  • Ticket #525 – Description

    initial v7  
    44
    55Bugzilla 2.17.7 currently implements such functionality in the following way (see http://landfill.bugzilla.org/bugzilla-tip/):
    6 - first, the user performs a query
    7 - on the resulting bug list page, there is a link at the bottom of the page: "Change several bugs at once"
    8 - 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.
    9 - the user selects the bugs to batch modify
    10 - the user modifies the fields needed to be changed in the fields at the bottom of the page
    11 - the user clicks "commit"
     6 * first, the user performs a query
     7 * on the resulting bug list page, there is a link at the bottom of the page: "Change several bugs at once"
     8 * 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.
     9 * the user selects the bugs to batch modify
     10 * the user modifies the fields needed to be changed in the fields at the bottom of the page
     11 * the user clicks "commit"
    1212
    1313Why would such functionality be useful?  Here are some example scenarios:
    14 - 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.
    15 - 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.
     14 * 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.
     15 * 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.