151714 - user with no canconfirm permission should not get option to mark bugs they reported as NEW

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Dave]

I do not have canconfirm permission set for my account (nor any other permission
bits -- I just double checked this, too), but I am presented with the option to
mark a bug that I reported as NEW.  I have not actually tried it to see if
Bugzilla actually allows it, (didn't want to upset people).  Here are the
options I have now for a bug I reported (such as Bug 148881):
Leave as UNCONFIRMED 
Confirm bug (change status to NEW)
Accept bug (confirm bug, change status to ASSIGNED)
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
     and confirm bug (change status to NEW)
Reassign bug to owner of selected component
     and confirm bug (change status to NEW) 

Apologies if I am misremebering (and this is not a regression after all).  But I
think there is a mistake being made here, even if it is not a regression.  1) If
Bugzilla would deny me permission to change it to NEW, then don't have it
present me with that option.  2)  If Bugzilla is going to allow me to set to NEW
any bug I report, it seems like rules are being broken:
(From http://bugzilla.mozilla.org/bug_status.html) "UNCONFIRMED  [...]Nobody has
validated that this bug is true. Users who have the "canconfirm" permission set
may confirm this bug, changing its state to NEW. [...]"  Either way, seems like
something's wrong.

Don't get me wrong; it would be kind of cool if I could confirm my own reports.
 But I don't think developers would consider this "cool."  I am aware of Bug
95579 and Bug 90619, but 1) I suspect this is a regression (recent upgrade) and
those bugs are pretty old; and 2) I don't see the stuff about being able to mark
a bug NEW discussed anywhere in either of those two bugs.  I also understand the
notion that users ought to be able to reopen bugs they reported, mark their own
reports duplicates of others, and so forth, but I am pretty sure this does not
fall under "so forth".
I'll let someone who _should_ be allowed to confirm do so and set it to block
Bug 150783 if that is deemed necessary (and if this report is not invalid in the
first place).  :)  Couldn't find that anyone else had reported this yet.

Comment 1

[Bradley Baetz (:bbaetz)]

-> gerv, who wrote this originally

The show_bug test for user.canedit is wrong, and some of the template tests
don't match reality.

Comment 2

[Dave]

By the way, with no extra permission bits set, am I really supposed to be able
to create bugs as NEW?  Maybe part of this same issue (or not)?  (Unless this is
the correct behavior when advanced bug entry form is used... that's the only
thing I can think of.)

Comment 3

[Dave Miller [:justdave]]

For this particular bug, it's because you filed it in the Bugzilla product.  The
Bugzilla product doesn't use UNCONFIRMED, so all bugs are NEW when they're filed.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Trying to confirm the bug silently fails, so this is not a security bug, just a
user interface issue.

Comment 5

[Matthew Tuck [:CodeMachine]]

I'm not sure what the issue is with show_bug, how exactly are the template tests
wrong.  This is supposed to happen if you're not logged in, is that the problem?

Comment 6

[Bradley Baetz (:bbaetz)]

If you're logged in, and are the reporter, but don't have canconfirm, then the
option to confirm is shown, because the cgi sets user.canedit based (partly) on
you being the reporter.

The reporter can change most things, but CONFIRMING a bug isn't one of them. The
tst for user.canconfirm is similarly broken.

Comment 7

[Gervase Markham [:gerv]]

Suggested permissions summary now posted to the newsgroups. See also related bug
151326.

Gerv

Comment 8

[Bradley Baetz (:bbaetz)]

OK, but we need to get this bug fixed for 2.16.

I suspect that gerv just copied CheckCanChangeField's logic, which is slightly
wierd for allowing the reporter to confirm. (It actually lets them, but the way
the code is structured means that hte optoin becomes a noop - see my
npm.webtools posting for the gory stuff)

Since qa/assignee can't confirm either, that just means that we have to remove
those checks arround this block in the template.

Comment 9

[Bradley Baetz (:bbaetz)]

Attachment: v1

This splits user.canconfirm up to be totally separate to canedit. I changed the
template to be accurate. Because of the way thet code works, trying these
invalid options won't give you an error message, they just won't work.

Comment 10

[Bradley Baetz (:bbaetz)]

-> patch author (me)

Comment 11

[Jouni Heikniemi]

Comment on attachment 90448 [details] [diff] [review]
v1

>-                       || UserInGroup("editbugs");                   
>-    $user{'canconfirm'} = ($::userid == 0) || UserInGroup("canconfirm");
>+                       || UserInGroup("editbugs");

Why does that UserInGroup("...") line get removed and then added again? Doesn't
really matter, the result is sane, but it's odd.

r=jouni

Comment 12

[Bradley Baetz (:bbaetz)]

whitespace change - I removed some trailing spaces.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 90448 [details] [diff] [review]
v1

Looks good, works.  r=myk

Comment 14

[Bradley Baetz (:bbaetz)]

Checked into trunk + branch (and changing summary, since this was only a UI issue)

Checking in bug_form.pl;
/cvsroot/mozilla/webtools/bugzilla/bug_form.pl,v  <--  bug_form.pl
new revision: 1.97; previous revision: 1.96
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
 edit.html.tmpl
new revision: 1.13; previous revision: 1.12
done

Checking in bug_form.pl;
/cvsroot/mozilla/webtools/bugzilla/bug_form.pl,v  <--  bug_form.pl
new revision: 1.93.2.2; previous revision: 1.93.2.1
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
 edit.html.tmpl
new revision: 1.7.2.5; previous revision: 1.7.2.4
done