Open Bug 612327 Opened 15 years ago Updated 12 years ago

Remove bugs.everconfirmed

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
REOPENED

People

(Reporter: LpSolit, Unassigned)

References

Details

With REOPENED going away from the default workflow, and the magic trick to decide between UNCONFIRMED and REOPENED being gone, I think everconfirmed no longer makes sense, and should go away.
No, it's still worthwhile to know whether or not a bug has been confirmed, separately from its status. Otherwise you can't know what to do with people who aren't in canconfirm when a bug is RESOLVED.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
(See check_can_change_field if what I said was unclear.)
We don't need everconfirmed to know this information. Looking at the bug status would be enough. Anyway, invalid isn't the right resolution.
Resolution: INVALID → WONTFIX
(In reply to comment #1) > No, it's still worthwhile to know whether or not a bug has been confirmed, > separately from its status. Otherwise you can't know what to do with people who > aren't in canconfirm when a bug is RESOLVED. Coming back to this, everconfirmed won't answer this question either. Till now, a user with no privs could only choose either UNCO or REOPENED, based on everconfirmed. But with REOPENED going away, you don't know what to do with a powerless user who tries to reopen a bug. You could use NEW -> RESO -> ASSI to indirectly edit open bug statuses. So everconfirmed as is is not helpful anymore.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I'm not sure what your objection is. Did you check over how check_can_change_field works, again? Until now, an unprivileged user could *only* reopen to UNCONFIRMED, if the bug wasn't confirmed. The workflow we're supporting is: UNCO -> RESOLVED -> (what?) For users who are *not* in canconfirm.
(In reply to comment #5) > I'm not sure what your objection is. Did you check over how > check_can_change_field works, again? I know how it works, yes. > Until now, an unprivileged user could *only* reopen to UNCONFIRMED, if the bug > wasn't confirmed. I'm not talking about these bugs. I'm talking about already confirmed bugs.
Okay. But NEW -> RESO -> ASSI is often a perfectly valid transition. For example: 1. User A files a bug. 2. Developer X closes it as invalid. 3. Developer Y disagrees, reopens it and assigns it to himself immediately.
Right, and this is fine as long as the developer has canconfirm privs. But if he hasn't, then he should not be allowed to do this transition. It doesn't make sense to explicitly forbird NEW -> ASSIGNED in check_can_change_field() if the user hasn't canconfirm privs, but allow NEW -> RESO -> ASSIGNED for this same user. Else we could as well remove this restriction entirely (which I don't want!).
Ah, I see what you mean. The only reasonable way to do this would be to store the previous status as a column in the bugs table (because we need the information on every check_can_change_field call for the bug_status field and values), but I'm not sure how I feel about that. Also, if we ever want to stop associating "UNCONFIRMED" and "this bug is not confirmed" with each other, we'd need everconfirmed again.
(In reply to comment #9) > Also, if we ever want to stop > associating "UNCONFIRMED" and "this bug is not confirmed" with each other, we'd > need everconfirmed again. Why would you want to stop that? "this bug is not confirmed" is the exact definition of UNCONFIRMED. You cannot dissociate them. Users wouldn't understand the distinction (nor would I).
Because we might want to allow people to change the name of the UNCONFIRMED status or to add additional statuses that are not confirmed. For example, if somebody adds a NEEDINFO status, they may not want that status to confirm the bug. They also may not want it to *unconfirm* the bug, to move it to that status.
(In reply to comment #11) > Because we might want to allow people to change the name of the UNCONFIRMED > status or to add additional statuses that are not confirmed. IMO, the definition of an unconfirmed bug is bad. everconfirmed is purely technical for the old time when a resolved bug could only be reopened with status UNCO or REOPENED, and people should not even see it in bugmails at all (bug 84022). If an admin renames UNCO to something else, and/or add NEEDINFO, the bug is not confirmed vs not confirmed; it simply has status NEEDINFO, ASSIGNED/IN_PROGRESS, RESOLVED, etc..., but I see no value in the distinction between a confirmed and an unconfirmed bug. In the same way, the distinction between an open bug and a closed bug is also due to how things worked in the old time. We think "closed" as in "this bug has a resolution", and "open" as in "this bug has no resolution". But this definition of open vs closed is inappropriate for bugs with status e.g. WAITING and a resolution either TRIAGE, TESTCASE, or UPSTREAM_FIX. The "waiting" state (used by e.g. GCC Bugzilla) is at mid-way between an open and closed state, but from a technical point of view, this status having a resolution means that the bug is closed, which is not exactly true. So to be clear, we should really stop using words like "confirmed" vs "unconfirmed", and "open" vs "closed", because that may not be true anymore now that you have full control on status and resolution values.
I think the open vs. closed distinction is still very important. Closed states have an associated resolution; open ones don't. But I agree everconfirmed should die. Its original purpose was single and simple - to offer the correct status when reopening a bug. Should it go to UNCONFIRMED or REOPENED? Now that statuses are much more fluid and redefinable, and now that confirmation has become a step in the workflow which is recognised as not applying to every installation, I think we can leave that decision to the user who is doing the reopening. everconfirmed makes particular statuses special, which makes statuses less user-configurable. That's something we want to avoid. It's a pain to support and the benefit is tiny. Gerv
It is still useful to know whether or not a closed bug is confirmed, from both a code perspective and an API perspective. (is_confirmed is one of the fields we return in the API)
The latter part of your logic is circular. It's useful to know this information because we put it in the API - but presumably we put it in the API because we thought it was useful. But that doesn't help answer whether it actually is useful to anyone. So who does care? What decisions are going to be made differently based on this flag? As I said, originally it was solely about reopening bugs, because when UNCONFIRMED was added, we wanted it to be a prison only a sufficiently empowered user could let a bug out of. However, anyone can resolve and reopen bugs they filed - and if that moved it to REOPENED rather than back to UNCONFIRMED, it would have become confirmed 'by the back door'. However, times have changed. We have a less combative relationship with bug filers, no-one ever tried this 'auto-promotion' route anyway, UNCONFIRMED is not a part of many workflows, and yet is_confirmed hangs around, making UNCONFIRMED special and requiring us to track it and have special options and code for it. What is the problem with the idea that if I am reopening a bug, I can decide whether it fits my Bugzilla's definition of UNCONFIRMED or not, rather than having the software enforce it for me? After all, if I'm reopening it, I must have seen it, so the bug is almost certain to be confirmed. Forcing it to UNCONFIRMED just because that's what it was before it was resolved is most likely to just lead to the user having to do an extra bug-edit-and-submit cycle, and cursing inflexible workflow rules. Gerv
(In reply to comment #15) > However, anyone can resolve and reopen > bugs they filed - and if that moved it to REOPENED rather than back to > UNCONFIRMED, it would have become confirmed 'by the back door'. No, that is untrue. Users without canconfirm cannot confirm a bug by any means. They can only reopen to a confirmed status if the bug was already confirmed. > What is the problem with the idea that if I am reopening a bug, I can decide > whether it fits my Bugzilla's definition of UNCONFIRMED or not, Well, for Mozilla, because you have tens of thousands of bug filers who do not have the ability to competently make that judgment.
(In reply to comment #16) > No, that is untrue. Users without canconfirm cannot confirm a bug by any > means. They can only reopen to a confirmed status if the bug was already > confirmed. But they can reopen the bug to another confirmed status which is different from the old one, which we should forbird, see comment 8. But everconfirmed is unable to prevent that. Storing the previous open status would make more sense.
(In reply to comment #17) > Storing the previous open status would make more sense. Ah, that might be a good idea indeed. I mean, I like the simplicity of everconfirmed (and the idea that whether or not a bug is "confirmed" is a separate fact from its status) but you're right that storing the old status name would get us more strict controls, so perhaps we should just do that.
(In reply to comment #16) > (In reply to comment #15) > > However, anyone can resolve and reopen > > bugs they filed - and if that moved it to REOPENED rather than back to > > UNCONFIRMED, it would have become confirmed 'by the back door'. > > No, that is untrue. Users without canconfirm cannot confirm a bug by any > means. They can only reopen to a confirmed status if the bug was already > confirmed. My statement was predicated on the non-existence of everconfirmed. That was my point - everconfirmed allows you to do this. It's its only function. > > What is the problem with the idea that if I am reopening a bug, I can decide > > whether it fits my Bugzilla's definition of UNCONFIRMED or not, > > Well, for Mozilla, because you have tens of thousands of bug filers who do > not have the ability to competently make that judgment. It's not that common for new bug filers to reopen bugs. And anyway, because the workflow is now flexible enough, someone else could just move it back to UNCONFIRMED if they felt it hadn't been confirmed yet. My key point: the extra admin, code and specialization of particular types required to support a slightly enhanced behaviour in the case of reopening bugs is not worth the effort of keeping and supporting this. Storing the previous open state would be more general, would work whatever states were in use, and doesn't make any state special. I think that's a much better plan. And even if we decide to keep it for now, I don't think it should be exposed on the WebServices interface, because then "but it's on the WebServices interface" will become another compatibility reason to keep it independent of its actual usefulness. Gerv
See Also: → 482654
You need to log in before you can comment on or make changes to this bug.