281579 - suggestion for bugzilla permissions when using groups

Status: NEW

(Bugzilla :: Extension Ideas, enhancement)

Description

[Carl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

I think a better method then the one that is currently in use is when you add a
product, first a default group is created that will show every bug but is read
only.  Next if you want people to be able to submit bugs to that product, you
have to add them to a group and add that group to the product.  Then you have
the following permissions for that group:

"can see all bugs group has submitted"
"can see all bugs submitted to product"
"can only see bugs that the user has submitted",
"only members of group can submit bugs" which means if that permission isn't
selected then users who aren't members can submit bugs
"can edit bugs" which means they can edit all aspect of any bug and can assign
it to someone to get fixed for example

Reproducible: Always

Steps to Reproduce:
1. tried creating a product and looking for these options
2. couldn't find them
3. came up with these permissions to make it all easy

Actual Results:  
it never worked out for how I wanted it.

Expected Results:  
I think adding in permissions like these would add greatly for ease of use.

current group method used is hard to understand.

Comment 1

[Carl]

As for the bugs being added to the group the user is a member of, each user
should have a group order they should follow.  For example if product A has
groups 1 and 2 and Product B has groups 2 and 3, and a user is a member of both
groups 1, 2 and 3, then the group order could be set to groups 1, 2, and 3 in
the users setup.  The result of this would be the user submitting a bug to
product A, the bug would be added in the groups 1.  If the user submitted a bug
to Product B, then the bug would be added in the groups 2.  It would follow the
order sequentally.

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041217
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041217
> 
> I think a better method then the one that is currently in use is when you add a
> product, first a default group is created that will show every bug but is read
> only.  Next if you want people to be able to submit bugs to that product, you
> have to add them to a group and add that group to the product.  Then you have
> the following permissions for that group:
> 
> "can see all bugs group has submitted"
> "can see all bugs submitted to product"
> "can only see bugs that the user has submitted",
> "only members of group can submit bugs" which means if that permission isn't
> selected then users who aren't members can submit bugs
> "can edit bugs" which means they can edit all aspect of any bug and can assign
> it to someone to get fixed for example
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. tried creating a product and looking for these options
> 2. couldn't find them
> 3. came up with these permissions to make it all easy
> 
> Actual Results:  
> it never worked out for how I wanted it.
> 
> Expected Results:  
> I think adding in permissions like these would add greatly for ease of use.
> 
> current group method used is hard to understand.

Comment 2

[Max Kanat-Alexander]

Please clarify the summary of this bug. I can't understand what it is that you
are asking for?

If you're asking for more fine-grained permissions, we have a bug on that
somewhere, already...

Comment 3

[Carl]

With the way bugzilla is setup right now, you need to have 3 types of 
products.  One where developers can put bugs in, another where staff can put in 
bugs but can't edit them or anything, and another product where end users can 
submit bugs to, which the end users can only see their bugs.  Right now certain 
permissions are assumed if you are a member of a group or not.  If you are a 
member of a group without the canedit option selected, then you can submit bugs 
and see all the bugs that were submitted by members of that group.  If you 
aren't a member and entry is not selected, then you can submit bugs but can 
only see your own bugs you submitted.

With the permissions I suggested, it be alot easier in that you'd have only one 
product and be able to have multiple groups assigned to that product each one 
with different permissions then.  Plus the bug groups wouldn't interfere with 
each other as they do right now.  An example is that when 2 groups in a product 
has entry selected, a user has to be a member of both of those groups in order 
to see any bugs and be able to submit bugs.  Which complicates things.  These 
permissions would make things alot more clearer.  Plus getting rid of the 
ability for nonmembers to submit bugs and make it so that you have to be a 
member of a group in a product in order to submit bugs, which then that group 
would have certain permissions defined by the administrator, would be much more 
simpler to manage.  You could do so much more then I think.  And it be a hell 
of alot easier to understand and certainly would be more straightforward.

Plus the documentation currently doesn't mention that members of a group can 
see all bugs that were submitted by members of that group and that nonmembers 
can only see bugs the user submitted themselves.  Therefore the documentation 
needs to be updated.

Comment 4

[Frédéric Buclin]

joel, I think the features suggested by the reporter are already available using
the different Shown/NA Mandatory/Mandatory combinations in Edit Group Control.
If that's the case, I think we can close this bug.

Comment 5

[Joel Peshkin]

Yeah, I don't see anything clearly articulated that we cannot do already.  It
does require creating multiple groups that inherit from each other.  That, as we
know, is a pain - but, it is necessary for backward compatibility.

The one thing that I think the requester wishes for is a mechanism to permit a
product to have groups X, Y, and Z in a status resembling shown where X and Y
are customer groups and Z is a developer group whose members are also members of
X and Y.  Then, if someone who is in X (but not Z) submits a bug, restrict it to
X and of someone who is in Y (but not Z) submits a bug, restrict it to Y.  In
such cases, we would even probably want to make the restiction mandatory.   That
functionality would be handy, but nobody has suggested a viable way to organize it.

I'm not sure what the suggested change to the documentation is.

Comment 6

[Carl]

>> Steps to Reproduce:
>> 1. tried creating a product and looking for these options
>> 2. couldn't find them
>> 3. came up with these permissions to make it all easy

The only way around I saw to be able to do this was to create multiple products
of the same product.  Then assign users to the product in question.  For example
if you have product A, you create 2 products, one for developers, the other for
the public.  You name the one for developers Product A developers and make all
developers a member of that product with the ability to edit bugs.  Second is
Product A public, which is created for the public to submit bugs without the
ability to see any other bugs but their own submitted.  Then bug managers would
read the bugs the public submit, and resubmit them to the developers product A
in maybe a bit more clearer language at the same time assigning it to a
particular developer.

But this then becomes complicated if the public group you want to split it up
into the ability for certain people to see all bugs submitted by certain people
only.  For example, if you have persons 1, 2, 3, 4, 5, 6.  Persons 1, 2, and 3
are in company A and persons 4, 5, and 6 are in company B.  And you want to set
it so that persons 1, 2, and 3 can only see bugs that they each submit, without
seeing any bugs persons 4, 5, and 6 submit.  At the same time, persons 4, 5 and
6 can see any bugs persons 4, 5, and 6 submit but can't see any bugs persons 1,
2, and 3 because they're all in different companies.  This way in case a bug is
a suggestion instead of a bug, it will be kept seperated from any other people
you don't want to see it.