92552 - Separate out reassignment actions.

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Matthew Tuck [:CodeMachine]]

We should separate out the reassignment actions from the standard
status-changing actions.

Basically it should look like this.

...
< > Resolve bug, mark it as a duplicate ...

< > Don't change assignee
< > Reassign bug to ...
< > Reassign bug to default assignee of component

[ ] Reassign bug to default QA of component

Tell me again why assignee and QA work differently?  Sure, assignee has a real
name for the existing value, and can't be blank, but I don't see why we can't
just make the assignee like the QA contact and add a real name to the QA contact.

Or if you prefer, make the QA contact work like the assignee.  Then the above
options would be consistent between the two.

Comment 1

[Matthew Tuck [:CodeMachine]]

Moving to new Bugzilla product ...

Comment 2

[Matthew Tuck [:CodeMachine]]

*** Bug 107581 has been marked as a duplicate of this bug. ***

Comment 3

[benc]

I really need this, because bugs are being moved from one component to another,
but the QA asignment is not changing. When I go back to correct the QA contact,
I cannot use the "Reassign bug to owner and QA contact of selected component",
b/c the ownership has already been sent to a non-default bugzilla user.

So, I have to do all the QA reassignments by hand.

Comment 4

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 5

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 6

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 7

[benc]

This was a pain when I worked for netscape, annoying for working w/ mozilla, and
driving me crazy at my new workplace.

Can someone give rough guidelines/milestones for getting this fixed? I think I
can find all the pieces if I have to.

Comment 8

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

Comment 9

[hacksaw]

We're using Bugzilla as part of a CMM Level 3 compliant process. Due to it's high usefulness, it's use is expanding rapidly. One of our groups really wants to get as close to possible to just working through bugzilla.

We'd like our process to be, take a bug that has been fixed, and assign it to the QA Contact for verification. The bug should then show up as part of that person's assigned bugs.

That way, there isn't a special search. It's just part of the work flow. 

So, how I envision the status list at the end is that when a bug has been marked as fixed, it could be automatically assigned to the QA contact for review, who'd get an email like "This bug has been marked as Resolved:Fixed. Please review the fix and record a comment on it, and then either mark it as verified, or reopen it."

Another thing to consider is that you might actually want to assign two reviewers to it, especially if it is an enhancement.

Comment 10

[Frédéric Buclin]

Attachment: patch, v1

Comment 11

[Frédéric Buclin]

Attachment: patch, v1.1

Comment 12

[Frédéric Buclin]

Attachment: patch, v1.2

Use the same UI for mass-change as for show_bug (i.e. checkboxes besides text boxes).

Comment 13

[Gervase Markham [:gerv]]

Comment on attachment 261284 [details] [diff] [review]
patch, v1.2

r=gerv - looks OK to me.

Gerv

Comment 14

[Frédéric Buclin]

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.358; previous revision: 1.357
done
Checking in Bugzilla/Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.178; previous revision: 1.177
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.99; previous revision: 1.98
done
Checking in template/en/default/bug/knob.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/knob.html.tmpl,v  <--  knob.html.tmpl
new revision: 1.31; previous revision: 1.30
done
Checking in template/en/default/global/userselect.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/userselect.html.tmpl,v  <--  userselect.html.tmpl
new revision: 1.6; previous revision: 1.5
done
Checking in template/en/default/list/edit-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v  <--  edit-multiple.html.tmpl
new revision: 1.41; previous revision: 1.40
done

Comment 15

[Frédéric Buclin]

Comment on attachment 261284 [details] [diff] [review]
patch, v1.2

if there is something wrong, I will let bkor file a new bug. :)

Comment 16

[Yann]

This patch is wrong. 

If bug 123 has status "NEW", and has user X as assignee, if user Y accept the bug, then the assignee is still user X.

Comment 17

[Frédéric Buclin]

(In reply to comment #16)

Unrelated, see my comment in the bug you filed.

Comment 19

[Yann]

Ok, I got fooled by the similarity in label between "Assignee" person and "Assigned" status ;-). These 2 terms are very similar and may create user confusion now that the 2 are split.

One regression though is that I can no longer go from "ASSIGNED" status to "NEW" status, even though the "bug lifecycle" shows this is possible.

