If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Should be able to default groups to on when submitting a bug

RESOLVED FIXED in Bugzilla 2.18



User Accounts
17 years ago
5 years ago


(Reporter: Stephen Rasku, Assigned: myk)


Bugzilla 2.18
Dependency tree / graph


(Whiteboard: [blocker will fix])


(2 obsolete attachments)



17 years ago
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.

Comment 1

17 years ago
Created attachment 19828 [details] [diff] [review]
Patch that fixes this bug.

Comment 2

17 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

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.


Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 3

17 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.
Keywords: patch
OS: Solaris → All
Hardware: Sun → All
Resolution: FIXED → ---

Comment 4

17 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

17 years ago
You can actually do anything with a bug you filed yourself.
Keywords: review

Comment 6

17 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
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.
Keywords: patch, review

Comment 8

17 years ago
Created attachment 33936 [details] [diff] [review]
Patch against Bugzilla 2.12

Comment 9

17 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
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
Keywords: patch
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?

Comment 12

17 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
I mean the user can't change what their defaults are...  sure, they can change it 
when they're opening a bug.

Comment 14

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

16 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.
-> Bugzilla product
Assignee: tara → myk
Component: Bugzilla → User Accounts
Depends on: 68022
Product: Webtools → Bugzilla
Version: other → 2.14
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 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-


15 years ago
Attachment #33936 - Attachment is obsolete: true
Attachment #33936 - Flags: review-
Depends on: 157756
Whiteboard: [blocker will fix]
bug 157756 fixed this.
Last Resolved: 17 years ago15 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.