Closed
Bug 273825
Opened 20 years ago
Closed 19 years ago
UserInGroup("canedit") in post_bug.cgi sounds incorrect
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: LpSolit, Assigned: LpSolit)
References
()
Details
Attachments
(1 file)
581 bytes,
patch
|
bugreport
:
review+
|
Details | Diff | Splinter Review |
"canedit" is not a default system group, but "editbugs" is! A user with editbugs privs but no canconfirm privs can select "NEW" as the initial bug status from enter_bug.cgi, but this choice is not validated as the corresponding lines in post_bug.cgi are: if (UserInGroup("canedit") || UserInGroup("canconfirm")) { # Default to NEW if the user hasn't selected another status $::FORM{'bug_status'} ||= "NEW"; } else { ... "canedit" only appears in group_control_map but UserInGroup uses user_group_map to check if the user is in a group or not! Problems appear even for components which do not use restrictions! My suggestion is to replace "canedit" by "editbugs" in the above condition. Or do we want more restrictions (in special cases) to confirm bugs? Concerns 2.18 also!
Assignee | ||
Comment 1•19 years ago
|
||
The 'canedit' group does not exist! Moreover, the section "3.10. Groups and Group Security" specifies that "Similarly, you must be a member of all of the entry groups for a product to add bugs to a product and you must be a member of all of the canedit groups for a product in order to make any change to bugs in that product.". In other words, there no need to check the 'canedit' bit as it is only used when editing *existing* bugs, not when creating *new* bugs. The 'entry' part is checked by a previous call to CanEnterProduct().
Assignee | ||
Updated•19 years ago
|
Flags: blocking2.18.1?
Assignee | ||
Updated•19 years ago
|
Attachment #176520 -
Flags: review?(justdave)
Assignee | ||
Updated•19 years ago
|
Attachment #176520 -
Flags: review?(justdave)
Comment 2•19 years ago
|
||
Interesting... It certainly looks wrong, but it's been that way since 2002 when Gerv landed bug 163457. We should ask Gerv if we are missing something before we change this.
Assignee | ||
Updated•19 years ago
|
Target Milestone: --- → Bugzilla 2.20
Comment 3•19 years ago
|
||
Comment on attachment 176520 [details] [diff] [review] replace canedit by editbugs, v1 r=joel by inspection
Attachment #176520 -
Flags: review?(bugreport) → review+
Assignee | ||
Updated•19 years ago
|
Flags: approval?
Flags: approval2.18?
Target Milestone: Bugzilla 2.20 → Bugzilla 2.18
Comment 4•19 years ago
|
||
So (having spent twenty minutes fiddling) the upshot of this bug is: if a user is in editbugs and is not in canconfirm (either directly, by regexp or by inheritance from admin) then when they file a NEW bug in a product which is using UNCONFIRMED, it'll end up UNCONFIRMED. All the conditions at the beginning of that sentence are probably why no-one's seen this. Very few people have editbugs and not canconfirm. r=gerv. Gerv
Updated•19 years ago
|
Flags: blocking2.18.1?
Flags: blocking2.18.1+
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+
Comment 5•19 years ago
|
||
2.18: Checking in post_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v <-- post_bug.cgi new revision: 1.88.2.5; previous revision: 1.88.2.4 done Tip: Checking in post_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v <-- post_bug.cgi new revision: 1.105; previous revision: 1.104 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 6•19 years ago
|
||
*** Bug 292085 has been marked as a duplicate of this bug. ***
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•