3.14. Groups and Group Security
Groups allow for separating bugs into logical divisions. Groups are typically used to to isolate bugs that should only be seen by certain people. For example, a company might create a different group for each one of its customers or partners. Group permissions could be set so that each partner or customer would only have access to their own bugs. Or, groups might be used to create variable access controls for different departments within an organization. Another common use of groups is to associate groups with products, creating isolation and access control on a per-product basis.
Groups and group behaviors are controlled in several places:
The group configuration page. To view or edit existing groups, or to create new groups, access the "Groups" link from the page footer. This section of the manual deals primarily with the aspect of group controls accessed on this page.
Global configuration parameters. Bugzilla has several parameters that control the overall default group behavior and restriction levels. For more information on the parameters that control group behavior globally, see Section 3.1.9.
Product association with groups. Most of the functionality of groups and group security is controlled at the product level. Some aspects of group access controls for products are discussed in this section, but for more detail see Section 3.4.4.
Group access for users. See Section 3.14.3 for details on how users are assigned group access.
Group permissions are such that if a bug belongs to a group, only members of that group can see the bug. If a bug is in more than one group, only members of all the groups that the bug is in can see the bug. For information on granting read-only access to certain people and full edit access to others, see Section 3.4.4.
 | By default, bugs can also be seen by the Assignee, the Reporter, and by everyone on the CC List, regardless of whether or not the bug would typically be viewable by them. Visibility to the Reporter and CC List can be overridden (on a per-bug basis) by bringing up the bug, finding the section that starts with "Users in the roles selected below..." and un-checking the box next to either 'Reporter' or 'CC List' (or both). |
3.14.1. Creating Groups
To create a new group, follow the steps below:
Select the "Groups" link in the page footer.
A table of all the existing groups is displayed. Below the table is a description of all the fields. To create a new group, select the "Add Group" link under the table of existing groups.
There are four fields to fill out. These fields are documented below the form. Choose a name and description for the group. Decide whether this group should be used for bugs (in all likelihood this should be selected). Optionally, choose a regular expression that will automatically add any matching users to the group. The regular expression can be useful, for example, to automatically put all users from the same company into one group (if the group is for a specific customer or partner).
If "User RegExp" is filled out, users whose email addresses match the regular expression will automatically be members of the group as long as their email addresses continue to match the regular expression. If their email address changes and no longer matches the regular expression, they will be removed from the group. Versions 2.16 and older of Bugzilla did not automatically remove users who's email addresses no longer matched the RegExp.
If specifying a domain in the regular expression, end the regexp with a "$". Otherwise, when granting access to "@mycompany\.com", access will also be granted to 'badperson@mycompany.com.cracker.net'. Use the syntax, '@mycompany\.com$' for the regular expression.
After the new group is created, it can be edited for additional options. The "Edit Group" page allows for specifying other groups that should be included in this group and which groups should be permitted to add and delete users from this group. For more details, see Section 3.14.2.
3.14.2. Editing Groups and Assigning Group Permissions
To access the "Edit Groups" page, select the "Groups" link in the page footer. A table of all the existing groups is displayed. Click on a group name you wish to edit or control permissions for.
The "Edit Groups" page contains the same four fields present when creating a new group. Below that are two additional sections, "Group Permissions," and "Conversion of groups created with Bugzilla versions 2.16 and prior". The "Conversion..." section compensates for the default behavior of version 2.16 and prior by allowing for the mass removal of members who were put in this group via the regular expression. The "Group Permissions" section requires further explanation.
The "Group Permissions" section on the "Edit Groups" page contains a table listing each group next to two columns of check boxes. The first column is marked "Grant" and the second is marked "Inherit". If the 'usevisibilitygroups' parameter is in use (see Section 3.1) an additional column, "Visible", is displayed. The way these controls allow groups to relate to one another is called inheritance. Use this table to configure group permissions as follows (the discussion below assumes the group being edited is called "Group1").
For any group in the table, if "Visible" is checked (only applicable if the 'usevisibilitygroups' parameter is in use), then all members of the checked group will be able to see "Group1" and all of its members. Further, only members of groups with "Visible" checked will be aware of "Group1".
For any group in the table, if "Grant" is checked then any members of the checked groups will be able to grant (or revoke) membership in "Group1" to any other user - even if the users in the checked group are not administrators. In other words, the members of any checked group are like group administrators for "Group1".
For any group in the table, if "Inherit" is checked, then any members of the checked group will also be members of "Group1". In other words, members of any checked group will inherit membership in "Group1".
3.14.3. Assigning Users to Groups
A User can become a member of a group in several ways:
The user can be explicitly placed in the group by editing the user's profile. This can be done by accessing the "Users" link from the page footer. Use the search form to find the user you want to edit group membership for, and click on their email address in the search results to edit their profile. The profile page lists all the groups, and indicates if the user is a member of the group either directly or indirectly. More information on indirect group membership is below. For more details on User administration, see Section 3.2.
The group can inherit members from other groups. This is indicated by square brackets around the check box next to the group name in the user's profile. See Section 3.14.2 for details on group inheritance.
The user's email address can match the regular expression that has been specified to automatically grant membership to the group. This is indicated by "*" around the check box by the group name in the user's profile. See Section 3.14.1 for details on the regular expression option when creating groups.
3.14.4. Assigning Group Controls to Products
The primary functionality of groups is derived from the relationship of groups to products. The concepts around segregating access to bugs with product group controls can be confusing. For details and examples on this topic, see Section 3.4.4.