Joel Peshkin wrote on 1/10/06 7:41 PM:

What you are really looking for is something that is SUFFICIENT/NA
meaning that the bug MUST be restricted to AT LEAST NE of a set of
groups. If we were to do that (and I am not sure it is worth the
complexity), a user who was a member of only one SUFFICIENT group would
see that group as MANDATRY, but a user who was a member of several
would be able to choose one (or more?) of the SUFFICIENT groups.

How much complexity would it be? That actually sounds like it might be
useful.

For what it's worth, here's the approach that I am taking for my
company. I'm adding a group for my company's staff and a group for
each client for which we wish to give limited access to Bugzilla. The
Staff group automatically inherits any of these client groups. Then,
we add all our bugs to the Staff group with Default/NA access control.
Next, for products to which a client needs limited access, we add the
client's group with access control Default/Na.

At this point, if a Staff user adds a bug and doesn't change the
default settings, a new bug will belong to the Staff group and any
client groups that need limited access to the given product which will
block anyone other than a Staff user from seeing it as they are the
only ones who belong to all groups. In additon, all our old bugs will
be added to the Staff group to protect them from client eyes.

If a Client enters a bugs for the product and doesn't change the
default settings, a new bug will belong to only that Client's group,
and therefore only Staff users (who inherit the Client group) and that
Client's fellow users will be able to access the bug.

Finally, to keep Staff users and Clients from shooting themselves in
the foot by changing these settings, I have changed the edit.html
template so that the Group Permissions settings area of a bug is only
visible to admins. Thus, the behavior that we expect is automatically
enforced unless an admin wishes to change it.

Another benefit of this approach is that our clients will then be
unable to see what other clients have this special access to a common
product.

This solution works for us and actually seems better than the
Mandatory/NA for which I had been pining earlier in the week.

Regards,

John

This sounds like an extremely valuable pattern that should be
generally available. We're looking for exactly this functionality.

To summarize:

* product, with components
* Multiple 'client' groups, who must be able to file bugs
* Each client group must be disjoint from all others, able to see
only bugs filed by users in their group
* A group of developers ("Staff") who must be able to see all bugs
filed by all users
* The ability to mark certain bugs as visible by more than one
client group (a "staff-only" function).

John Weathers wrote:
For what it's worth, here's the approach that I am taking for my
company. I'm adding a group for my company's staff and a group for
each client for which we wish to give limited access to Bugzilla. The
Staff group automatically inherits any of these client groups. Then,
we add all our bugs to the Staff group with Default/NA access control.
Next, for products to which a client needs limited access, we add the
client's group with access control Default/Na.

At this point, if a Staff user adds a bug and doesn't change the
default settings, a new bug will belong to the Staff group and any
client groups that need limited access to the given product which will
block anyone other than a Staff user from seeing it as they are the
only ones who belong to all groups. In additon, all our old bugs will
be added to the Staff group to protect them from client eyes.

If a Client enters a bugs for the product and doesn't change the
default settings, a new bug will belong to only that Client's group,
and therefore only Staff users (who inherit the Client group) and that
Client's fellow users will be able to access the bug.

Finally, to keep Staff users and Clients from shooting themselves in
the foot by changing these settings, I have changed the edit.html
template so that the Group Permissions settings area of a bug is only
visible to admins. Thus, the behavior that we expect is automatically
enforced unless an admin wishes to change it.

Another benefit of this approach is that our clients will then be
unable to see what other clients have this special access to a common
product.

This solution works for us and actually seems better than the
Mandatory/NA for which I had been pining earlier in the week.

Regards,

John

Can you let me know the exact changes you made to the edit.html file to
do this? I'm running bugzilla 3.0.

John Weathers wrote:
For what it's worth, here's the approach that I am taking for my
company. I'm adding a group for my company's staff and a group for
each client for which we wish to give limited access to Bugzilla. The
Staff group automatically inherits any of these client groups. Then,
we add all our bugs to the Staff group with Default/NA access control.
Next, for products to which a client needs limited access, we add the
client's group with access control Default/Na.

At this point, if a Staff user adds a bug and doesn't change the
default settings, a new bug will belong to the Staff group and any
client groups that need limited access to the given product which will
block anyone other than a Staff user from seeing it as they are the
only ones who belong to all groups. In additon, all our old bugs will
be added to the Staff group to protect them from client eyes.

If a Client enters a bugs for the product and doesn't change the
default settings, a new bug will belong to only that Client's group,
and therefore only Staff users (who inherit the Client group) and that
Client's fellow users will be able to access the bug.

Finally, to keep Staff users and Clients from shooting themselves in
the foot by changing these settings, I have changed the edit.html
template so that the Group Permissions settings area of a bug is only
visible to admins. Thus, the behavior that we expect is automatically
enforced unless an admin wishes to change it.

Another benefit of this approach is that our clients will then be
unable to see what other clients have this special access to a common
product.

This solution works for us and actually seems better than the
Mandatory/NA for which I had been pining earlier in the week.

Regards,

John