Closed Bug 268466 Opened 20 years ago Closed 20 years ago

add option 'letsubmitterchoosetargetmilestone' to specify target milestone on bug create

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 99567

People

(Reporter: jsalter, Assigned: myk)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Should have an option to allow target milestone to be specified during bug creation - by default this option is 'off'. This is use for internal projects where multiple users actually pay attention to what milestones there are and knows which a bug needs to go to. In particular, this is useful for sustaining/maintenance teams. The following code provides this capability: template/en/default/bug/create/create.html.tmpl: <td> <input name="assigned_to" size="32" value="[% assigned_to FILTER html %]"> <noscript>(Leave blank to assign to default component owner)</noscript> </td> + [% IF Param('letsubmitterchoosetargetmilestone') %] + [% sel = { description => 'Target Milestone', name => 'target_milestone' } %] + [% INCLUDE select %] + [% END %] </tr> enter_bug.cgi: # attempt to fill-in the target milestone values # $vars->{'target_milestone'} = $::target_milestone{$product} || []; if (formvalue('target_milestone')) { $default{'target_milestone'} = formvalue('target_milestone'); } elsif (defined $cgi->cookie("VERSION-$product") && lsearch($vars->{'target_milestone'}, $cgi->cookie("VERSION-$product")) != -1) { $default{'target_milestone'} = $cgi->cookie("VERSION-$product"); } else { $default{'target_milestone'} = $vars->{'target_milestone'}->[$#{$vars->{'target_milestone'}}]; } data/params: 'letsubmitterchoosetargetmilestone' => 1, defparams.pl: { name => 'letsubmitterchoosetargetmilestone', desc => 'If this is on, then people submitting bugs can choose an ' . 'initial target milestone for that bug. If off, then all bugs ' . 'have the default target milestone selected for that product.', type => 'b', default => 0 }, Reproducible: Always Steps to Reproduce: 1. Enhancement request. 2. 3. Actual Results: A drop-down list with the available target milestones is made available during bug creation.
Change enter_bug.cgi to retrieve the product-specific target milestone: ... $default{'version'} = $vars->{'version'}->[$#{$vars->{'version'}}]; } + my $milestone; + SendSQL("SELECT defaultmilestone FROM products WHERE name= " . SqlQuote ($product)); + $milestone = FetchOneColumn(); + # attempt to fill-in the target milestone values + # + $vars->{'target_milestone'} = $::target_milestone{$product} || []; + if( $milestone ) { + $default{'target_milestone'} = $milestone; + elsif( formvalue('target_milestone') ) { + $default{'target_milestone'} = formvalue('target_milestone'); + } elsif (defined $cgi->cookie("VERSION-$product") && + lsearch($vars->{'target_milestone'}, $cgi->cookie("VERSION-$product")) != - 1) + { + $default{'target_milestone'} = $cgi->cookie("VERSION-$product"); + } else { + $default{'target_milestone'} = $vars->{'target_milestone'}->[$#{$vars->{'target_milestone'}}]; + }
Do we want this? Actually, the reporter is not allowed to edit the target milestone, unless he has editbugs privs or is the owner or assignee of the bug: http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi#470 # - change the target milestone if ($field eq "target_milestone") { return 0; } In this case, this should be modified as: # - change the target milestone (unless he could have set it originally) if (($field eq "target_milestone") && !Param('letsubmitterchoosetargetmilesetone')) { return 0; } If the reporter can set the target milsetone on bug creation, he should also be able to modify it afterwards. This could be discussed as part of bug 90619.
Depends on: 90619
A scenario for us as to why this is a useful option is as follows: Customer support has a call logged against them of a problem. Sustaining/Maintenance verifies the problem exists and opens internal bugs against engineering which has target milestones of 1.1 and 1.2 (but not 1.0). Not having the option to specify target milestones makes it one extra step to actually assign the bug to the correct version. It's possible that this could be limited to a 'group' (for example, support or maintenance) rather than have it be a global option. I hadn't thought of that until just now.
Why defining a new parameter then? We could say that users with editbugs privs have the ability to choose the target milestone on bug creation (that is, the UI displays such an option), but is unavailable (hidden) for general users. In the case you mention, it appears that your Maintenance team *has* such privs. And so, we do not give more rights to users, but only decrease the number of steps necessary to set the milestone by one. Is that a conveniable solution for you?
Hmmm... I was going to confirm this bug, but I found another bug already asking for this feature. Marking as a dupe of it. *** This bug has been marked as a duplicate of 99567 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
No longer depends on: 90619
Resolution: --- → DUPLICATE
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.