Comment 20

[Frédéric Buclin]

(In reply to comment #19)
> One regression though is that I can no longer go from "ASSIGNED" status to
> "NEW" status, even though the "bug lifecycle" shows this is possible.

Yeah, because this transition ASSIGNED -> NEW was only allowed when reassigning bugs, and as they are now decoupled, we no longer accept it (as it was not a "real" transition as it, i.e. you couldn't do it without ressigning bugs). But don't worry, it will come back as soon as my workflow implementation is complete. Watch bug 344965 if you are impatient. :)

Comment 21

[Yann]

(In reply to comment #20)
> (In reply to comment #19)
> But
> don't worry, it will come back as soon as my workflow implementation is
> complete. Watch bug 344965 if you are impatient. :)

Actually, I applied the patch from bug 92552 on my Bugzilla 3.0, because most users here do not understand why assignee and status are linked (which is logical).

In addition, I modified knob.html.tmpl and process_bug.cgi to re-introduce the ASSIGNED -> NEW transition.

I always feel that the status labels in Bugzilla are confusing, so much btw that b.m.o never uses the verified/closed statuses. So I kept the original lifecycle and renamed the statuses/resolutions to:

[% status_descs = { "UNCONFIRMED" => "UNCONFIRMED",
                    "NEW"         => "IN ANALYSIS",
                    "ASSIGNED"    => "IN DEVELOPMENT",
                    "REOPENED"    => "REOPENED",
                    "RESOLVED"    => "COMPLETED",
                    "VERIFIED"    => "IN QA",
                    "CLOSED"      => "CLOSED" } %]

[% resolution_descs = { "FIXED"      => "FIXED",
                        "LATER"      => "FIXED (QA pending)",
                        "INVALID"    => "INVALID",
                        "WONTFIX"    => "WON'T FIX",
                        "DUPLICATE"  => "DUPLICATE",
                        "WORKSFORME" => "WORKS FOR ME",
			"REMIND"     => "RECURRENT",
                        "MOVED"      => "MOVED",
                        "---"        => "---",
                        " "          => " " } %]

Comment 22

[Veda Larson Palmer]

Thanks everyone who worked on this - I think that this will be very helpful.

(In reply to comment #21)

"VERIFIED" => "IN QA" doesn't make sense to me, as VERIFIED means that "QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken."

"LATER" => "FIXED (QA pending)" and "REMIND" => "RECURRENT" don't make sense to me either (although maybe these doesn't matter much because they have been removed (bug 13534), right?)

Comment 24

[Bernd Kuemmerlen]

(In reply to comment #21)
> Actually, I applied the patch from bug 92552 on my Bugzilla 3.0, because most
> users here do not understand why assignee and status are linked (which is
> logical).

How did you apply the patch? I did not manage to do this, there were several rejects which I could not even resolve manually because the code seems to have changed a lot (this is for the BUGZILLA-3_0 version from CVS)

Comment 25

[Bernd Kuemmerlen]

I don't understand the status of this Bug... In which Bugzilla Release has this been fixed? Is it only on the trunk? Is there a patch against Bugzilla 3.0?

Comment 26

[Frédéric Buclin]

The target milestone says "Bugzilla 3.2", so no, this feature is not available in 3.0. You will have to wait for 3.2 or download the unstable 3.1.2 tarball.

Comment 27

[Yann]

(In reply to comment #24)
> (In reply to comment #21)
> > Actually, I applied the patch from bug 92552 on my Bugzilla 3.0, because most
> > users here do not understand why assignee and status are linked (which is
> > logical).
> 
> How did you apply the patch? I did not manage to do this, there were several
> rejects which I could not even resolve manually because the code seems to have
> changed a lot (this is for the BUGZILLA-3_0 version from CVS)
> 

I went through the code of the patch and applied what was relevant to 3.0. Unfortunately, I cannot make a patch out of it, but it was pretty straight forward, though manual. Since then, we entered 3000 bugs and 10.000+ comments, so it is quite safe.

Comment 29

[Max Kanat-Alexander]

Added to the Bugzilla 3.2 release notes in bug 432331.