Groups allow the administrator to isolate bugs or products that should only be seen by certain people. The association between products and groups is controlled from the product edit page under "Edit Group Controls."
If the makeproductgroups param is on, a new group will be automatically created for every new product. It is primarily available for backward compatibility with older sites.
Note that group permissions are such that you need to be a member of all the groups a bug is in, for whatever reason, to see that bug. Similarly, you must be a member of all of the entry groups for a product to add bugs to a product and you must be a member of all of the canedit groups for a product in order to make any change to bugs in that product.
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). |
To create Groups:
Select the "groups" link in the footer.
Take a moment to understand the instructions on the "Edit Groups" screen, then select the "Add Group" link.
Fill out the "Group", "Description", and "User RegExp" fields. "User RegExp" allows you to automatically place all users who fulfill the Regular Expression into the new group. When you have finished, click "Add".
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.
This is a change from 2.16 where the regular expression resulted in a user acquiring permanent membership in a group. To remove a user from a group the user was in due to a regular expression in version 2.16 or earlier, the user must be explicitly removed from the group. This can easily be done by pressing buttons named 'Remove Memberships' or 'Remove Memberships included in regular expression' under the table. |
If specifying a domain in the regexp, make sure you end the regexp with a $. Otherwise, when granting access to "@mycompany\.com", you will allow access to 'badperson@mycompany.com.cracker.net'. You need to use '@mycompany\.com$' as the regexp. |
If you plan to use this group to directly control access to bugs, check the "use for bugs" box. Groups not used for bugs are still useful because other groups can include the group as a whole.
After you add your new group, edit the new group. On the edit page, you can specify other groups that should be included in this group and which groups should be permitted to add and delete users from this group.
Users can become a member of a group in several ways.
The user can be explicitly placed in the group by editing the user's own profile
The group can include another group of which the user is a member.
The user's email address can match a regular expression that the group specifies to automatically grant membership to the group.
On the product edit page, there is a page to edit the "Group Controls" for a product. This allows you to configure how a group relates to the product. Groups may be applicable, default, and mandatory as well as used to control entry or used to make bugs in the product totally read-only unless the group restrictions are met.
For each group, it is possible to specify if membership in that group is...
required for bug entry,
Not applicable to this product(NA), a possible restriction for a member of the group to place on a bug in this product(Shown), a default restriction for a member of the group to place on a bug in this product(Default), or a mandatory restriction to be placed on bugs in this product(Mandatory).
Not applicable by non-members to this product(NA), a possible restriction for a non-member of the group to place on a bug in this product(Shown), a default restriction for a non-member of the group to place on a bug in this product(Default), or a mandatory restriction to be placed on bugs in this product when entered by a non-member(Mandatory).
required in order to make any change to bugs in this product including comments.
These controls are often described in this order, so a product that requires a user to be a member of group "foo" to enter a bug and then requires that the bug stay restricted to group "foo" at all times and that only members of group "foo" can edit the bug even if they otherwise could see the bug would have its controls summarized by...
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT |
To permit any user to file bugs in each product (A, B, C...) and to permit any user to submit those bugs into a security group....
Product A... security: SHOWN/SHOWN Product B... security: SHOWN/SHOWN Product C... security: SHOWN/SHOWN |
To permit any user to file bugs in a Security product while keeping those bugs from becoming visible to anyone outside the securityworkers group unless a member of the securityworkers group removes that restriction....
Product Security... securityworkers: DEFAULT/MANDATORY |
To permit users of product A to access the bugs for product A, users of product B to access product B, and support staff to access both, 3 groups are needed
Support: Contains members of the support staff.
AccessA: Contains users of product A and the Support group.
AccessB: Contains users of product B and the Support group.
Once these 3 groups are defined, the products group controls can be set to..
Product A... AccessA: ENTRY, MANDATORY/MANDATORY Product B... AccessB: ENTRY, MANDATORY/MANDATORY |
Optionally, the support group could be permitted to make bugs inaccessible to the users and could be permitted to publish bugs relevant to all users in a common product that is read-only to anyone outside the support group. That configuration could be...
Product A... AccessA: ENTRY, MANDATORY/MANDATORY Support: SHOWN/NA Product B... AccessB: ENTRY, MANDATORY/MANDATORY Support: SHOWN/NA Product Common... Support: ENTRY, DEFAULT/MANDATORY, CANEDIT |