1220125 - or_groups not useful in current form with makeproductgroups and group security

Status: RESOLVED WORKSFORME

(Bugzilla :: Administration, task)

Description

[Alex Schuilenburg]

I know makeproductgroups is being discontinued (bug 1136745), which is why I raise this as some of us still use product groups so as not to expose new products or confidential projects to the outside world.

The new or_groups option would simplify our customer confidentiality setup (customer bugs for a product are visible within a customer group only), except for the fact that all customers are also members of the product group which means they can see each other's bugs. (Product bugs are mandatory to product groups).

While we can achieve customer bug confidentiality using AND (or_groups=0) it becomes complex setting up groups when we have partnerships between customers who wish to share access to certain bugs. Or rather, customers have to remember to drop their own and all other customer groups from the bug, while adding the bug into the partnership group, to make it visible to all partners.  It is obviously simpler just enable or_groups and add the bug to the partnership group.

However, enabling or_groups then makes the bugs visible to all members of the product groups when makeproductgroups is enabled.

The solution to this is relatively simple and I am happy to contribute this back to the project if others think this useful. The solution is simply to exclude the product group from the OR through the introduction of an additional localconfig setting.  At the moment we do this by excluding groups where products.name == groups.name, which is simple enough but cannot be guaranteed since this is not guaranteed (you could theoretically rename the product group). Hence to guarantee this may require additional fields in the DB.

Worth contributing should I just maintain as a custom bugzilla patch?

Comment 1

[Frédéric Buclin]

There is no reason to make exceptions for some given groups. This is going to confuse more people. Moreover, as you said, the makeproductgroups parameter is gone and so new groups are not created automatically.

To fix your problem, the "product group", as you name it (the one with product.name == group.name), shouldn't contain any customers. This way, the product remains hidden from the public, and customers cannot access each other bugs.

Comment 2

[Alex Schuilenburg]

(In reply to Frédéric Buclin from comment #1)
> To fix your problem, the "product group", as you name it (the one with
> product.name == group.name), shouldn't contain any customers. This way, the
> product remains hidden from the public, and customers cannot access each
> other bugs.

Therein lies the problem.  The customers need access to generic product bugs, and fixes, provided by us and so need to remain members of the product group. These "open" product bugs  need to be hidden from the general public.

I am also confused. If the customer is not a member of the product group (or project), how can they see see the product (or project). I must be missing something.

Anyway, what I have now works for us. It hides confidential projects and allows co-operating customers and partners to share bugs by simply placing them in a common group while restricting visibility from the public.

Comment 3

[Frédéric Buclin]

(In reply to Alex Schuilenburg from comment #2)
> Therein lies the problem.  The customers need access to generic product
> bugs, and fixes, provided by us and so need to remain members of the product
> group. These "open" product bugs  need to be hidden from the general public.

I guess generic bugs are set manually? In that case, you could create another "customers_public" group, add all customers in it, and when a bug should be accessible to your customers, you restrict this bug to this customers_public group. This way, all your customers can access the bug, but it remains hidden from the external public.


> I am also confused. If the customer is not a member of the product group (or
> project), how can they see see the product (or project).

You said you didn't want your customers to see other customer bugs, so these bugs must remain hidden, which is what my proposal does. If you mean to see the product in order to file bugs in it, then you simply need to set the ENTRY bit from the Edit Group Controls page for all your customer groups, and so they will be able to report bugs in the product, but not see all other bugs by default.

Comment 4

[Alex Schuilenburg]

(In reply to Frédéric Buclin from comment #3)
> I guess generic bugs are set manually? In that case, you could create
> another "customers_public" group, add all customers in it, and when a bug
> should be accessible to your customers, you restrict this bug to this
> customers_public group. This way, all your customers can access the bug, but
> it remains hidden from the external public.

They are, and we already have a customer_public group into which such bugs are only restricted to. So this is easy.

> You said you didn't want your customers to see other customer bugs, so these
> bugs must remain hidden, which is what my proposal does. If you mean to see
> the product in order to file bugs in it, then you simply need to set the
> ENTRY bit from the Edit Group Controls page for all your customer groups,
> and so they will be able to report bugs in the product, but not see all
> other bugs by default.

Ah, thanks, that was what I was missing. I had failed to appreciate that "Entry" makes the product visible to members of the group. They already have "Default/NA" controls for the customer group so looks like removing customers from the product group and setting Entry will do exactly what I need and simplify my extension.

Thanks again for the help.