475409 - Reassigning an assigned bug no longer changes status to new

Status: REOPENED

(Bugzilla :: Creating/Changing Bugs, defect)

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: 

In Bugzilla 3.0, reassigning a bug in the ASSIGNED state changed its status to NEW.  In Bugzilla 3.2, reassigning a bug has no effect on the status.  In my workflow, having a bug in the NEW state means that it's newly assigned to me (either b/c it's newly entered, or because it's been reassigned), and I still need to review it.  So this change means that I'll no longer be able to search for NEW bugs assigned to me and find the ones that I haven't looked at yet.

Reproducible: Always

Steps to Reproduce:
1. Reassign a bug with status ASSIGNED, without touching the Status drop-down.
Actual Results:  
The bug's status remains ASSIGNED.

Expected Results:  
The bug's status should be changed to NEW.

This was brought up way back in 2002 in bug 173341 comment 1, but that bug got resolved along with bug 92552 with no further discussion.  I looked through the bugs in the dependency tree of bug 101179 and couldn't find any mention of this either.

The problem is that the current UI can't distinguish between these two cases:

1) I know exactly what status I want the bug to have after the reassignment, and I've picked it from the status drop-down.

2) I don't care what status the bug has after the reassignment, and I haven't touched the status drop-down at all.

Maybe a bit of javascript that changes the status drop-down to NEW when you click the "edit" link next to the assignee?  Although I don't like the idea of my bug triage workflow depending on whether somebody else has javascript turned on in their browser ...

Comment 1

[Reed Loden [:reed]]

I thought I already filed this, but I agree that the current behavior is wrong.

Comment 2

[Reed Loden [:reed]]

Oh, I filed bug 377534, which is kinda the same issue but not.

Comment 3

[Frédéric Buclin]

We separated both actions on purpose in bug 92552. We won't bring it back. If you want to reassign + change the bug status to NEW, just do it... manually.

Comment 4

[Matt McHenry]

I don't want to do it myself -- I want to require that everyone does it.  If this bug really is invalid, then what is the semantic distinction between NEW and ASSIGNED?

Comment 5

[Matt McHenry]

Having waited a week, reopening to get a response to comment 4.  Apologies if that's not proper process.

Comment 6

[Max Kanat-Alexander]

