482654 - Cannot REOPEN bugs that went from UNCONFIRMED -> RESOLVED

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Adam Chou]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
Build Identifier: 3.2.2

The bug cannot be reopened because bugs.everconfirmed never gets set to 1

Reproducible: Always

Steps to Reproduce:
1.create a bug whose initial state is UNCONFIRMED
2.Mark the bug as RESOLVED - FIXED
3.attempt to mark the bug as REOPENED
Actual Results:  
REOPENED is not displayed as an option

Expected Results:  
REOPENED is displayed as an option

the "hack" in bug/knob.html.tmpl:38 won't display the option correctly. So either knob has a logic error, sub set_status() has a bug, or  the admin shouldn't be able to go from unconfirmed to resolved when setting bug workflow path.

Comment 1

[Adam Chou]

i should probably also note that in my bug workflow table, i didn't have
resolved  to unconfirmed set. once i added that, i was able to move the status
of the bug to unconfirmed. since there is a workaround, i suppose the severity
could probably be reduced to minor. however, the bug workflow here chart
doesn't make that clear http://www.bugzilla.org/docs/tip/en/html/lifecycle.html
and resolved-fixed implies that the bug was confirmed and just skipped the
step. so not sure how you guys want to resolve it now, but just some thoughts.

Comment 2

[Frédéric Buclin]

As you said, you forbid the RESOLVED -> UNCONFIRMED transition in your status workflow, so the behavior is correct. And the comment right above the workflow matrix says:

"... reopening a bug will only display either UNCONFIRMED or REOPENED (if allowed by your workflow) but not both. The decision depends on whether the bug has ever been confirmed or not. So it is a good idea to allow both transitions ..."

Re-read the last sentence!

Comment 3

[Max Kanat-Alexander]

To be fair, I think that from a user's perspective, this is irrational behavior, even if it is documented on the page. We don't have to fix it immediately, but we should keep the bug open to keep track of the fact that some day this should probably be made more intuitive.

Comment 4

[Frédéric Buclin]

(In reply to comment #3)
> some day this should probably be made more intuitive.

More intuitive how? You explicitly forbird the RESOLVED -> UNCONFIRMED transition.

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> More intuitive how? You explicitly forbird the RESOLVED -> UNCONFIRMED
> transition.

  You mean that *he* explicitly forbade the transition? Yes. And then it still showed up in the list. That's not really intuitive.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
>   You mean that *he* explicitly forbade the transition? Yes. And then it still
> showed up in the list. That's not really intuitive.

Huh? No, UNCONFIRMED isn't listed in the bug status select field if this transition is not allowed.

Comment 7

[Max Kanat-Alexander]

Oh, I see. What he's saying is that when UNCONFIRMED is not a legal transition but REOPENED is, REOPENED is not displayed. That's something we could possibly address.

Comment 9

[David D. Kilzer (ddk)]

Can this be scheduled for an upcoming release?  We just ran into this on bugs.webkit.org.