Closed
Bug 61343
Opened 24 years ago
Closed 22 years ago
Should be able to default groups to on when submitting a bug
Categories
(Bugzilla :: User Accounts, enhancement, P3)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: mozilla-work, Assigned: myk)
References
Details
(Whiteboard: [blocker will fix])
Attachments
(2 obsolete files)
When submitting a bug it should be possible to have the default be: Only people in the "XXX" group can see this bug instead of: People not in the "XXX" group can see this bug I would add an additional checkbox for editusers for each group which would say something like: This bit is on by default.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
The above bug fixes the described problem. It is based on our local copy of bugzilla which is based on 2.10. It requires a new field called 'defaultgroupset' be added to the profiles table. The patch has the following features: 1. You can enable/disable the bit for each user in editusers.cgi; 2. enter_bug.cgi will set the a group to on if defaultgroupset has that bit set in defaultgroupset; and 3. If there is a regular expression for a group, any new user who matches that regular expression will have that bit enabled in their defaultgroupset. Enjoy!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 3•24 years ago
|
||
Reopening. FIXED means that the fix has been checked into CVS, and I assume that's not the case here. If I'm wrong, please re-close.
Status: RESOLVED → REOPENED
Keywords: patch
OS: Solaris → All
Hardware: Sun → All
Resolution: FIXED → ---
Comment 4•24 years ago
|
||
That's true. I was suprised that I could actually set to FIXED since I didn't believe that external users would actually have the permission to FIX bugs.
Comment 5•24 years ago
|
||
You can actually do anything with a bug you filed yourself.
Keywords: review
Comment 6•24 years ago
|
||
Default security permissions is one of the things I mentioned in my security redesign proposal on bug 39816. Most likely this patch won't be valid after we redo the security, but the issue still will...
Target Milestone: --- → Bugzilla 2.14
Comment 7•23 years ago
|
||
removing patch keyword... this patch will not apply cleanly against the current CVS code. Keywords can be added back when we have a clean patch.
Reporter | ||
Comment 8•23 years ago
|
||
Reporter | ||
Comment 9•23 years ago
|
||
I have created a diff between 2.12 and our version of bugzilla. I have editted out our other enhancments and hopefully nothing else.
Keywords: patch
Comment 10•23 years ago
|
||
This patch appears to depend on the existence of a column in the profiles table that doesn't exist, but there's no patch for checksetup.pl to create that column in here.... cc Chris for schema change
Status: REOPENED → NEW
Keywords: patch
Comment 11•23 years ago
|
||
what does this do that product groups doesn't? product groups are turned on in new bugs by default. Although that goes by product, and I guess this would set it by user. Wouldn't you want settings by user to be editable by the user?
Reporter | ||
Comment 12•23 years ago
|
||
They are editable by the user. It's just whether they are on or off by default. We had a problem with people forgetting to select the groups when they submitting a bug and this made a bunch of bugs public that should have been private.
Comment 13•23 years ago
|
||
I mean the user can't change what their defaults are... sure, they can change it when they're opening a bug.
Reporter | ||
Comment 14•23 years ago
|
||
Yeah, that's true. I didn't anticipate that when I wrote this. I don't need that for my installation right now but I think it would be a good feature.
Comment 15•23 years ago
|
||
I'm going to hold this off for 2.16... mainly because we're going to be completely redoing the way groups work shortly to try to get around the 63-group limitation, and this'll need to be redone after that anyway.
Target Milestone: Bugzilla 2.14 → Bugzilla 2.16
Comment 16•23 years ago
|
||
Anyone interested in a patch against 2.14? Most of its the same but my changes to editusers.cgi got blown away when I upgraded from 2.12 to 2.14. I will probably handle this in-house by simply hacking the MySQL database directly. However, if anyone's interested, I can come up with something that gives at least the same functionality as the patch against 2.12.
Comment 17•23 years ago
|
||
-> Bugzilla product
Assignee: tara → myk
Component: Bugzilla → User Accounts
Depends on: 68022
Product: Webtools → Bugzilla
Version: other → 2.14
Comment 18•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 19•22 years ago
|
||
Comment on attachment 19828 [details] [diff] [review] Patch that fixes this bug. This is being done on a per-product basis in bug 157756
Attachment #19828 -
Attachment is obsolete: true
Attachment #19828 -
Flags: review-
Updated•22 years ago
|
Attachment #33936 -
Attachment is obsolete: true
Attachment #33936 -
Flags: review-
Comment 20•22 years ago
|
||
bug 157756 fixed this.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Updated•12 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
•