Groups allow for separating bugs into logical divisions. Groups are typically used 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:
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 Assigning Group Controls to Products.
Note
By default, bugs can also be seen by the Assignee, the Reporter, and 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).
To create a new group, follow the steps below:
Select the Administration link in the page footer, and then select the Groups link from the Administration page.
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 five 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, and choose an icon that will help identify user comments for 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).
Note
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 whose email addresses no longer matched the RegExp.
Warning
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 Editing Groups and Assigning Group Permissions.
To access the "Edit Groups" page, select the Administration link in the page footer, and then select the Groups link from the Administration page. 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 five fields present when creating a new group. Below that are two additional sections, "Group Permissions" and "Mass Remove". The "Mass Remove" option simply removes all users from the group who match the regular expression entered. The "Group Permissions" section requires further explanation.
The "Group Permissions" section on the "Edit Groups" page contains four sets of permissions that control the relationship of this group to other groups. If the usevisibilitygroups parameter is in use (see Parameters) two additional sets of permissions are displayed. Each set consists of two select boxes. On the left, a select box with a list of all existing groups. On the right, a select box listing all groups currently selected for this permission setting (this box will be empty for new groups). The way these controls allow groups to relate to one another is called inheritance. Each of the six permissions is described below.
A User can become a member of a group in several ways:
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 Assigning Group Controls to Products.
This documentation undoubtedly has bugs; if you find some, please file them here.