1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
5
>Groups and Group Security</TITLE
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
10
TITLE="The Bugzilla Guide - 3.0.4 Release"
11
HREF="index.html"><LINK
13
TITLE="Administering Bugzilla"
14
HREF="administration.html"><LINK
17
HREF="quips.html"><LINK
19
TITLE="Checking and Maintaining Database Integrity"
20
HREF="sanitycheck.html"></HEAD
31
SUMMARY="Header navigation table"
40
>The Bugzilla Guide - 3.0.4 Release</TH
56
>Chapter 3. Administering Bugzilla</TD
62
HREF="sanitycheck.html"
77
>3.14. Groups and Group Security</A
80
> Groups allow for separating bugs into logical divisions.
81
Groups are typically used to
82
to isolate bugs that should only be seen by certain people. For
83
example, a company might create a different group for each one of its customers
84
or partners. Group permissions could be set so that each partner or customer would
85
only have access to their own bugs. Or, groups might be used to create
86
variable access controls for different departments within an organization.
87
Another common use of groups is to associate groups with products,
88
creating isolation and access control on a per-product basis.
91
> Groups and group behaviors are controlled in several places:
99
> The group configuration page. To view or edit existing groups, or to
100
create new groups, access the "Groups" link from the page footer.
101
This section of the manual deals primarily with the aspect of
102
group controls accessed on this page.
107
> Global configuration parameters. Bugzilla has several parameters
108
that control the overall default group behavior and restriction
109
levels. For more information on the parameters that control
110
group behavior globally, see <A
111
HREF="parameters.html#param-group-security"
118
> Product association with groups. Most of the functionality of groups
119
and group security is controlled at the product level. Some aspects
120
of group access controls for products are discussed in this section,
121
but for more detail see <A
122
HREF="products.html#product-group-controls"
129
> Group access for users. See <A
130
HREF="groups.html#users-and-groups"
133
details on how users are assigned group access.
138
> Group permissions are such that if a bug belongs to a group, only members
139
of that group can see the bug. If a bug is in more than one group, only
142
> the groups that the bug is in can see
143
the bug. For information on granting read-only access to certain people and
144
full edit access to others, see <A
145
HREF="products.html#product-group-controls"
163
SRC="../images/note.gif"
170
> By default, bugs can also be seen by the Assignee, the Reporter, and
171
by everyone on the CC List, regardless of whether or not the bug would
172
typically be viewable by them. Visibility to the Reporter and CC List can
173
be overridden (on a per-bug basis) by bringing up the bug, finding the
174
section that starts with <SPAN
176
>"Users in the roles selected below..."</SPAN
178
and un-checking the box next to either 'Reporter' or 'CC List' (or both).
190
>3.14.1. Creating Groups</A
193
> To create a new group, follow the steps below:
201
> Select the <SPAN
204
> link in the page footer.
209
> A table of all the existing groups is displayed. Below the table is a
210
description of all the fields. To create a new group, select the
214
> link under the table of existing groups.
219
> There are four fields to fill out. These fields are documented below
220
the form. Choose a name and description for the group. Decide whether
221
this group should be used for bugs (in all likelihood this should be
222
selected). Optionally, choose a regular expression that will
223
automatically add any matching users to the group. The regular
224
expression can be useful, for example, to automatically put all users
225
from the same company into one group (if the group is for a specific
226
customer or partner).
242
SRC="../images/note.gif"
252
> is filled out, users whose email
253
addresses match the regular expression will automatically be
254
members of the group as long as their email addresses continue
255
to match the regular expression. If their email address changes
256
and no longer matches the regular expression, they will be removed
257
from the group. Versions 2.16 and older of Bugzilla did not automatically
258
remove users who's email addresses no longer matched the RegExp.
278
SRC="../images/warning.gif"
285
> If specifying a domain in the regular expression, end
286
the regexp with a "$". Otherwise, when granting access to
287
"@mycompany\.com", access will also be granted to
288
'badperson@mycompany.com.cracker.net'. Use the syntax,
289
'@mycompany\.com$' for the regular expression.
298
> After the new group is created, it can be edited for additional options.
299
The "Edit Group" page allows for specifying other groups that should be included
300
in this group and which groups should be permitted to add and delete
301
users from this group. For more details, see <A
302
HREF="groups.html#edit-groups"
315
>3.14.2. Editing Groups and Assigning Group Permissions</A
318
> To access the "Edit Groups" page, select the
322
> link in the page footer.
323
A table of all the existing groups is displayed. Click on a group name
324
you wish to edit or control permissions for.
327
> The "Edit Groups" page contains the same four fields present when
328
creating a new group. Below that are two additional sections, "Group
329
Permissions," and "Conversion of groups created with Bugzilla versions
330
2.16 and prior". The "Conversion..." section compensates for the default
331
behavior of version 2.16 and prior by allowing for the mass removal of
332
members who were put in this group via the regular expression. The
333
"Group Permissions" section requires further explanation.
336
> The "Group Permissions" section on the "Edit Groups" page contains a table
337
listing each group next to two columns of check boxes. The first column is
338
marked "Grant" and the second is marked "Inherit". If the
339
'usevisibilitygroups' parameter is in use (see
341
HREF="parameters.html"
343
>) an additional column, "Visible", is displayed.
344
The way these controls allow groups to relate
345
to one another is called <EM
348
to configure group permissions as follows (the discussion below assumes the
349
group being edited is called "Group1").
352
> For any group in the table, if "Visible" is checked (only applicable if
353
the 'usevisibilitygroups' parameter is in use), then all members of the
354
checked group will be able to see "Group1" and all of its members. Further,
357
> members of groups with "Visible" checked will
358
be aware of "Group1".
361
> For any group in the table, if "Grant" is checked then any members of
362
the checked groups will be able to grant (or revoke) membership in
363
"Group1" to any other user - even if the users in the checked group
364
are not administrators. In other words, the members of any checked
365
group are like group administrators for "Group1".
368
> For any group in the table, if "Inherit" is checked, then any members
369
of the checked group will also be members of "Group1". In other words,
370
members of any checked group will inherit membership in "Group1".
378
NAME="users-and-groups"
379
>3.14.3. Assigning Users to Groups</A
382
> A User can become a member of a group in several ways:
390
> The user can be explicitly placed in the group by editing
391
the user's profile. This can be done by accessing the "Users" link
392
from the page footer. Use the search form to find the user
393
you want to edit group membership for, and click on their email
394
address in the search results to edit their profile. The profile
395
page lists all the groups, and indicates if the user is a member of
396
the group either directly or indirectly. More information on indirect
397
group membership is below. For more details on User administration,
399
HREF="useradmin.html"
406
> The group can inherit members from other groups. This is indicated by
407
square brackets around the check box
408
next to the group name in the user's profile.
410
HREF="groups.html#edit-groups"
412
> for details on group inheritance.
417
> The user's email address can match the regular expression
418
that has been specified to automatically grant membership to
419
the group. This is indicated by "*" around the check box by the
420
group name in the user's profile.
422
HREF="groups.html#create-groups"
425
the regular expression option when creating groups.
436
>3.14.4. Assigning Group Controls to Products</A
439
> The primary functionality of groups is derived from the relationship of
440
groups to products. The concepts around segregating access to bugs with
441
product group controls can be confusing. For details and examples on this
443
HREF="products.html#product-group-controls"
454
SUMMARY="Footer navigation table"
483
HREF="sanitycheck.html"
499
HREF="administration.html"
507
>Checking and Maintaining Database Integrity</TD
b'\\ No newline at end of file'
added
removed
docs/html/groups.html
