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)
Bugzilla
Creating/Changing Bugs
Tracking
()
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.
Reporter | ||
Comment 1•20 years ago
|
||
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'}}];
+ }
Comment 2•20 years ago
|
||
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
Reporter | ||
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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?
Comment 5•20 years ago
|
||
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
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•