463453 - commentonduplicate is overridden by the bug status workflow when it should be the other way around

Status: RESOLVED WONTFIX

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Vincent Danen]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US) AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v622.3.0.105198
Build Identifier: 

Using 3.2rc1, if you try to close a bug as a duplicate of another bug, and commentonduplicate is off, bugzilla still requires a comment because the status is changing from NEW to RESOLVED (and the workflow requires a comment here).

commentonduplicate should override the values defined in the workflow because it's a special case.  Allowing NEW->RESOLVED without a comment is not a good idea in our case (Mandriva's bugzilla), but we should be able to close as duplicate without adding a comment (bugzilla is, technically, adding a comment for us).

3.0.x allowed for us to close bugs as duplicate without adding a comment.

Reproducible: Always

Steps to Reproduce:
1. set commentonduplicate to off
2. set NEW->RESOLVED requiring a comment in the bug workflow
3. try to resolve a bug as a duplicate without adding a comment

Comment 1

[Max Kanat-Alexander]

The current behavior is intentional, and though I understand why the behavior you're describing would be helpful in your case, it would be very confusing for most people.

Comment 2

[Vincent Danen]

Fair enough, but then doesn't that render commentonduplicate rather useless?  At the very least, there should be a note associated with that setting that the bug workflow settings will override whatever is set there.

I mean, realistically speaking, bugzilla already adds the comment "this is a duplicate of bug #123", so there already *is* a comment.  I can't see what someone would write that would differ much from that.  With the new workflow stuff, that pretty much makes commentonduplicate a redundant/useless configuration option.

Comment 3

[Frédéric Buclin]

(In reply to comment #2)
> Fair enough, but then doesn't that render commentonduplicate rather useless?

Totally, yes. Which is why I have in mind to kill this parameter. Comments should only be controlled by the workflow.

Comment 5

[Matt McHenry]

I've entered bug 474974 as another way to get this functionality back, within the bounds of the new workflow stuff.

Comment 6

[Denis Roy]

You gotta be kidding me.  My users are going from 3.0.x to 3.4 and will need to comment on all duplicates now, despite the parameter?  I haven't been running 3.4 for 12 hours and I already got one of these.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=288058

There's a difference in forcing a comment on a resolution vs. a duplicate.  What do you expect users to say in that comment?

Comment 8

[Frédéric Buclin]

(In reply to comment #1)
> The current behavior is intentional, and though I understand why the
> behavior you're describing would be helpful in your case, it would be very
> confusing for most people.

I don't think this would be confusing. It's just a finer control of the way people have to comment on bugs being marked as RESOLVED. Anyway, I won't reopen this bug, but rather implement bug 474974.