Bug 281809: 'Groups' docs need improving - Patch by Sam Folk-Williams <sam.folkwilliams@gmail.com> r=LpSolit

1 files changed, 530 insertions, 239 deletions

diff --git a/docs/xml/administration.xml b/docs/xml/administration.xml
index 464f80749..c24ca40f3 100644
--- a/docs/xml/administration.xml
+++ b/docs/xml/administration.xml
@@ -532,6 +532,22 @@
 
           <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
             </term>
             <listitem>
@@ -1349,9 +1365,13 @@
     </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>
@@ -1359,7 +1379,7 @@
     <orderedlist>
       <listitem>
         <para> 
-        Select <quote>products</quote> from the footer.
+        Select <quote>Products</quote> from the page footer.
         </para>
       </listitem>
 
@@ -1387,121 +1407,319 @@
       </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>
 
@@ -2356,28 +2574,70 @@ foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
   <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 
@@ -2386,158 +2646,189 @@ foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
         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">