474974 - Workflow should allow exceptions to comments required on status transitions for special resolutions (e.g. duplicate)

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Matt McHenry]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: 

I'm entering this bug as an alternative to bug 463453, which was lamenting the loss of the commentonduplicate parameter.  This is a regression from 3.0 to 3.2.

If the desire is really to control all the commenton* stuff via the workflow interface, then I think that an exception mechanism is needed for special resolutions whose comment-on behaviour ought to be different from the norm for a particular status transition.

Like the reporter of the earlier bug, our site had commentonresolve=true and commenonduplicate=false, and that combination worked well for us.  I'll reiterate the point in bug 463453 comment 2: bugzilla is already adding a comment for you when you resolve a bug as a duplicate.  When the duplicate-ness is blindingly obvious (as is usually the case) forcing an additional comment is a waste of time.  Indeed, if it's not obvious, we usually leave both bugs open and link them with a dependency.

Reproducible: Always




I'd be happy with just reopening bug 463453, but it looks like there's consensus there from the main contributors that it's properly marked wontfix.

Comment 1

[Scott Weber]

I am also annoyed by this change in the behavior enforced by the workflow and completely agree with the concerns raised in this and related bugs.  I am not willing to turn the requirement for a comment on transition to RESOLVED off, because I absolutely want a comment for the other resolutions.  So, this means that every time a duplicate is marked in the system the user inevitably gets the error message about a comment being required and then puts something pointless like "duplicate" in the comment box.

While this extra comment doesn't really hurt, it is also a waste of space and a waste of time and a duplication of effort.

Comment 2

[Denis Roy]

(In reply to comment #0)
> I'm entering this bug as an alternative to bug 463453, which was lamenting the
> loss of the commentonduplicate parameter.  This is a regression from 3.0 to
> 3.2.

+1.  This is a regression.

Comment 3

[Frédéric Buclin]

OK, I agree. As I still want to kill the commentonduplicate parameter, I will confirm this bug rather than reopening bug 463453.

Comment 4

[Matt McHenry]

Is b.m.o already doing this?  I just noticed that bug 105597 comment 18 marks resolves that bug as a duplicate, but doesn't contain any text other than the standard boilerplate.  Or does b.m.o have commentonresolve=false?

Comment 5

[Frédéric Buclin]

(In reply to Matt McHenry from comment #4)
> Is b.m.o already doing this?  I just noticed that bug 105597 comment 18
> marks resolves that bug as a duplicate, but doesn't contain any text other
> than the standard boilerplate.

Looks like you misread what bug 105597 is about. Did you look at the patch there? It's not about custom boilerplate but about tagging comments, which is quite different.

Comment 6

[Matt McHenry]

No, I'm not interested in the content of bug 105597 at all -- just the fact that you seemed to be able to mark it as duplicate without entering a vacuous comment.  :)

Comment 7

[:glob ✱]

(In reply to Matt McHenry from comment #4)
> Or does b.m.o have commentonresolve=false?

commenton* is set to off on bmo