503127 - Separate configuration for "default on bug entry" versus "no milestone set" values in target milestone field

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

Description

[Erik Magana]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Texas Instruments; [R1 1.3]; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: Bugzilla_3.2.3

User is getting the "milestone_required" user error when changing a bug in Assigned state. Milestone field is correctly set with the products current default milestone.


Reproducible: Always

Steps to Reproduce:
1. set usetargetmilestone = true
2. set musthavemilestoneonaccept = true
3. set product default milestone equal to a value other than '---'
4. create multiple milestones, ensuring one of the milestones is set as the default milestone for the product.
5. submit a bug.
6. assign the bug using the default target milestone as the target milestone
Actual Results:  
milestone_required user error thrown

Expected Results:  
bug updates


Issue is in Bug.pm line 1005 of Bugzilla_3.2.3 version. 

Suggestion update line 1005 to say:
&& $invocant->target_milestone eq '---')
instead of :
&& $invocant->target_milestone eq $product->default_milestone)

Comment 1

[Frédéric Buclin]

The goal of musthavemilestoneonaccept is to ensure that bugs marked as ASSIGNED have a milestone different from the default one. '---' is not a magical milestone. The current behavior is by design.

Comment 2

[Erik Magana]

Attachment: Admin Products Edit Screen

This image shows that a default milestone can be set for any particular product.

Comment 3

[Frédéric Buclin]

I know that, and that's exactly my point. --- is nothing special.

Comment 4

[Erik Magana]

Frederic,

I completely agree if musthavemilestoneonaccept = true then yes a target milestone should not equal "---". However that is not the scenario.

I have defined a valid milestone for my product to be my default, in addition when creating the product, originally, I overwrote the milestone from the default value of "---" to "M1". I also added additional milestones to that product, but for my current work the current default milestone i have set for all is "M1".

The design of the code is only accurate if the creator of a product leaves the Product's default milestone set to "---", which is not the case in my scenario.

Comment 5

[Frédéric Buclin]

You don't use the musthavemilestoneonaccept parameter correctly in your scenario. If you want to accept bugs to be ASSIGNED despite being set to the default milestone, then don't use this parameter.

Comment 6

[Erik Magana]

The purpose of the musthavemilestoneonaccept parameter is to ensure that people accepting bugs provide a milestone for completion. That is our intent in using this parameter. 

I have been thorough enough to ensure that the milestone field does not prepopulate with "---"; however other users with permissions to create products may not be as thorough and in those instances where the default is set to "---", then and only then will the designed code work properly.

Question #1: Why provide a dropdown box with default milestone in the Product edit screen? Especially if changing the default milestone contradicts the musthavemilestoneonaccept parameter when accepting. 

I believe this issue is not invalid and can provide valid scenarios where the code by design was not taken into account.

Comment 7

[Dave Miller [:justdave]]

The defaultmilestone option on a product is setting which milestone is considered "no milestone has been set yet".  The default provided option for this is '---' but some people like to be more explicit and make it something like 'untargeted' or make it something in some other language.

The problem here is that "the unset milestone" and the "default milestone on the bug entry form" are tied to each other at the moment, and what you're really asking for is a distinction between the two.

Comment 8

[Dave Miller [:justdave]]

Erik: for a local workaround in your situation, you could edit Bugzilla/Bug.pm around line 985, which currently has this:
(assuming you're running Bugzilla 3.2.x)

    if (ref $invocant && $new_status->name eq 'ASSIGNED'
        && Bugzilla->params->{"usetargetmilestone"}
        && Bugzilla->params->{"musthavemilestoneonaccept"}
        # musthavemilestoneonaccept applies only if at least two
        # target milestones are defined for the product.
        && scalar(@{ $product->milestones }) > 1
        && $invocant->target_milestone eq $product->default_milestone)
    {
        ThrowUserError("milestone_required", { bug => $invocant });
    }

and replace $product->default_milestone with '---'

Comment 9

[Frédéric Buclin]

Per bug 399078, I doubt we will do this.

Comment 10

[Erik Magana]

Frederic,

I have already implemented the workaround (see my description under suggestion). I brought it up here because the design seems to be prone to much misinterpretation. 

When originally seeing the dropdown default product milestone option, my initial thoughts were not that it was to be used to identify the default value that is not allowed to be selected as a milestone. My initial interpretation was that this resettable default value can be used to help ensure that the correct milestone is selected when used properly in conjunction with the musthavemilestoneonaccept parameter.

If a distinction wants to be created between "unset" milestones and "default" milestones I'd like to recommend the following two options.

Option #1:
Add a checkbox to the milestone edit form "Milestone Ended". This option will of course need to ensure that when a product is created if "---" is used then the checkbox is automatically checked.

The benefit here is that you can create multiple milestones and as time passes through your programs and those milestones are reached you can "End" them so that users accepting future work don't set the target milestone to one that is no longer applicable. The Bug.pm code can then do a boolean check on "Assign" (line 985) to see if the milestone is "not ended"

Option #2:
Add a date to the milestone form of when the milestone will be reached. It similar to option #1 except that you provide a date for when the milestone will no longer be acceptable as input. This option is preferable because the user community can then query for open bugs where the milestone date has expired and these bugs can then be reevaluated.


I believe either of these two options would make Bugzilla more flexible in allowing users to accept proper target milestones for their bugs. In my environment we currently have three milestones per product and one of them will be reached in the coming weeks.

Comment 11

[Tom Ryan]

This is an issue for us because one set of products needs to use  "musthavemilestoneonaccept" and one set of products does not. The way we planned to get around this was to define a default milestone for the products where we don't want to require a milestone on accept.