387240 - Reporters without EDITBUGS should not be able to re-open VERIFIED bugs

Status: NEW

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

Description

[Chris Lawson (gone)]

Bug 387194 is just one example; I could easily quote several others if I felt like digging. It would help matters greatly if Bugzilla accounts without edit privileges were disallowed from re-opening a verified bug, especially in the case that the bug is VERIFIED INVALID. I have yet to see an incorrect VERIFIED INVALID resolution at all, much less one that was correctly re-opened by the reporter. What usually happens is that the reporter gets indignant that his "bug" is not really a bug at all and starts committing all sorts of etiquette violations, which does nothing for the sanity and health of triage folks, who then have to deal with it.

Granted, this isn't exactly a widespread problem, but it's bad enough that I finally filed a bug on it ;)

Comment 1

[Max Kanat-Alexander]

You know, actually, I agree with this. If a bug is in the VERIFIED state, that usually means some qualified engineer agreed that the resolution was correct, and *most* of the time, that engineer is far more qualified than the reporter.

I wouldn't mind making this the default behavior in Bugzilla. Anybody else agree?

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> I wouldn't mind making this the default behavior in Bugzilla. Anybody else
> agree?

No, I don't. I don't want to see more hardcoded restrictions, first because you can now customize/rename bug statuses, and secondly because this violates some rules, such as those allowing the reporter to reopen their bugs.

What I'm going to do is to implement a new template for editworkflow.cgi which lets you decide which transitions are allowed based on your privs and role with the bug. This will allow admins to customize transitions even more, without having to edit Bug.pm. This will fix many requests made against bug 90619.

Comment 3

[Chris Lawson (gone)]

I don't really know the Bugzilla code base at all, so I don't know what the impact of this enhancement request would actually be vis-a-vis comment 2, but I will point this out:

# If reporter can't re-open their bug they will just file a duplicate.

That's a comment in the code (or was back in 2001 when bug 90619 was first filed), and I don't think it's true at all. It certainly doesn't agree with my three-plus years of triage experience in Mozilla's Bugzilla.

Is there a reason other than "I don't want to see more hardcoded restrictions" that implementing this request as-asked is bad? I.e., regardless of the code used to achieve the behaviour, is it possible for the default behaviour in Bugzilla to be to prevent reporters from reopening VERIFIED bugs?

Alternatively, will the change proposed in comment 2 allow someone who is not an admin -- but has editbugs, canconfirm, etc. privileges -- modify a bug in such a manner that reporters cannot re-open it, ideally in a single step combined with verification? If it will not allow this, such a change will be pretty much useless for Camino's triage team, at least.

Like I said, that's not really a huge deal, but it also wouldn't help resolve the issue behind this bug if that's the case.

Comment 4

[Max Kanat-Alexander]

(In reply to comment #2)
Okay. But after we have that customizable structure, I'd be all for making this part of the default restrictions.

Comment 5

[Frédéric Buclin]

(In reply to comment #4)
> Okay. But after we have that customizable structure, I'd be all for making this
> part of the default restrictions.

We could do that, even if it's less our problem at this point, as the admin would then be free to choose himself what the rules are.

Comment 6

[timeless]

personally, I've always felt that CLOSED was the state at which a reporter should no longer be able to reopen a bug

Lifecycle of a bug:
reporter files bug (UNCO)
qa confirms bug (NEW)
assignee accepts bug (ASSI nee ACCE)
assignee commits a fix (FIXE)
qa tests bug and feels it's fixed (VERI)
reporter tests bug and asserts it's not fixed (REOP)
assignee accepts bug (ASSI nee ACCE)
assignee commits a fix (FIXE)
qa tests bug and feels it's fixed (VERI)
product management ships a final release of the product (CLOS)

at this point, if the reporter wants to report things are not working, product management respectfully requests the reporter file a new bug (obviously with a newer version of the product, but ...).

perhaps you're used to a process where QA contacts are perfect. I'm used to a number of places where QA contacts are far from perfect.

Notes:
1. yes, I'm encouraging closed to exist as a state.
2. no, I'm not encouraging QA to use CLOSED when they want reporters to shut up. CLOSED should be restricted to a product management team and should be used en mas on verified bugs after some product release (possibly the last point release of a branch, and possibly simply the first release of a product).