</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ usevisibilitygroups
+ </term>
+ <listitem>
+ <para>
+ If selected, user visibility will be restricted to members of
+ groups, as selected in the group configuration settings.
+ Each user-defined group can be allowed to see members of selected
+ other groups.
+ For details on configuring groups (including the visibility
+ restrictions) see <xref linkend="edit-groups"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>
querysharegroup
</variablelist>
<para>
- When editing a product there is also a link to edit
- <xref linkend="product-group-controls"/>.
+ When editing a product there is also a link to edit Group Access Controls,
+ see <xref linkend="product-group-controls"/>.
</para>
+
+ <section id="create-product">
+ <title>Creating New Products</title>
+
<para>
To create a new product:
</para>
<orderedlist>
<listitem>
<para>
- Select <quote>products</quote> from the footer.
+ Select <quote>Products</quote> from the page footer.
</para>
</listitem>
</listitem>
</orderedlist>
+ </section>
+
+ <section id="edit-products">
+ <title>Editing Products</title>
- <section id="product-group-controls" xreflabel="Group Access Controls">
- <title>Assigning Group Controls to Products</title>
- <para>
- On the <quote>Product Edit</quote> page,
- there is a link called
- <quote>Edit Group Access Controls</quote>.
- The settings on this page control the relationship
- of the groups to the product being edited.
- </para>
- <para>
- Groups may be applicable, default, and
- mandatory for each product. Groups can also control access
- to bugs for a given product, or be used to make bugs
- for a product totally read-only unless the group
- restrictions are met.
- </para>
- <para>
- If any group has <emphasis>Entry</emphasis> selected, then the
- product will restrict bug entry to only those users
- who are members of all the groups with
- <emphasis>Entry</emphasis> selected.
- </para>
- <para>
- If any group has <emphasis>Canedit</emphasis> selected,
- then the product will be read-only for any users
- who are not members of all of the groups with
- <emphasis>Canedit</emphasis> selected. ONLY users who
- are members of all the <emphasis>Canedit</emphasis> groups
- will be able to edit. This is an
- additional restriction that further limits
- what can be edited by a user.
- </para>
- <para>
- The following settings let you
- choose privileges on a <emphasis>per-product basis</emphasis>.
- This is a convenient way to give privileges to
- some users for some products only, without having
- to give them global privileges which would affect
- all products.
- </para>
- <para>
- Any group having <emphasis>editcomponents</emphasis>
- selected allows users who are in this group to edit all
- aspects of this product, including components, milestones
- and versions.
- </para>
- <para>
- Any group having <emphasis>canconfirm</emphasis> selected
- allows users who are in this group to confirm bugs
- in this product.
- </para>
- <para>
- Any group having <emphasis>editbugs</emphasis> selected allows
- users who are in this group to edit all fields of
- bugs in this product.
- </para>
<para>
- The <emphasis>MemberControl</emphasis> and
- <emphasis>OtherControl</emphasis> fields indicate which
- bugs will be placed in this group according
- to the following definitions.
+ To edit an existing product, click the "Products" link from the
+ page footer. If the 'useclassification' parameter is
+ turned on, a table of existing classifications is displayed,
+ including an "Unclassified" category. The table indicates how many products
+ are in each classification. Click on the classification name to see its
+ products. If the 'useclassification' parameter is not in use, the table
+ lists all products directly. The product table summarizes the information
+ about the product defined
+ when the product was created. Click on the product name to edit these
+ properties, and to access links to other product attributes such as the
+ product's components, versions, milestones, and group access controls.
</para>
+
+ </section>
+
+ <section id="comps-vers-miles-products">
+ <title>Adding or Editing Components, Versions and Target Milestones</title>
+ <para>
+ To edit existing, or add new, Components, Versions or Target Milestones
+ to a Product, select the "Edit Components", "Edit Versions" or "Edit
+ Milestones" links from the "Edit Product" page. A table of existing
+ Components, Versions or Milestones is displayed. Click on a item name
+ to edit the properties of that item. Below the table is a link to add
+ a new Component, Version or Milestone.
+ </para>
+ <para>
+ For more information on components, see <xref linkend="components"/>.
+ </para>
+ <para>
+ For more information on versions, see <xref linkend="versions"/>.
+ </para>
+ <para>
+ For more information on milestones, see <xref linkend="milestones"/>.
+ </para>
+ </section>
+
+ <section id="product-group-controls">
+ <title>Assigning Group Controls to Products</title>
+
+ <para>
+ On the <quote>Edit Product</quote> page, there is a link called
+ <quote>Edit Group Access Controls</quote>. The settings on this page
+ control the relationship of the groups to the product being edited.
+ </para>
+
+ <para>
+ Group Access Controls are an important aspect of using groups for
+ isolating products and restricting access to bugs filed against those
+ products. For more information on groups, including how to create, edit
+ add users to, and alter permission of, see <xref linkend="groups"/>.
+ </para>
+
+ <para>
+ After selecting the "Edit Group Access Controls" link from the "Edit
+ Product" page, a table containing all user-defined groups for this
+ Bugzilla installation is displayed. The system groups that are created
+ when Bugzilla is installed are not applicable to Group Access Controls.
+ Below is description of what each of these fields means.
+ </para>
+
+ <para>
+ Groups may be applicable (e.g bugs in this product can be associated
+ with this group) , default (e.g. bugs in this product are in this group
+ by default), and mandatory (e.g. bugs in this product must be associated
+ with this group) for each product. Groups can also control access
+ to bugs for a given product, or be used to make bugs for a product
+ totally read-only unless the group restrictions are met. The best way to
+ understand these relationships is by example. See
+ <xref linkend="group-control-examples"/> for examples of
+ product and group relationships.
+ </para>
+
+ <note>
+ <para>
+ Products and Groups are not limited to a one-to-one relationship.
+ Multiple groups can be associated with the same product, and groups
+ can be associated with more than one product.
+ </para>
+ </note>
+
+ <para>
+ If any group has <emphasis>Entry</emphasis> selected, then the
+ product will restrict bug entry to only those users
+ who are members of <emphasis>all</emphasis> the groups with
+ <emphasis>Entry</emphasis> selected.
+ </para>
+
+ <para>
+ If any group has <emphasis>Canedit</emphasis> selected,
+ then the product will be read-only for any users
+ who are not members of <emphasis>all</emphasis> of the groups with
+ <emphasis>Canedit</emphasis> selected. <emphasis>Only</emphasis> users who
+ are members of all the <emphasis>Canedit</emphasis> groups
+ will be able to edit bugs for this product. This is an additional
+ restriction that enables finer-grained control over products rather
+ than just all-or-nothing access levels.
+ </para>
+
+ <para>
+ The following settings let you
+ choose privileges on a <emphasis>per-product basis</emphasis>.
+ This is a convenient way to give privileges to
+ some users for some products only, without having
+ to give them global privileges which would affect
+ all products.
+ </para>
+
+ <para>
+ Any group having <emphasis>editcomponents</emphasis>
+ selected allows users who are in this group to edit all
+ aspects of this product, including components, milestones
+ and versions.
+ </para>
+
+ <para>
+ Any group having <emphasis>canconfirm</emphasis> selected
+ allows users who are in this group to confirm bugs
+ in this product.
+ </para>
+
+ <para>
+ Any group having <emphasis>editbugs</emphasis> selected allows
+ users who are in this group to edit all fields of
+ bugs in this product.
+ </para>
+
+ <para>
+ The <emphasis>MemberControl</emphasis> and
+ <emphasis>OtherControl</emphasis> are used in tandem to determine which
+ bugs will be placed in this group. The only allowable combinations of
+ these two parameters are listed in a table on the "Edit Group Access Controls"
+ page. Consult this table for details on how these fields can be used.
+ Examples of different uses are described below.
+ </para>
+
+ <section id="group-control-examples">
+ <title>Common Applications of Group Controls</title>
+
<para>
- For each group, it is possible to specify if
- membership in that group is:
+ The use of groups is best explained by providing examples that illustrate
+ configurations for common use cases. The examples follow a common syntax:
+ <emphasis>Group: Entry, MemberControl, OtherControl, CanEdit,
+ EditComponents, CanConfirm, EditBugs</emphasis>. Where "Group" is the name
+ of the group being edited for this product. The other fields all
+ correspond to the table on the "Edit Group Access Controls" page. If any
+ of these options are not listed, it means they are not checked.
</para>
- <orderedlist>
- <listitem>
+
<para>
- Required for bug entry.
+ Basic Product/Group Restriction
</para>
- </listitem>
- <listitem>
+
+ <para>
+ Suppose there is a product called "Bar". The
+ "Bar" product can only have bugs entered against it by users in the
+ group "Foo". Additionally, bugs filed against product "Bar" must stay
+ restricted to users to "Foo" at all times. Furthermore, only members
+ of group "Foo" can edit bugs filed against product "Bar", even if other
+ users could see the bug. This arrangement would achieved by the
+ following:
+ </para>
+
+ <programlisting>
+Product Bar:
+foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
+ </programlisting>
+
+ <para>
+ Perhaps such strict restrictions are not needed for product "Bar". A
+ more lenient way to configure product "Bar" and group "Foo" would be:
+ </para>
+
+ <programlisting>
+Product Bar:
+foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
+ </programlisting>
+
+ <para>
+ The above indicates that for product "Bar", members of group "Foo" can
+ enter bugs. Any one with permission to edit a bug against product "Bar"
+ can put the bug
+ in group "Foo", even if they themselves are not in "Foo". Anyone in group
+ "Foo" can edit all aspects of the components of product "Bar", can confirm
+ bugs against product "Bar", and can edit all fields of any bug against
+ product "Bar".
+ </para>
+
<para>
- 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).
+ General User Access With Security Group
</para>
- </listitem>
- <listitem>
+
+ <para>
+ To permit any user to file bugs against "Product A",
+ and to permit any user to submit those bugs into a
+ group called "Security":
+ </para>
+
+ <programlisting>
+Product A:
+security: SHOWN/SHOWN
+ </programlisting>
+
<para>
- 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).
+ General User Access With A Security Product
</para>
- </listitem>
- <listitem>
+
<para>
- Required in order to make <emphasis>any</emphasis> change
- to bugs in this product <emphasis>including comments.</emphasis>
+ To permit any user to file bugs against product called "Security"
+ while keeping those bugs from becoming visible to anyone
+ outside the group "SecurityWorkers" (unless a member of the
+ "SecurityWorkers" group removes that restriction):
</para>
- </listitem>
- </orderedlist>
- <para>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...</para>
- <programlisting>
-foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
+
+ <programlisting>
+Product Security:
+securityworkers: DEFAULT/MANDATORY
+ </programlisting>
+
+ <para>
+ Product Isolation With a Common Group
+ </para>
+
+ <para>
+ To permit users of "Product A" to access the bugs for
+ "Product A", users of "Product B" to access the bugs for
+ "Product B", and support staff, who are members of the "Support
+ Group" to access both, three groups are needed:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>Support Group: Contains members of the support staff.</para>
+ </listitem>
+
+ <listitem>
+ <para>AccessA Group: Contains users of product A and the Support group.</para>
+ </listitem>
+
+ <listitem>
+ <para>AccessB Group: Contains users of product B and the Support group.</para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ Once these three groups are defined, the product group controls
+ can be set to:
+ </para>
+
+ <programlisting>
+Product A:
+AccessA: ENTRY, MANDATORY/MANDATORY
+Product B:
+AccessB: ENTRY, MANDATORY/MANDATORY
+ </programlisting>
+
+ <para>
+ Perhaps the "Support Group" wants more control. For example,
+ the "Support Group" could be permitted to make bugs inaccessible to
+ users of both groups "AccessA" and "AccessB".
+ Then, the "Support Group" could be permitted to publish
+ bugs relevant to all users in a third product (let's call it
+ "Product Common") that is read-only
+ to anyone outside the "Support Group". In this way the "Support Group"
+ could control bugs that should be seen by both groups.
+ That configuration would be:
+ </para>
+
+ <programlisting>
+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
</programlisting>
-
- </section>
+ <para>
+ Make a Product Read Only
+ </para>
+
+ <para>
+ Sometimes a product is retired and should no longer have
+ new bugs filed against it (for example, an older version of a software
+ product that is no longer supported). A product can be made read-only
+ by creating a group called "readonly" and adding products to the
+ group as needed:
+ </para>
+
+ <programlisting>
+Product A:
+ReadOnly: ENTRY, NA/NA, CANEDIT
+ </programlisting>
+ <note>
+ <para>
+ For more information on Groups outside of how they relate to products
+ see <xref linkend="groups"/>.
+ </para>
+ </note>
+
+ </section>
+
+ </section>
</section>
<section id="groups">
<title>Groups and Group Security</title>
- <para>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 <quote>Edit Group Controls.</quote>
+ <para>
+ 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.
</para>
<para>
- 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.
+ Groups and group behaviors are controlled in several places:
</para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 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 <xref linkend="param-group-security"/>.
+ </para>
+
+ </listitem>
+
+ <listitem>
+ <para>
+ 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 <xref linkend="product-group-controls"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Group access for users. See <xref linkend="users-and-groups"/> for
+ details on how users are assigned group access.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
<para>
- Note that group permissions are such that you need to be a member
- of <emphasis>all</emphasis> the groups a bug is in, for whatever
- reason, to see that bug. Similarly, you must be a member
- of <emphasis>all</emphasis> of the entry groups for a product
- to add bugs to a product and you must be a member
- of <emphasis>all</emphasis> of the canedit groups for a product
- in order to make <emphasis>any</emphasis> change to bugs in that
- product.
- </para>
- <note>
+ 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 <emphasis>all</emphasis> 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 <xref linkend="product-group-controls"/>.
+ </para>
+
+ <note>
<para>
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
section that starts with <quote>Users in the roles selected below...</quote>
and un-checking the box next to either 'Reporter' or 'CC List' (or both).
</para>
- </note>
- <section>
+ </note>
+
+ <section id="create-groups">
<title>Creating Groups</title>
- <para>To create Groups:</para>
+
+ <para>
+ To create a new group, follow the steps below:
+ </para>
<orderedlist>
+
<listitem>
- <para>Select the <quote>groups</quote>
- link in the footer.</para>
+ <para>
+ Select the <quote>Groups</quote> link in the page footer.
+ </para>
</listitem>
<listitem>
- <para>Take a moment to understand the instructions on the <quote>Edit
- Groups</quote> screen, then select the <quote>Add Group</quote> link.</para>
+ <para>
+ 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
+ <quote>Add Group</quote> link under the table of existing groups.
+ </para>
</listitem>
<listitem>
- <para>Fill out the <quote>Group</quote>, <quote>Description</quote>,
- and <quote>User RegExp</quote> fields.
- <quote>User RegExp</quote> allows you to automatically
- place all users who fulfill the Regular Expression into the new group.
- When you have finished, click <quote>Add</quote>.</para>
- <para>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.</para>
- <note>
- <para>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.</para>
- </note>
- <warning>
- <para>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.</para>
- </warning>
- </listitem>
- <listitem>
- <para>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.</para>
+ <para>
+ 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).
+ </para>
+ <note>
+ <para>
+ If <quote>User RegExp</quote> 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.
+ </para>
+ </note>
+ <warning>
+ <para>
+ 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.
+ </para>
+ </warning>
</listitem>
+
<listitem>
- <para>After you add your new group, edit the new group. On the
- edit page, you can specify other groups that should be included
+ <para>
+ 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.</para>
+ users from this group. For more details, see <xref linkend="edit-groups"/>.
+ </para>
</listitem>
</orderedlist>
</section>
- <section>
+
+ <section id="edit-groups">
+ <title>Editing Groups and Assigning Group Permissions</title>
+
+ <para>
+ To access the "Edit Groups" page, select the
+ <quote>Groups</quote> 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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
+ <xref linkend="parameters"/>) an additional column, "Visible", is displayed.
+ The way these controls allow groups to relate
+ to one another is called <emphasis>inheritance</emphasis>. Use this table
+ to configure group permissions as follows (the discussion below assumes the
+ group being edited is called "Group1").
+ </para>
+
+ <para>
+ 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,
+ <emphasis>only</emphasis> members of groups with "Visible" checked will
+ be aware of "Group1".
+ </para>
+ <para>
+ 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".
+ </para>
+ <para>
+ 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".
+ </para>
+
+ </section>
+
+ <section id="users-and-groups">
<title>Assigning Users to Groups</title>
- <para>Users can become a member of a group in several ways.</para>
+
+ <para>
+ A User can become a member of a group in several ways:
+ </para>
+
<orderedlist>
+
<listitem>
- <para>The user can be explicitly placed in the group by editing
- the user's own profile</para>
+ <para>
+ 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 <xref linkend="useradmin"/>.
+ </para>
</listitem>
+
<listitem>
- <para>The group can include another group of which the user is
- a member.</para>
+ <para>
+ 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 <xref linkend="edit-groups"/> for details on group inheritance.
+ </para>
</listitem>
+
<listitem>
- <para>The user's email address can match a regular expression
- that the group specifies to automatically grant membership to
- the group.</para>
+ <para>
+ 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 <xref linkend="create-groups"/> for details on
+ the regular expression option when creating groups.
+ </para>
</listitem>
+
</orderedlist>
+
</section>
+
<section>
<title>Assigning Group Controls to Products</title>
+
<para>
- For information on assigning group controls to
- products, see <xref linkend="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 <xref linkend="product-group-controls" />.
</para>
+
</section>
-
- <section>
- <title>Common Applications of Group Controls</title>
- <section>
- <title>General User Access With Security Group</title>
- <para>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....</para>
- <programlisting>
-Product A...
-security: SHOWN/SHOWN
-Product B...
-security: SHOWN/SHOWN
-Product C...
-security: SHOWN/SHOWN
- </programlisting>
- </section>
- <section>
- <title>General User Access With A Security Product</title>
- <para>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....</para>
- <programlisting>
-Product Security...
-securityworkers: DEFAULT/MANDATORY
- </programlisting>
- </section>
- <section>
- <title>Product Isolation With Common Group</title>
- <para>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</para>
- <orderedlist>
- <listitem>
- <para>Support: Contains members of the support staff.</para>
- </listitem>
- <listitem>
- <para>AccessA: Contains users of product A and the Support group.</para>
- </listitem>
- <listitem>
- <para>AccessB: Contains users of product B and the Support group.</para>
- </listitem>
- </orderedlist>
- <para>Once these 3 groups are defined, the products group controls
- can be set to..</para>
- <programlisting>
-Product A...
-AccessA: ENTRY, MANDATORY/MANDATORY
-Product B...
-AccessB: ENTRY, MANDATORY/MANDATORY
- </programlisting>
- <para>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...</para>
- <programlisting>
-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
- </programlisting>
- </section>
- </section>
+
</section>
<section id="sanitycheck">
projects / thirdparty / bugzilla.git / commitdiff
