399078 - Remove the 'musthavemilestoneonaccept' parameter

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[Frédéric Buclin]

Per our discussions at our last 2 Bugzilla meetings, this param should go away. It should always be 0.

Comment 1

[Leo Zelevinsky]

In the bugzilla installation that I administer, I have this param set to 1 and I like it.

It ensures that when one of the members of my team accepts a bug to work on, they must specify which milestone they are working for and that I don't have to afterwards go through the bugs with -- and assign milestones to them.

I did find that it wasn't perfect - they are able to create a new bug and immediately make the status ASSIGNED, in which case they didn't have to / couldn't enter the milestone.

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> I did find that it wasn't perfect - they are able to create a new bug and
> immediately make the status ASSIGNED, in which case they didn't have to /
> couldn't enter the milestone.

That's a known bug, and another good reason to drop this imperfect solution. Moreover, now that bug statuses are customisable, you could rename ASSIGNED to something else and Bugzilla would have no idea what to do with this parameter.

Comment 3

[Bill McGonigle (not currently reading bugmail; please contact directly)]

I agree with Dave Miller's sentiment here:

http://www.nabble.com/Re%3A-Prefs-Removal-Proposal-p12393318.html

this flag is a useful reminder for developers in a non-volunteer bugzilla use case where the organization finds it useful to have an expectation of finish-date upon accepting a bug.  It helps the developers also be realistic about signing up for too much work for a milestone.  

Sure, you could get rid of it and we could just be grumpy at the developers (hey, you forgot to set your milestone flag!) but we prefer to delegate grumpiness to software.

This is not to say it wouldn't be great to generalize the flag->field->value requirements mapping, and if that already exists, by all means deep-six this specific-case feature, and somebody please comment here about the generalized mechanism.

Comment 4

[Max Kanat-Alexander]

  The thing we're looking at here is the limited engineering resources of Bugzilla. This feature doesn't work right--we could continue to maintain it, or we could remove it. Removing it is easier.

  There will be a generic mechanism in the future to deal with this, but it doesn't exist now. So for a few versions of Bugzilla, this would have to be a local customization. With the way the code will be in 3.2, it actually wouldn't be that hard of a customization, I think (though I'm not certain).

Comment 5

[Ian Roberts]

I concur with Leo Zelevinsky's comment 1.  We also make use of this feature for the same reason.

I think if you are going to remove this feature, you should ensure that there is some (documented) way of easily customising to give equivalent functionality.

Comment 6

[Simon Green]

Attachment: bug399078-v1.patch

Comment 7

[Gervase Markham [:gerv]]

Comment on attachment 8638897 [details] [diff] [review]
bug399078-v1.patch

Review of attachment 8638897 [details] [diff] [review]:
-----------------------------------------------------------------

I have no particular love for this option, but it is true that it's difficult to implement in an extension, because the bug_check_can_change_field hook has access to the bug's current values, but it doesn't have access to the _other_ changes which are being made at the same time. So it's not possible to say "allow changing field X only if field Y is a certain value", because it won't catch the case where Y is being changed to that value in the same change that X is changing.

We had two objections to this change eight years ago. But in my view, it's a very obscure and specific feature, and requires the hard-coding of statuses which I don't like. So in balance, let's kill it.

BTW, love the new email address, Simon :-)

Gerv

Comment 8

[Simon Green]

(In reply to Gervase Markham [:gerv] from comment #7)
> I have no particular love for this option, but it is true that it's
> difficult to implement in an extension, because the
> bug_check_can_change_field hook has access to the bug's current values, but
> it doesn't have access to the _other_ changes which are being made at the
> same time. So it's not possible to say "allow changing field X only if field
> Y is a certain value", because it won't catch the case where Y is being
> changed to that value in the same change that X is changing.

You can put this in the hooks for Bugzilla::Bug's create and update functions to catch violations. I know that Red Hat Bugzilla have done this for selected products, cause I wrote the code :) In our case, we only wanted it for certain products, so had to use an extension.

> BTW, love the new email address, Simon :-)

Thanks :)

Comment 9

[Simon Green]

To ssh://[e-mail]/bugzilla/bugzilla.git
   d373bb1..f578f79  master -> master

Comment 10

[Leif Gruenwoldt]

(In reply to Gervase Markham [:gerv] from comment #7)
> We had two objections to this change eight years ago. But in my view, it's a
> very obscure and specific feature, and requires the hard-coding of statuses
> which I don't like. So in balance, let's kill it.

Sorry for the late comment, I just stumbled on this.

Life would go on without the "musthavemilestoneonaccept" parameter... but I've found it very useful for helping enforce my workflow in my group. Like many I think, we consider the "---" milestone a backlog and carefully pick a set of bugs out of that to assign to a milestone before we begin working on those bugs. This parameter acts as a nice safety feature to ensure we don't begin working on a bug that was unplanned. Otherwise doing so may have consequences like blowing a schedule or losing focus.

I understand now that the original implementation of the parameter had issues, maybe a better implementation could be found.

A proposal I have is to add a new field like "is_accepted=true/false" to the Status and Bug. This would be similar to the "is_closed" field if I understand how that works (the Bug seems to pick up the "is_closed" value from the Status it's in e.g VERIFIED has is_closed=true).

Getting back to the proposal, if the Bug has "is_accepted=false", "milestone=---" and the global param "musthavemilestoneonaccept=true" then the bug wouldn't be able to move to a Status that has "is_accepted=true" (e.g. IN_PROGRESS).

In the default bz lifecycle these Statuses would have the following "is_accepted" values:

UNCONFIRMED, CONFIRMED: false
IN_PROGRESS, RESOLVED, VERIFIED: true

Thoughts?

Comment 11

[Leif Gruenwoldt]

(In reply to leifer from comment #10)
> then the bug wouldn't be able to move to a Status that has "is_accepted=true"
> (e.g. IN_PROGRESS).

Correction: *would* be able to move.

Comment 12

[Leif Gruenwoldt]

(In reply to leifer from comment #11)
> (In reply to leifer from comment #10)
> > then the bug wouldn't be able to move to a Status that has "is_accepted=true"
> > (e.g. IN_PROGRESS).
> 
> Correction: *would* be able to move.

Ah never mind. I was right the first time.

Comment 13

[Gervase Markham [:gerv]]

leifer: you can implement whatever policy you like by hooking "bug_end_of_update".

https://www.bugzilla.org/docs/5.0/en/html/api/Bugzilla/Hook.html#bug_end_of_update

Gerv