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•24 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•24 years ago
|
||
Reporter | ||
Comment 9•24 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
•