99251 - Resolving FIXED should automatically confirm.

Status: REOPENED

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

Description

[Matthew Tuck [:CodeMachine]]

When you mark a bug RESOLVED FIXED, it should automatically be confirmed
(everconfirmed should be set to 1).

This is no biggie if a mistake was made ... after all, what if you normally
CONFIRM a bug accidentally ... there's no undo!

Comment 1

[Matthew Tuck [:CodeMachine]]

Taking this for 2.18 - I would prefer to get stuff like this in initially with
the new resolutions table as a part of bug #94534.

Comment 2

[Dave Miller [:justdave]]

Taking Jake's bugs...  his Army Reserve unit has been deployed.

Comment 3

[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 4

[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 5

[Frédéric Buclin]

As per my comment 17 bug 34172, I ask to *wontfix* this bug as this is a way for
reporters without canconfirm privs to confirm their bugs:

1. Create a new bug. This bug is unconfirmed for users without privs.
2. The reporter closes his bug as RESOLVED FIXED. The bug gets confirmed.
3. The reporter reopens his bug. The bug is now NEW because everconfirmed = 1!

We already have such problems when reassigning bugs, see bug 266579 (the
reporter assigns his bugs to him, and as the owner confirms his bugs). Do not
give another opportunity to do things we don't want or we could then compare
Bugzilla to a well known OS... ;)

Comment 6

[Dave Miller [:justdave]]

The only way I'd take this is if we prevented the reported from resolving their
own bug as fixed.  Perhaps if someone who has editbugs privs resolves it as fixed?

Comment 7

[Frédéric Buclin]

(In reply to comment #6)
> The only way I'd take this is if we prevented the reported from resolving their
> own bug as fixed.  Perhaps if someone who has editbugs privs resolves it as fixed?

As I said in the other bug: if the bug is valid, it should be NEW first. If this
was fixed by another bug, then it is a dupe.

And I don't really like the idea to hack CheckCanChangeField() once more. But if
you really want to prevent the reporter from resolving his bugs as fixed, it is
straightforward to hack the code.

Comment 8

[Dave Miller [:justdave]]

If we take this, it needs more discussion first. I think it's a can of worms though.

Comment 9

[Stephen Lee]

IMHO, a bug should be confirmed on RESOLVED FIXED only if the person marking it 
has CanConfirm privilege. Even then, I am not conviced it should be automatic.

If it is possible to have a bug that is in any RESOLVED state with 
ever_confirmed=0, it would seem a good idea for the REOPEN option also to 
include a "[ ] and confirm bug" checkbox.


AIUI, "resolved fixed; everconfirmed=0" would mean something like "we were 
never sure whether this bug actually occurred, but if it did, we believe it 
would have been fixed by the changes we have done". e.g. a reported bug related 
to the UI of Dialog X when Dialog X has since been completely redesigned.

Comment 10

[u430950]

This appears to now work as expected.