Closed Bug 94247 Opened 23 years ago Closed 17 years ago

Allow reporters to ABANDON bugs

Categories

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

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 148564

People

(Reporter: timeless, Unassigned)

References

Details

(Whiteboard: [people:rep])

Attachments

(1 file, 2 obsolete files)

v3
6.94 KB, patch
LpSolit
: review-
Details | Diff | Splinter Review 
We were talking about why someone would want to CC themselves when they filed a 
bug.  The only reason I could suggest was...
<blockquote src="#mozwebtools">
<style> t {title: timeless}; c {title: caillon}; j {title: justdave};</style>
<li class=t>
Why would you want to cc yourself to a bug you're filing? you will already 
receive bugmail for this bug, however if you really want to, there is a strange 
use for this really whacked out concept, see bugmail prefs mail panel.
<li class=c>
That works?
hm
<li class=t>
eg. i could set myself up to not receive bugmail if i'm the reporter.
but to receive it if i'm a cc for certain categories.
doing so might be useful if i'm really crazy.
<li class=c>
heh
<li class=t>
One instance would be if I'm a prolific filer of bugs that I eventually decide 
I really hate.
Eg if I were kerz or plairo and got stuck having filed the mozilla icon bugs.
<li class=j>
Like the bugs that result in flame wars in the bug comments because the 
developers can't decide how to fix it.
<li class=c>
LOL.
<li class="t critical">
Since there's no 'remove me as reporter' option although i can opt to get mail 
if i'm removed from that capacity.

justdave: what would break if we implemented remove me as reporter?

ie set the field to NULL.
<li class=j>
Probably not a whole lot.
The UI already deals with it in case of deleted userIDs.

sanitycheck will probably complain.
<li class="t critical">
The option would be listed as Abandon bug.

Note doing this will really confuse people, but you may want to do it if 
someone decided this bug was a good place for a flame war or other long 
bugmailspamy argument.
<li class="j critical">
I don't see a problem with it personally, as long as it shows up in the 
activity log who the original reporter was.
<li class="t critical">
Comment: This bug was abandoned by its reporter. If it is ever resolved it can 
not be reopened.

justdave: sure.
<li class=j>
Hmm, I like that idea.
<li class=t>
do i have to file the enhancement request?
<li class=j>
so they'd have to file a new bug to reopen it (thus someone else would be the 
reporter)
</blockquote>

So the feature would:
1. be listed as Abandon bug.
2. only be available to the logged in reporter.
3. cause the reporter field to be null, and appear in the activity log.
4. result in a comment probably of the form: "This bug was abandoned by its 
reporter. If it is ever resolved it can not be reopened.", depending on whether 
we want bugzilla or the reporter to be responsible for the comment...
5. #4 would be binding, bugzilla will forcibly prevent the bug from being 
reopened if it's every resolved. Sanity Check will look for bugs in state 
reopened w/ no reporter and complain loudly. Change several bugs at once would 
of course also object to abandoned bugs being reassigned after resolution.
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.16
Question:
Why should the QA contact, bug owner or persons with EditBugs be prevented from 
reopening a bug, just because the original reporter isn't interested in it any 
more?

If there is already an easily reproducable test case, or the nature of the bug 
is well understood, I don't see why the original reporter's interest or lack of 
it in the details of the ensuing discussion should have any bearing on the 
bug's life cycle.
Abandoning a bug should only be done if the bug is out of control. Bugzilla 
users are usually willing to tolerate small trickles of bugmail so this feature 
is intended for use when they are sick of large delluges of bugmail from a 
specific bug.

Or put another way, I don't like REOPEN much at all. here's the natural course 
of things: a bug is born, it is reported, it is confirmed, it is assigned, it 
is fixed, it is verified. The product ships and the bug is closed.

If some new bug happens which results in the same problem as reported in the 
old bug, it's a _new_ bug.
If a bug is marked invalid, there was probably a good reason.
If the reporter of a bug loses interest, and the bug is resolved as a dupe, can 
you justify reopening the bug?  clearly as filed the bug is dead. Any need for 
a seperate bug to continue the issue should be treated as a seperate bug.
If a bug is resolved wontfix, and the reporter lost interest, then anyone who 
feels the need to reopen the discussion should probably start from scratch 
anyways. @bugzilla.mozilla.org, I'd hope that scratch included a 
news.mozilla.org/netscape.public.mozilla.* discussion or a mozdevday discussion 
or perhaps a logged and well attended irc.mozilla.org discussion.  Whichever it 
is, the bug will be at least slightly different from the original, and the 
focus would be the complicated group consensus and a description of the 
decision making process.

