Open Bug 281926 Opened 20 years ago Updated 11 years ago

Improve Product Group Controls system (it doesn't easily support multiple customers per product)

Categories

(Bugzilla :: Administration, task, P2)

Product:
Bugzilla
Component:
Administration
Version:
2.18
Type:
task

Tracking

()

People

(Reporter: nb+bz, Unassigned)

References

(Depends on 1 open bug)

Details

A common use case for Bugzilla access controls is as follows:

A company has several customers: A, B, C.

A bug reported by someone at a customer should be visible to people at that
customer and to staff, but not to people at other customers.

A bug reported by staff should not be visible to any customers by default.

The staff should be able to permit or prevent any customer from viewing or
editing any bug.

Some of this can be done at present, for a single point-of-contact at each
customer, using reporter-accessible and cclist-accessible (the staff can add or
remove customer points-of-contact on the cc-list).  But a good solution using
groups is not possible.
Nothing fundamentally stops of from adding further group controls to do this. 
Does anyone have an idea of how to do this without making it even more
complicated?  Something tells me that we could use the visibility groups to
help, but I do not yet have a clear view of this.
Assignee: create-and-change → administration
Severity: normal → enhancement
Component: Creating/Changing Bugs → Administration
Summary: groups system doesn't support multiple customers → groups system doesn't support multiple customers per product
How about replacing the group access controls with a system which presents a
*growable* list of controls (like the advanced boolean search controls) like this:

Bug access requires membership in group X:
 - [Always/by default/optionally/never] if someone [in/out] of group [Y] creates
a bug in this product.
 - ...

<Make a new control> for group [Z].

The square brackets denote drop-downs.  The angle brackets denote a button.

I expect that for many uses in most installations, this would *look* simpler in
the admin interface.

There would have to be logic to test for contradictory controls, and a rule to
say what order the controls get applied in (which implies a sort order).

In the database, there would have to be two group fields (member_group and
access_group), and each current row would be split into two rows, one for the
MemberControl and one for the OtherControl, with a boolean Member field.

I'm probably not expressing this very clearly.  I could mock up some HTML.
So the controls in my example would look something like this:

Bug access requires membership in group CustomerAorStaff:
  - Always if created by someone in group CustomerA;
  - Optionally if created by someone in group Staff.

Bug access requires membership in group CustomerBorStaff:
  - Always if created by someone in group CustomerB;
  - Optionally if created by someone in group Staff.

Bug access requires membership in group CustomerCorStaff:
  - Always if created by someone in group CustomerC;
  - Optionally if created by someone in group Staff.

Bug access requires membership in group Staff:
  - By default if created by someone in group Staff.
  - Never if created by someone not in group Staff.

And the group CustomerAorStaff would inherit from CustomerA and from Staff, and
so on.
Thinking about it further, the controls don't require a "Never" option: that's
implied by the absence of a control (or of a row in the database).
I think we are now talking about 2 things...

1) A much better UI  ...  I think you are on the right track

2) A new control option that resembles MANDATORY/NA at first glance but really
wants to be different
perhaps.... "STICKY/NA"  where the bug MUST be in the group on entry if the
reporter is in this group AND NONE OF THE OTHER STICKY GROUPS and, once in the
STICKY group, cannot be removed from it by anyone.


(In reply to comment #4)
> I think we are now talking about 2 things...
> 
> 1) A much better UI  ...  I think you are on the right track
> 
> 2) A new control option that resembles MANDATORY/NA at first glance but really
> wants to be different
> perhaps.... "STICKY/NA"  where the bug MUST be in the group on entry if the
> reporter is in this group AND NONE OF THE OTHER STICKY GROUPS and, once in the
> STICKY group, cannot be removed from it by anyone.

Well, I was thinking of replacing the schema and the logic as well.  Something
like this:

     product_id mediumint not null,
     member_group_id mediumint not null,
     access_group_id mediumint not null,
     member_bool tinyint not null,
     control tinyint not null

where member_bool is 1 or 0 and control is one of MANDATORY, DEFAULT, SHOWN.

A row applies to bugs in a given product (product_id) and users either in
(member_bool = 1) or out (member_bool = 0) of a given group (member_group_id).

If control is MANDATORY, then when such a user creates such a bug, the bug gets
put in the access_group_id.  No control is shown when such a user creates or
edits such a bug.

If control is DEFAULT, then when such a user creates or edits such a bug, a
checkbox control for access_group_id is shown, defaulting to checked on bug
creation.

If control is SHOWN, then when such a user creates or edits such a bug, a
checkbox control for access_group_id is shown, defaulting to unchecked on bug
creation.

The important innovation here is to separate member_group_id from
access_group_id.  In the current system they are shared and this is what
prevents (say) Staff members from being able to choose whether to put a bug into
group CustomerA.

An alternative to the control field would be to have two booleans: one for
showing a checkbox and one for setting the group.  We don't bother to store the
rows for which both are False (i.e. "NA" rows).

