310120 - Reassign Bug to Reporter upon Resolution

Status: RESOLVED WONTFIX

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

Description

[Brian Moran]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: 

This is a hybrid of 92549 92515 and perhaps 226357 -- doesn't have the 
flexibility of all of those, but does a little of what is wanted. 

This patch remedies the necessity of 'reassigning' a bug back to the reporter 
then resolving it (once a bug is resolved, it can't be reassigned).  In our 
organization, a developer fixes a bug, and the bug is reassigned back to the 
reporter so that they can verify the bug is truly fixed.

Patch Summary: 
One-step resolution and reassignment of a bug back to the reporter for 
verification, and (hopefully) closure. Deltas of few lines in two files. 


Reproducible: Always

Steps to Reproduce:
1. Reporter "Foo" creates bug against developer "blech"
2. Developer "Blech" fixes bug. Resolves "fixed". Bug still assigned 
to "Blech", so "foo" doesn't verify the bug is fixed (unless the're really on 
top of things)

Comment 1

[Brian Moran]

Attachment: Patch to process_bug.cgi and templateen/default/bug/knob.html.tmpl

Hi, hope this is useful to others besides us. This was against 2.18.

Comment 2

[Brian Moran]

OOps,fix misspelling in title

Comment 3

[Frédéric Buclin]

Comment on attachment 197493 [details] [diff] [review]
Patch to process_bug.cgi and templateen/default/bug/knob.html.tmpl

It looks like there is a lot of code duplication; that's not good.

Moreover %::FORM has been completely removed from the code.

Comment 4

[Brian Moran]

I would love to have the time to create a patch against >2.18. The version of 
2.18 that we have is sprinkled with %::FORM.

Re: Code duplication - utility outweighed brevity. Perhaps in the near future 
we'll do something with version >2.18, in which case we'll also likely have 
the luxury of becoming more terse.

Comment 5

[Brian Moran]

Attachment: The Resolve-and-Reassign patch against 2.20

This latest patch is against 2.20; It addresses all concerns in the previous
comments (no references to FORM, reuse of 12 lines of code in a case statement,
etc.)

Comment 6

[Dave Miller [:justdave]]

Comment on attachment 198398 [details] [diff] [review]
The Resolve-and-Reassign patch against 2.20

As a nit, this patch is backwards...  it removes the feature from your patched
version instead of adding it to 2.20.

I think this is great for sites whose process works this way.  In general I'm
not sure it should go in; maybe this should be one of those things where we
keep track of it and point people at the patch on this bug when they want it. 
My mail problem with it is additional UI bloat on a section of the page that's
already overly complicated.

Maybe getting this feature in for real should be the job of one of the UI
hackathons to come up with a clean way to do it...

Comment 7

[Dave Miller [:justdave]]

s/mail/main/ in the above comment.

Comment 8

[Frédéric Buclin]

I would never accept a patch which reassigns bugs to reporters when closing them. But what would make more sense is a way to specify what should be done when closing a bug, maybe in some admin page, such as:

"When a bug is marked as RESOLVED FIXED, the following option can be executed automatically:

- reassign bug to <select>reporter, qa contact (for verification), default assignee, ...</select>
- mark the bug as confirmed (everconfirmed = 1) (that's bug 99251)
- ask the user to set the target milestone if the default one is selected
- etc....

Comment 9

[A. Karl Kornel]

(In reply to comment #8)
> I would never accept a patch which reassigns bugs to reporters when closing
> them. But what would make more sense is a way to specify what should be done
> when closing a bug, maybe in some admin page, such as:

Agreed.

> "When a bug is marked as RESOLVED FIXED, the following option can be executed
> automatically:

Assuming that workflows end up being implemented as I expect, you could have a workflow transition that sets everconfirmed and forcibly reassigns a bug to someone.

At this point I'd say WONTFIX, since I wouldn't want this to be the default.

Comment 10

[Max Kanat-Alexander]

Yes, this is a fairly common request from corporate organizations.

Probably it will be implemented as part of a larger "do actions on workflow changes", but it's still OK to have a bug for it.

Comment 12

[Frédéric Buclin]

This won't be implemented in the core code. There are way too many requests of this form which can be make, e.g. reassign the bug to the QA team when resolved, set such or such field to such or such value when... etc.... The right place for this is in an extension.