(In reply to comment #4)
> I don't want to do it myself -- I want to require that everyone does it.

  It would be a relatively straightforward JavaScript customization for your installation.

> If this bug really is invalid, then what is the semantic distinction 
> between NEW and ASSIGNED?

  Well, I personally use ASSIGNED to mean "I'm actually working on this right now." It's all really just up to you--the statuses are just strange symbols that we write with letters, what they mean is up to you. :-)

Comment 8

[Brad Johnson]

Attachment: Quick and dirty patch to change status back to NEW if assignee changes. Does not set status to NEW if assignee is changed when updating multiple bugs at once.

Quick and dirty patch to change status back to NEW if assignee changes.

Comment 9

[Jen Armstrong]

I also preferred how this worked before the change, since I actually used Assigned to mean the same as referenced by Matt and Max.

Since you insist that this new functionality is here to stay, can you please have someone correct the help information under the "A Bug's Life Cycle" page.  Currently, it states the following:
"Assigned To
This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list."

Comment 10

[Frédéric Buclin]

(In reply to comment #9)
> Since you insist that this new functionality is here to stay, can you please
> have someone correct the help information under the "A Bug's Life Cycle" page. 

Please file a separate bug about this if there isn't one already.

Comment 11

[Jen Armstrong]

(In reply to comment #10)
> (In reply to comment #9)
> > Since you insist that this new functionality is here to stay, can you please
> > have someone correct the help information under the "A Bug's Life Cycle" page. 
> Please file a separate bug about this if there isn't one already.

Just to note that the documentation issue is already listed under bug 468655.

Comment 12

[Reed Loden [:reed]]

It's sad that I have to resort to involving the module owner to get a bug fixed that has made NEW and ASSIGNED completely useless. Even mkanat mentioned in comment #6 how he uses ASSIGNED, and this bug makes his use case flawed. This should be fixed.

Comment 13

[Max Kanat-Alexander]

This is a perfectly easy customization to do if you want to do it.

Comment 14

[Brad Johnson]

Act(In reply to comment #13)
> This is a perfectly easy customization to do if you want to do it.

Actually the suggested fix of fixing it via javascript is not going to fix it completely. The hard part that can't be handled in javascript is changing the status to NEW when people reassign in bulk via the "Change Several Bugs at Once".

Comment 15

[Dave Miller [:justdave]]

There's obviously an issue here...  having this not automatically happen effectively removes the distinction between these two states, so if we're not going to put this behavior back, we should probably ship without an ASSIGNED state by default (and let people create that state themselves if they want it).

However, I think a more elegant solution for this (which is more in line with the current philosophy on state transitions) is to allow transition triggers to be defined.  Using that idea, you could kill two birds with one stone...  this one, where if the assignee changes, it goes back to NEW, and NEEDSINFO being the other one, where it transitions back to NEW or ASSIGNED if the reporter adds a comment (or perhaps if anyone adds a comment).  An elegant way to define those triggers would be fun to come up with though.

Comment 16

[Reed Loden [:reed]]

Reopening in response to comment #15.

Comment 17

[Max Kanat-Alexander]

I'm pretty sure we already have a bug for said workflow triggers, and I've actually had extensive discussions with dkl and dwm about them. For now, I'm not going to add *back in* hacky things that are custom to the specific names of the workflow now that we have custom workflows, though. So I'd like for *this particular* bug to stay WONTFIX, and if somebody can find the status-trigger bug, feel free to link it from here.

There is still a definite significant difference between ASSIGNED and NEW that is not in any way diminished by the fact that Bugzilla doesn't automatically do something for you that you are capable of doing yourself.

Comment 18

[Matt McHenry]

Bug 300126 is the only thing I could find with either "workflow" or "trigger" in the summary, and it looks like it's about flags, not statuses.

Comment 20

[H.-J.Schlebusch]

Any progress on this issue?
Moving up to v. 3.4.5 from an old 2.x-version just ruined our company-wide workflows just because of this change.
Decoupling the fields may be nice, but you should have given an option (via administrative preferences) to stick to the former behavior.
We need the old behavior back - for single bug changes as well as for bulk reassignments.
A fix through java-script is not really preferred, this should all be in the perl code.

Comment 21

[Oz]

I would just like to register my support for getting this fixed in some way be that behaviour is reverted, an option to make it work the old way, using the workflow to allow this to be done automatically, whatever, but there needs to be an option for this to happen automatically.

Can I point out that the bugzilla documentation on this site and shipped with the code still says that when a bug is reassigned its status is set back to NEW.  So the product does not even agree with its own documentation.

http://www.bugzilla.org/docs/tip/en/html/lifecycle.html

and from bugzilla's very own documentation for the field (clicking the Assigned To link on this very page) https://bugzilla.mozilla.org/page.cgi?id=fields.html#assigned_to

Assigned To

This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.

Comment 23

[Allauddin Ahmad]

Hi:
We are also having these issues upgrading from 3.0 to 4.2.5
When we change products/components the assignee changes(correct) but the status also changes to ASSIGNED instead of NEW. Previously the new assignee had to accept it to ASSIGNED status for him now it does automatically.
This change is affecting our work flow and we cannot move forward.
Please update if someone find any solution for this.

thanks

Comment 24

[William Gallafent]

I echo the questions in Comment 23.

Our desired workflow means that when the value in “Assigned To” is changed, it is not acceptable for the Status to be IN_PROGRESS any more: it should be changed back to CONFIRMED (or UNCONFIRMED, if this was the previous state of the bug, for historical reasons). This would work in the same way as “Change in «Assigned To» -> reset status to NEW” used to (automatically in a hard-wired way, which I agree is not desirable!) with the old workflow.

I agree with comment 17 that a generic way to assign triggers to a given state transition would be very useful. I have therefore added a quick note to bug 300126 to that effect.

Comment 26

[Ed Morley [:emorley]]

I filed bug 1036834 which was duped here (there is a WIP over there as well).

It seems that some of the objections in this bug are due to a misunderstanding of the request (comment 4, comment 6, comment 15 and comment 16 seem don'#t differentiate between #1 and #2 below) - tweaking summary to be less ambiguous.

To clarify:
1) I agree it is useful to have the bug status and the assignee field partially decoupled, since it allows for the "assign bug to self but only change status to IN_PROGRESS/ASSIGNED when actually working on it" workflow.
2) However, even with that workflow, resetting the bug to have an assignee of nobody but leaving a status of IN_PROGRESS/ASSIGNED does not make sense.

ie:
assignee set + status:IN_PROGRESS/ASSIGNED => OK
assignee set + status:{NEW,UNCO,...} => OK
assignee not set + status:{NEW,UNCO,...} => OK
assignee not set + status:IN_PROGRESS/ASSIGNED => Not expected (and the subject of this bug) [1]/

As far as I can tell, reset_assigned_to() is called when mass-changing bugs, so my WIP in bug 1036834 should cover the mass change case too, right?


[1] Note that if someone *really* wanted this state, they could manually change the status back again after using "reset assignee", or else manually set the assignee to nobody instead of using the reset feature)

Comment 27

[Matt McHenry]

(In reply to Ed Morley [:edmorley] from comment #26)
> It seems that some of the objections in this bug are due to a
> misunderstanding of the request (comment 4, comment 6, comment 15 and
> comment 16 seem don'#t differentiate between #1 and #2 below) - tweaking
> summary to be less ambiguous.

No, my original request intentionally did not distinguish between your #1 and #2.

Bugzilla does not have any real representation of the "assignee not set" state in your table.  In some installations (e.g. b.m.o) the default assignee is a user with special meaning (e.g. [e-mail]) -- but bugzilla itself doesn't know that.  In many installations, including mine, default assignees are actual people (many of whom share dual roles of "primary triager" and "primary developer" for the same component).

So I want all bugs that come onto my list to get reset back to NEW, regardless of whether they came there via someone explicitly assigning them to me or via "reset assignee to default".  In either case, I haven't started working on the bug yet.

I think if we only want to implement this for the "reset assignee to default" case, that ought to be a separate bug (probably bug 1036834 :) ).

Comment 28

[Ed Morley [:emorley]]

Sorry I hadn't fully read the first third of the bug, had just read the later comments. Sounds like my bug shouldn't have been made a dupe, since it's not entirely the same. Sorry for the churn; I'll reopen bug 1036834 :-)