group_control_map.canconfirm and friends

[Nick Barnes]

Dear all, but especially LpSolit and mkanat,

Preparing updates to the online schema doc, I've been looking at the
three columns added to the group_control_map table: editbugs,
editcomponents, and canconfirm.  This is from the patch by LpSolit,
reviewed by mkanat, for bug 189627.  If I'm reading the code
correctly, these columns are used by in_group() in Bugzilla/User.pm.
Using "editcomponents" as an example, in_group uses the columns to
answer questions of the form "is user U entitled to edit the set of
components for product P".  A call is made:

user->in_group('editcomponents', $product_id);

If the user is in the global "editcomponents" group, this returns 1.
Otherwise, if there is at least one group in group_control_map,
           for this product,
           which has group_control_map.editcomponents set,
           and of which this user is a member,
it returns 1.
Otherwise, it returns 0.

There is also get_products_by_permission() in Bugzilla/User.pm.  With
the same 'editcomponents' example, this returns a list of the products
which have a line in group_control_map with the editcomponents flag
set, such that the user is in the group.

Now, this indicates to me that (say) editcomponents privileges for a
given product are given to everyone who is in *any* group with a
suitable row in group_control_map, as opposed only to those people who
are in *all* such groups.  It's a union permission, in contrast to the
intersection permissions which most of the groups system uses.

While I don't have a working 3.0 installation, I can't tell whether
editproducts.cgi lets me put more than one such row in
group_control_map, but let's imagine that it did.

Have I got this right?  Was this the intended semantics?  I've read
the comment thread in 189627 but without much illumination on this
question.

Nick B