Group combinations

Gervase Markham gerv at
Thu Mar 4 08:58:31 UTC 2004

Dear developers,

Architecture question. It's about groups, so unfortunately it's quite a 
long mail.

Initial assertion: a common use of non-product groups is to classify 
customers, and keep them separate from one another. So Customer A 
accounts are in Group A, and they only sees bugs they filed and bugs the 
company has let them see. The same for Customer B in Group B, and so on. 
One would want to force each customer to file bugs in their group, using 
the Mandatory For Members flag for that group on all products.

Currently, for historical reasons, our groups system uses an AND model - 
that is, if a bug is in group A and group B, only users in both groups A 
AND B can see it.

This seems fine at first glance, but breaks when you introduce the 
employees of the Bugzilla owner. Which groups are they in?

Under the current model, they have to be in their own group (for 
company-private bugs, i.e. the majority) but also members of every 
customer group, so they can see the bugs they are showing to customers - 
remember, it's AND.

Group inheritance? Maybe. But the problem then is that anyone in Group A 
(including employees) files bugs in Group A mandatorily. If you 
remember, we set this so Customer A people don't accidentally create 
public bugs. That means that bugs employees file go into Group A, and 
can never be seen by Customer B, even if that's who they are filing the 
bug for. But this works the other way, too - the bugs go into Group B 
also! The upshot is that bugs employees file can never be seen by any 
customer! Oh dear.

If you want to sub-divide your employees into groups, it gets even worse.

Basically, the AND model doesn't work in this environment.

There are a few possible solutions:

- Change wholesale to an OR model. Because of the complexity of the new 
groups system, this could be a migration nightmare. There are several 
ways we could approach that.

- Offer users a choice of AND and OR, making all new installations OR. 
This has the disadvantage that it's one more variable to find out when 
diagnosing problems by email, and perhaps increases the potential of 
security holes.

- Make insidergroup more special - people in insidergroup can always see 
all bugs. That would solve the "employees" problem, but not the "two 
customers seeing the same bug" problem.



More information about the developers mailing list