Add ability to require a target milestone when a bug is RESOLVED/FIXED

RESOLVED WONTFIX

Status

()

Bugzilla
Creating/Changing Bugs
--
enhancement
RESOLVED WONTFIX
12 years ago
5 years ago

People

(Reporter: Don Norton, Assigned: Simon Green)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Tablet PC 1.7; .NET CLR 1.0.3705; .NET CLR 2.0.50727)
Build Identifier: 2.20

Much like the musthavemilestoneonaccept, it would be nice to be able to enforce a target milestone when a bug is RESOLVED/FIXED (musthavemilestoneonresolve or musthavemilestoneonfix).  Some work flows don't need the milestone set when accepted, but it would be nice to have the historical record of which milestone the bug was fixed in.


Reproducible: Always
(Reporter)

Comment 1

12 years ago
Created attachment 214244 [details] [diff] [review]
Suggested patch for adoption

Attaching a prototype patch for reference should this enhancement request be accepted.

Comment 2

12 years ago
Comment on attachment 214244 [details] [diff] [review]
Suggested patch for adoption

you have to request review to get your patch in our radar.
Attachment #214244 - Flags: review?
Comment on attachment 214244 [details] [diff] [review]
Suggested patch for adoption

>--- /usr/local/bugzilla/defparams.pl	2006-03-06 13:10:38.000000000 -0800

defparams.pl no longer exists so this doesn't apply to trunk anymore. It's content needs to be split to Bugzilla/Config/BugChange.pm and template/en/default/admin/params/bugchange.html.tmpl template.

>+    desc => 'If you are using Target Milestone, do you want to require that ' .
>+            'the milestone be set in order for a user to RESOLVE/FIX a bug?',

Change end to "RESOLVE ${terms.abug} FIXED."

>--- /usr/local/bugzilla/process_bug.cgi	2006-03-06 15:29:14.000000000 -0800
>+     if ($requiremilestonetoresolve) {
...
>+     }

Please don't duplicate code here, rather move it inside the previous block changing code as necessary.

>  my $requiremilestone = 0;
>+ my $requiremilestonetoresolve = 0;

When combining the block, this global variable could also be combined. One could use values 0=no need to require, 1=require when accepting and 2=require when resolving. These values could then be used to throw correct error in the block.

>--- /usr/local/bugzilla/template/en/default/global/user-error.html.tmpl	2006-03-06 12:52:54.000000000
>+   [% ELSIF error == "milestone_required_on_resolve" %]

Maybe even combine this error with the milestone_required error? Depends on how similar wording it will use in the end..

>+     [% title = "Milestone Required" %]
>+     You must record a target milestone for [% terms.bug %] 

s/record/determine/ and maybe drop target.

>+     if you are going to resolve it. This provides a historical

s/it/it fixed/

>+     reference for where [% terms.abug %] was resolved/fixed.

Hmm, probably "reference for which milestone [% terms.abug %] was fixed."
Attachment #214244 - Flags: review? → review-
Valid enhancement request because no duplicate.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

12 years ago
*** Bug 336620 has been marked as a duplicate of this bug. ***

Comment 6

12 years ago
Comment on attachment 214244 [details] [diff] [review]
Suggested patch for adoption

Note that this doesn't cover bug 329558 which wants it per product, not per installation.
(Assignee)

Comment 7

5 years ago
With the extension code written in 2009 (see revision 6854, bug 430014) this feature is more suited to be written as an extension for the specific need. Instructions on writing extension is available at:

http://www.bugzilla.org/docs/4.4/en/html/extensions.html

The extension you want is the bug_start_of_update hook.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

5 years ago
Assignee: create-and-change → hugo.seabrook
You need to log in before you can comment on or make changes to this bug.