Closed Bug 151714 Opened 22 years ago Closed 22 years ago

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


(Bugzilla :: User Accounts, defect)

Windows 98
Not set



Bugzilla 2.16


(Reporter: bugzilla4dave, Assigned: bbaetz)



(Keywords: regression)


(1 file)

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):
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 "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.
Keywords: regression
Target Milestone: --- → Bugzilla 2.16
-> gerv, who wrote this originally

The show_bug test for user.canedit is wrong, and some of the template tests
don't match reality.
Assignee: myk → gerv
Blocks: 150783
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.)
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.
Trying to confirm the bug silently fails, so this is not a security bug, just a
user interface issue.
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?
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.
Suggested permissions summary now posted to the newsgroups. See also related bug

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.
Attached patch v1Splinter Review
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.
-> patch author (me)
Assignee: gerv → bbaetz
Keywords: patch, review
Comment on attachment 90448 [details] [diff] [review]

>-                       || 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.

Attachment #90448 - Flags: review+
whitespace change - I removed some trailing spaces.
Comment on attachment 90448 [details] [diff] [review]

Looks good, works.  r=myk
Attachment #90448 - Flags: review+
Checked into trunk + branch (and changing summary, since this was only a UI issue)

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

Checking in;
/cvsroot/mozilla/webtools/bugzilla/,v  <--
new revision:; previous revision:
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
new revision:; previous revision:
Closed: 22 years ago
Resolution: --- → FIXED
Summary: user with no canconfirm permission should not get option (or be allowed) to mark bugs they reported as NEW → user with no canconfirm permission should not get option to mark bugs they reported as NEW
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.