282282 - Distinction between bug groups, user groups, and permissions

Status: NEW

(Bugzilla :: Administration, task)

Description

[Max Kanat-Alexander]

I came up with this idea in bug 281926 comment 8. Here's what I wrote:

  Why doesn't the system work in a way that *all* bugs are essentially private,
and then can only be seen if you have certain group memberships? Then public
Bugzillas can have an "all users" group that can see all bugs. I just think that
would make all this logic a lot easier. That is, we'd have an "implcit deny" and
then have to specify who we allowed. Just like most permissions systems work in
a Unix filesystem or in a Windows Domain.

  This is really also part of the "convert system groups to privileges"
functionality. Because then we'd be able to give certain USER groups
*privileges* to see certain BUG groups. (So we need a distinction between user
and bug groups, also.)

  Is the "created by group X, so only visible to group Y" functionality really
important? That seems like a very difficult thing to wrap my mind around, as an
administrator. That is, my policy would normally be "if the bug is a part of
this group of bugs, only this set of users can see it" -- that's the
functionality that I really want to implement. I'd also want to give the *users*
in *user group A* the *permission* to see *bugs* in *bug group B*.

Comment 1

[JensG]

Attachment: Groups vs Permision semantics

If asked, the first change I would recommend is to rename "groups" into "permissions", because that's what they really are. The term "group" is confusing, because the terminology implies an INCLUSION, whereas it really is focused about EXCLUSION. The next thing is, that I would make groups work as expected.

Let's say we have some bugs and groups assigned as follows:
- Bug 815   Groups: Foo, Bar, Baz
- Bug 4711  Groups: Foo

In order to see Bug 815, a user must have all three groups Foo, Bar, Baz. If he/she has only Foo, only Bug 4711 is accessible. Thus, the "groups" are really "permissions", and in order to see both bugs you need all the permissions Foo, Bar and Baz.

If it were for real "groups", you could see Bug 815 if you were in EITHER ONE of the groups. That single fact makes it confusing, and the info text below and the huge explanatory table at the bottom of the product groups management page is a clear, first-class, indicator about the confusing and counter-intuitivity level:

> Only users in all of the selected groups can view this bug: 
> Unchecking all boxes makes this a more public bug. 

and

> Please note that the above table delineates the only allowable combinations for the MemberControl and OtherControl field settings.
> Attempting to submit a combination not listed there (e.g. Mandatory/NA, Default/Shown, etc.) will produce an error message. 

Nobody would need this explanation (and despite of it still fail on the first try using it) if it only would work as expected.

Given our first scenario, let's assume I want to add a fourth group "Zalgo" which shall be allowed to see only a subset of all bugs, for example 815, but not 4711. 

Now, what I have to do is - roughly - as follows:
- create a group "non-Zalgo" 
- add all users by group inheritance to the "non-Zalgo" group, except the Zalgo users
- modify the product to set the "non-Zalgo" group as "default"
- do a mass change of all 4 million bugs that are supposed to be hidden from Zalgo users to add the "non-Zalgo" group

If it were named "permissions" instead of "groups", it would not become easier, but it would become more clear what it really is: A user has some permissions, and the bug indicates what permissisons are needed.

However, if groups would work as expected, I would do it the opposite way:
- add a new Zalgo group
- add the Zalgo users to that group
- no need to change group inheritances at all
- set up the Zalgo group as "shown" at the product
- mass-change only the 35 Zalgo bugs and activate the [x] Zalgo group 

The user belongs to one or more group and can see all bugs, that are assigned to at least one of these groups. Just like *nix file permissions.

Now, looking at these steps: What is easier, more understandable, and less prone to error?