There is an issue concerning conflicting rows: what happens if you have one row
saying "if someone in A makes a bug, put it in B, MANDATORY" and another which
says "if someone not in C makes a bug, offer to put it in B, SHOWN".  When
someone in A but not in C makes a bug, what do you do?  I think this can be
resolved by some simple rules (maybe MANDATORY > DEFAULT > SHOWN > none).  I
could be wrong about this part; we should discuss it.

The UI is just a question of showing the rows from this table and providing a
means to add, edit, or delete them.  The thing to avoid is what the current UI
does: to show all possible rows and let the admin say "this one on, that one
off".  With this proposal the number of possible rows is too large (groups^2),
so that temptation doesn't arise.

I think one of the problems with the current system is that the Edit Group
Access Controls page is too scary.  The MANDATORY/DEFAULT/SHOWN/NA selection is
tricky, and the fact that it appears twice, and some combinations are forbidden,
makes this more confusing.  I understand it (I think) but I still find myself
drawing on the whiteboard, chatting on #mozwebtools, etc, to try to apply it to
a new case.  I bet there are administrators who are put off by the whole thing.

An existing row in group_control_map becomes one or two rows in this table, in a
pretty obvious way (MemberControl and OtherControl each become one row, except
that NA entries don't become rows at all).

(In reply to comment #5)

> I think one of the problems with the current system is that the Edit Group
> Access Controls page is too scary.

I should emphasize that the current system is Excellent, and a Huge Improvement
on what we had before.  This proposal for further improvement is intended to
build on that work, not to denigrate it.
As a side note, one thing that would help is a "what-if" scenario or at the
minimum, a "view-as-userid=FOO" feature.

For example, all this group control stuff can get pretty unwieldly.  To test it,
I'll login as a particular userid just to see what he can really access.  It'd
be nicer if I could test this without login as that userid.  
  I like the UI idea. It looks better than what we have now, I *think*. I was
also having some general thoughts on the structure of groups, and perhaps this
should go in another bug, but here's what I'm wondering:

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

  Anyhow, this probably all belongs in a more large-scale "re-do groups system"
bug, but I thought I'd put out the information here since we're talking about
the basic UI and structure of product groups being confusing, and we also
started to mention schema.
OK, I've actually filed bug 282282 for what I was talking about in comment 8.
OS: FreeBSD → All
Hardware: PC → All
(In reply to comment #8)

> Is the "created by group X, so only visible to group Y" functionality really
> important?

It would meet a very common requirement: that staff members should be able to
control whether people at given customers can see particular bugs, while
otherwise customers are only able to see their own bugs.  As I say in comment 1,
this can be done at present by putting people on the CC list and using the
cclist_accessible flag.

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

Yes, your user group/bug group idea would have a similar effect: staff members
(i.e. people in group S) would be able to say "this bug is in bug groups P and
Q, this bug is in bug groups Q and R" *and* "this person is in user groups A and
B" *and* "people in user group A can see bugs in bug groups P and R, people in
user group B can see bugs in bug group Q".
The ability to configure this for a given bug, user, or bug group/user group
combination has to be a separate permission granted to group S.

I'm trying to take a single step closer to that most general concept.
A UI change to make the product group controls "growable" sounds like a good
one.  We already know, as we display the group controls, which ones are all
clear and which would need to be displayed.  As long as a group has any
relevence, we would display it and we would always permit one more group to be
selected.

Adding the control of group hierarchy to the same display is less obvious to me.
 I'd need to see a rather complete mockup.

I have a really clear idea of what this should look like, and will mock it up
when I have a minute.  Probably next week.
/me drools
Is this bug still applicable given that groups can solve the problem raised.  We have been using groups to hide customers' bugs from public view and from each other for the last 3 years using stock BZ 2.18.3.  They are only viewable by our staff.

We just created a group per customer, and default the group regexp to match all accounts at the customer's domain as well as ours (i.e. their and our staff).  When the customer submits a bug we ensure this group box is checked so bugs are hidden from view from other customers by default.  The bugs are also always private (hidden from the public) as we also created a product group where only customer groups are members, and customer's bugs are also defaulted into this group.  Customers can remove bugs from their own group (i.e. releasing them into the product group) to share bugs and their solutions with each other.  In addition, customers cannot make their bugs "public" as they are not given permission to remove the bug from the product group, only our staff are.
I forgot to add that the only issue we encountered was a HUGE list of groups appearing at the bottom of each bug when being edited/added by our staff.  This was very easily resolved by a bit of javascript and template changes where we hide the group list by default and show/hide it with the javascript.  It can just as easily be sorted by switching groups from lists to a multi-select drop down.
Priority: -- → P2
Summary: groups system doesn't support multiple customers per product → Improve Product Group Controls system (it doesn't easily support multiple customers per product)
Depends on: 658887
You need to log in before you can comment on or make changes to this bug.