gerv at mozilla.org
Thu Mar 4 08:58:31 UTC 2004
Architecture question. It's about groups, so unfortunately it's quite a
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
- 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