REOPENED 
  This bug was once resolved, but the resolution was deemed incorrect. For
  example, a WORKSFORME bug is REOPENED when more information shows
  up and the bug is now reproducible. From here bugs are either marked

If the reporter of a bug abandons a bug that's resolved as worksforme, then 
it's probably a good time to file a new bug w/ better steps to reproduce.

Later and Remind are excluded from my debate because they aren't resolutions.

If QA or anyone else wants to they are fully capable of filing a new bug, there 
is very little harm in doing so.

testcases and attachments can be referenced by any bug using | attachment 1 [details] [diff] [review] | 
or http://localhost/
Apologies for continuing to nitpick, but:

For unconfirmed bugs, I totally agree with your analysis - a bug that was never 
confirmed, and which the reporter abandoned is dead. Presumably it would 
quickly be VERIFIED INVALID, and left to rot.

IMHO, a confirmed bug is still a bug whether or not the original reporter is 
still interested in it. Reporters (particularly non-technical users) may not 
necessarily need to be involved in any part of a bug after developers have 
confirmed they can reproduce it. There may however be much discussion between 
developers, QA, and third parties who are affected by the same bug, in which 
the original reporter may have no interest.

For other roles (Owner, QA, CC), users can remove themselves when they have no 
further part to play in the discussion. It is not possible for Reporter at 
present. ISTM that was what this bug was about.


If a bug has no reporter (i.e. the reporter abandoned it), then surely it is in 
the same position as a bug whose reporter just fails to respond to any queries -
 if the bug has already been at least confirmed, and no further input is 
required from the reporter, it can continue as normal. If further input would 
have been required, it can be immediately resolved invalid rather than 
requesting and waiting a few weeks for a response.


If REOPENing is a valid action for QA or others to do at all, I don't see that 
it is any less valid on a bug that the original reporter is no longer 
interested in, as other parties may well continue to have an interest.

> If QA or anyone else wants to they are fully capable of filing a new bug,
> there is very little harm in doing so.

AFAICT, this applies equally for any REOPENing whether the bug was abandoned by 
its original reporter or not. If the capability to reopen by anyone other than 
the reporter is removed in this context, the logical conclusion would be to 
remove it in all contexts. This sounds like a separate issue.


It seems strange to give an otherwise unempowered user the power to 
unilaterally close off all effective discussion on a bug, just because they 
happened to report it first. At present, all actions on a bug's state, except 
confirmation, are reversible by anyone at least as empowered as the user making 
the change, and unempowered users cannot make irreversible changes to bugs. 
This proposal as it stands would change that model.

If the field is simply blanked, and the bug reaches a situation where further 
feedback would normally be required from the reporter, then the owner/triager 
can immediately resolve it invalid instead, if the reporter didn't already. 
This solves the problem of reporters being unable to be removed from specific 
bugs. Why complicate it further with technical restrictions of this type?
*shrug*. it seemed like a good idea at the time. for now we can implement basic 
abandoning and have a debate about the future of REOPEN some other time.

My view was that the only need for Abandoning bugs was when they had gotten out 
of hand, this was part of the premise.  Giving the reporter a bit of 
power seemed perfectly reasonable to me.  If i report a bug about X, and 
someone hijacks it to focus on Y which is very opposed to X, why shouldn't I be 
able to force people to start from scratch? (specifically, I would resolve 
invalid + abandon).

Again, the only people who i would expect to use this are people who actively 
use bugzilla or who for some reason end up w/ a large amount of bugmail from a 
bug.  Demanding that a bug be resolved once, and that future issues be covered 
elsewhere isn't unreasonable (although perhaps it should be handled 
seperately).
->New product Bugzilla
Assignee: justdave → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Whiteboard: [people:rep]
Another use of this feature: A couple of my bug reports were marked duplicates. There's no e-mail traffic in them, but it'd be nice to make them disappear from the My Bugs report so I can focus on the live ones.
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
See also Bug 37613 - "Accept bug" or "Take bug" functionality.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Attached patch v1 (obsolete) — — Splinter Review 
adds abandon-enabled and commentonabandon parameters
if enabled the reporter can choose to abandon the bug.	this results in the
reporter_id being set to 0.
Assignee: myk → bugzilla
Status: NEW → ASSIGNED
Attachment #185746 - Flags: review?
Does that mean that the bugs can be seen by logged-out users if they are
reporter_accessible?
Attached patch v2 (obsolete) — — Splinter Review 
timelyx did a review on irc; fixes mainly to wording and indentation.
Attachment #185746 - Attachment is obsolete: true
Attachment #185747 - Flags: review?
Attachment #185746 - Flags: review?
Comment on attachment 185747 [details] [diff] [review]
v2

> Does that mean that the bugs can be seen by logged-out users if they
> are reporter_accessible?

ah, good catch.
Attachment #185747 - Attachment is obsolete: true
Attachment #185747 - Flags: review?
Attached patch v3 — — Splinter Review 
fixes reporter_accessible issue
Attachment #185748 - Flags: review?
does that mean there's no way to tell who the reporter was, once the bug is
abandoned?
(In reply to comment #15)
> does that mean there's no way to tell who the reporter was, once the bug is
> abandoned?

I agree. A message such as "This bug has been abandonned by reporter@mail.com"
should be appended in the same way we do when marking a bug as a dupe of another
one.

Comment on attachment 185748 [details] [diff] [review]
v3

>Index: Bugzilla/User.pm

>-    return ( (($reporter == $userid) && $reporter_access)
>+    return ( ($reporter && ($reporter == $userid) && $reporter_access)
>            || (Param('useqacontact') && $qacontact && 
>               ($qacontact == $userid))
>            || ($owner == $userid)


This part will conflict with the patch in bug 292544.
Is there a good reason to use 0 rather than NULL? (e.g. does that cause lots of
other code to break?)

Does the change automatically get put into bugs_activity with changes to other
fields, or would the new code need to do this explicitly (in order to provide
traceability of original reporter)?

It appears from the templates that we'll just see "None" by reporter. This could
cause some confusion e.g. "how can a bug report itself?". Perhaps something like
"None <i>(Original reporter abandoned bug)</i>" would be more self-explanatory.
(In reply to comment #15)
> does that mean there's no way to tell who the reporter was, once the bug 
> is abandoned?

bug activity will show the original reporter.

to show it on the bug page would involve adding a field to the bugs table to
indicate if the bug has been abandoned, which is an overkill.

(In reply to comment #18)
> Is there a good reason to use 0 rather than NULL?

null was my initial attempt, but i hit quite a few places that expected
bug->reporter->id to work (for example).  i had concerns that i wouldn't be able
to catch all instances, and i'm sure that coders will forget to check it in new
code.

> Does the change automatically get put into bugs_activity with changes 
> to other fields, or would the new code need to do this explicitly

it's not automatic, the code calls

LogActivityEntry($cgi->param('id'), 'reporter', Bugzilla->user->email,
"ABANDONED", Bugzilla->user->id, $timestamp);

in process_bug.cgi

> It appears from the templates that we'll just see "None" by reporter. This
> could cause some confusion e.g. "how can a bug report itself?". 
> Perhaps something like "None <i>(Original reporter abandoned bug)</i>"
> would be more self-explanatory.

yeah, timelyx and i discussed this a bit on irc and came up with "none"
(originally i had "abandoned").  i like your suggestion and will add it with the
next revision of this patch.


(In reply to comment #19)
> null was my initial attempt, but i hit quite a few places that expected
> bug->reporter->id to work (for example). [...]

Ok. Let's worry about that elsewhere if it seems to matter. Stick with 0 here
(in fact, now I think of it, a blank QA uses 0 rather than NULL too, right?)

> it's not automatic, the code calls [...]

D'oh! (note to self don't try to read patches too fast) I could swear I'd
specifically searched for a line like that before commenting!


Other related thoughts (best left for other bugs after experience of using this
implementation, but noted here so I don't forget them):
- "should a sufficiently empowered user be able to abandon bugs on a reporter's
behalf?" - e.g. equivalent permission to editusers.
- "Should another user be able to take over the "Reporter" role of an abandoned
bug?"
fixing this will be useful to me.

i reported a bug about 5 years ago (about UI spoofing) and a lot of people got
CC'ed, generating significant bug spam by expressing their opinion on the matter.

the spam was anoying.

this bug will allow filtering the spam.
I'm not too fond of the thought to clear the reporter field of the bug. The
person there is the person who reported the bug, and the bug should not forget this.

Instead, I think a checkbox marked "I'm still interested in this bug" or
something, shown to the reporter only, could be used to allow a reporter to bail
from the effects of the role (read, from the spam).
Others might get shown an unobstrusive message "(not interested in this bug any
more)" or "(abandoned this bug)" or something below the reporter's name if the
reporter chose to clear his checkbox.

As a plus, the reporter may choose to get interested in his bug again :)
hrm, i like that.
when i have the time i'll do a new patch.
Hmmm... well the advantage of using a NULL or zero reporter is that all of the
rest of the code that deals with the reporter will immediately hide the reporter
information from other users.

This seems like a good idea to me, as otherwise some bit of code or another user
basing things on search results or database queries could end up nagging them
afterwards, without realising their query was including abandoned bugs.

You could still have the checkbox UI though - comment 0's author should always
be the reporter (unlike other comments, it is put into the long_descs table even
if blank), so bugzilla still knows who you are...
... and w.r.t. my comment #24 it may be informative to see if this query returns
any results on b.m.o's database, and if so why:

SELECT bugs.bug_id, bugs.reporter, longdescs.who
 FROM bugs,longdescs
   LEFT JOIN longdescs L2 ON longdescs.bug_id=L2.bug_id
                         AND longdescs.bug_when>L2.bug_when
 WHERE bugs.bug_id = longdescs.bug_id
   AND L2.bug_id IS NULL
   AND longdescs.who!=bugs.reporter
 LIMIT 10;
(In reply to comment #24)

I think it's better to do it right than to introduce inconsistencies.

I think that within the scope of this bug, the fact that a reporter has
abandoned a bug should stop sending reporter-role e-mails to the reporter, and
it should show only on show_bug.cgi. If we want to show the fact somewhere else,
let's do it in follow-up bugs.
(In reply to comment #26)
> I think it's better to do it right than to introduce inconsistencies.
[...]

I don't think anyone was proposing introducing inconsistencies, but clearly and
distinctly defining:
"reporter = 0" to mean "nobody is acting as the 'reporter' contact for this bug"

AIUI Bugzilla already has some concept of what userid=0 means (the QA field has
allowed this for a long time), which is how I understand the method implemented
here to work.


Bugzilla wouldn't be 'forgetting' the original reporter as you suggested in
comment 22, but just keeping the information to one side, and mentioning to a
casual observer only that the original reporter has abandoned the role.

I believe that after user abc@123 has abandoned one or more bugs, you would find
them all by searching (in a similar manner to past QA / Assignee etc):
[Reporter  ] [ Changed from  ] [ abc@123      ] or similar ("changed by" etc...)

I see no reason to continue to mention the original reporter on any 'live'
information relating to an abandoned bug. Why do you think this is necessary?


My comments 24/25 were indicating that the original reporter can still be
quickly identified as the author of comment 0 (unless there is some legitimate
mechanism these can be different), in case this grants any special privileges
(i.e. being able to un-abandon the bug).

An "interested in this bug" / "not interested in this bug" flag would be useful
for more than just the reporter (perhaps I'm CC-ed, don't want mail right now,
but want the bug to stay on my list so I can come back to it), and I would see
that as a move towards per-bug email filters. Probably useful, but different to
THIS bug as I interpreted it.
(In reply to comment #27)
> "reporter = 0" to mean "nobody is acting as the 'reporter' contact for this

I consider this to be an inconsistency. The reporter should continue to be the
user who reported the bug. I still fail to see the advantage of removing
information.

> AIUI Bugzilla already has some concept of what userid=0 means (the QA field
> has allowed this for a long time), which is how I understand the method
> implemented here to work.

If the QA field is 0, then the bug has no QA contact. This is all right, QA
contacts may come and go.

> Bugzilla wouldn't be 'forgetting' the original reporter as you suggested in
> comment 22, but just keeping the information to one side, and mentioning to a
> casual observer only that the original reporter has abandoned the role.
[...]
> I see no reason to continue to mention the original reporter on any 'live'
> information relating to an abandoned bug. Why do you think this is necessary?

Maybe this is the crucial point we differ on. I think the reporter cannot escape
his role of having reported the bug, and the database should reflect this.
What's shown to the casual observer is something different entirely: as
mentioned in comment 22, I agree the UI should mark abandoned bugs as such. Wrt
comment 24, code based on database queries should be free to decide whether to
include abandoned bugs or not.

That's why I think we should add the additional information whether the reporter
has abandoned the bug. Besides being cleaner, I'm convinced it's simpler, too:
when looking for bugs a person has reported, it's the easiest thing to show all,
and it's the easiest thing to show all non-abandoned. Plus, as soon as we have
the feature, it's the easiest thing to have one or the other be the default.
(In reply to comment #28)
> I still fail to see the advantage of removing information.

The information is not removed. It is retained in bugs_activity just like any
other change. I already demonstrated how to search for it if you really need to
find bugs abandoned by a user. Clearing the actual reporter field has the
desired effect of removing any *current* association with the bug.

> Maybe this is the crucial point we differ on.
> I think the reporter cannot escape his role of having reported the bug,
> and the database should reflect this.

I agree that this is the fundamental point on which we differ. To me, the point
of this bug is to create a mechanism to allow the reporter to escape that role,
but you appear to believe that a reporter must not under any circumstances be
allowed to escape.

As I see it, the important aspect of the reporter role is "user who you expect
to respond to requests for further clarification about this bug" rather than
"user who got to the 'Enter Bug' form first". Perhaps this is also something on
which we disagree.

You mention that "... QA contacts may come and go" [implied: but reporters may
not]. This is what I see as the problem - a Reporter *should* be free to go.
Comment on attachment 185748 [details] [diff] [review]
v3

Comment 22 is the right way to go.


>Index: process_bug.cgi

>+    /^abandon$/ && CheckonComment( "abandon") && do {
>+        # Ensure the reporter is doing the abandoning
>+        my $userid = Bugzilla->user->id;

process_bug.cgi already has a $user object and $whoid to identify the user.

>+        if ($bug->reporter && $bug->reporter->id != $userid) {
>+            ThrowUserError("abandoner_not_reporter");
>+        }

I definitely don't like that! Bugs have a reporter! I already see security
holes coming!


>+        LogActivityEntry($cgi->param('id'), 'reporter', Bugzilla->user->email, 
>+            "ABANDONED", Bugzilla->user->id, $timestamp);

1) Bugzilla->user->email should be $user->login
2) Bugzilla->user->id should be $whoid



>Index: sanitycheck.cgi

> CrossCheck("profiles", "userid",
>            ['profiles_activity', 'userid'],
>            ['profiles_activity', 'who'],
>-           ["bugs", "reporter", "bug_id"],
>+           ["bugs", "reporter", "bug_id", ['0']],

Argh.... see bug 109474.



>Index: Bugzilla/Bug.pm

> sub reporter () {
>-    my ($self) = @_;
>+    my ($self, $new_reporter_id) = @_;
>+    if (defined $new_reporter_id) {
>+        my $dbh = Bugzilla->dbh;
>+        if (!detaint_natural($new_reporter_id)) {
>+            ThrowCodeError("invalid_user_id", { userid => $new_reporter_id });
>+        }

Does user ID 65468762168465 also exist?


>Index: Bugzilla/User.pm

>-    return ( (($reporter == $userid) && $reporter_access)
>+    return ( ($reporter && ($reporter == $userid) && $reporter_access)

Are you *sure* you have caught all such places??


This approach has definitely not my vote. What wurblzap suggested about adding
a checkbox allowing the reporter to "disable" his role on a per bug basis (from
the bugmail point of view) is a much better solution.
Attachment #185748 - Flags: review? → review-
Actually removing the reporter is a bad thing.

We could use a mechanism that is an ANTI-CC.  This would deal with this as well
as helping to silence noisy bugs when component watching.

As this stands, this has my ANTI-vote.

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
*** Bug 322837 has been marked as a duplicate of this bug. ***
Instead of making a new feature, wouldn't it be better to remove one?

If the reporter got added to the CC list automatically and we remove the send email to the reporter stuff.  The reporter's email could be managed as a normal CC.
You wouldn't be able to filter e-mails differently any more.
(In reply to comment #35)
> You wouldn't be able to filter e-mails differently any more.
> 

Is that an observation or an issue?
QA Contact: mattyt-bugzilla → default-qa
Assignee: bugzilla → create-and-change
Status: ASSIGNED → NEW
We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.
Target Milestone: Bugzilla 3.0 → ---
Instead of actually marking the reporter as NULL in the DB, just add another column called reporter_abandoned and mark in the UI that he's abandoned it. Then don't send him email in his reporter role, on that bug.
Priority: P2 → P3
(In reply to comment #38)
this results in such bugs appearing in buglists, whines, charts and reports.

If I've abandoned it, I really don't want to ever find it when I go looking for things relating to me. If I want to find it, I'll search for it by some other attribute.

I suppose that does mean someone who wants to game the system could abandon all INVALID/WORKSFORME/WONTFIX bugs they report, but that's life.

It's pretty safe to say that in general people won't want to read abandoned bugs, they're about as close to dead as you can get.

And of course, in today's world anyone can clone (becoming the reporter) if they feel the bug is of some vital interest. 
Bug 148564 is a better approach to this problem and works in a more general way. We will implement the other one.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: