Skip to content

bugzilla
bugzilla
Commit 2c18697d authored by bugreport%peshkin.net's avatar bugreport%peshkin.net
Browse files
Options

Bug 203869: Update documentation to better describe group controls

r=gerv, a=justdave
parent cbef267d
Show whitespace changes
Inline Side-by-side
Showing with 163 additions and 42 deletions
docs/xml/administration.xml
View file @ 2c18697d
...@@ -640,16 +640,104 @@ ...@@ -640,16 +640,104 @@
<para> <para>
If the makeproductgroups param is on, a new group will be automatically If the makeproductgroups param is on, a new group will be automatically
created for every new product. created for every new product. It is primarily available for backward
compatibility with older sites.
</para> </para>
<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>
<section>
<title>Creating Groups</title>
<para>To create Groups:</para>
<orderedlist>
<listitem>
<para>Select the <quote>groups</quote>
link in the 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>
</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.</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>
</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
in this group and which groups should be permitted to add and delete
users from this group.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Assigning Users to Groups</title>
<para>Users 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>
</listitem>
<listitem>
<para>The group can include another group of which the user is
a member.</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>
</listitem>
</orderedlist>
</section>
<section>
<title>Assigning Group Controls to Products</title>
<para> <para>
On the product edit page, there is a page to edit the On the product edit page, there is a page to edit the
<quote>Group Controls</quote> <quote>Group Controls</quote>
for a product and determine which groups are applicable, default, for a product. This allows you to
and mandatory for each product as well as controlling entry configure how a group relates to the product.
for each product and being able to set bugs in a product to be Groups may be applicable, default,
totally read-only unless some group restrictions are met. 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.
</para> </para>
<para> <para>
...@@ -691,52 +779,85 @@ ...@@ -691,52 +779,85 @@
</para> </para>
</listitem> </listitem>
</orderedlist> </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 resticted
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>
<para>To create Groups:</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> <orderedlist>
<listitem> <listitem>
<para>Select the <quote>groups</quote> <para>Support: Contains members of the support staff.</para>
link in the footer.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Take a moment to understand the instructions on the <quote>Edit <para>AccessA: Contains users of product A and the Support group.</para>
Groups</quote> screen, then select the <quote>Add Group</quote> link.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Fill out the <quote>Group</quote>, <quote>Description</quote>, <para>AccessB: Contains users of product B and the Support group.</para>
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>
<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>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.</para>
</listitem> </listitem>
</orderedlist> </orderedlist>
<para>Once these 3 groups are defined, the products group controls
<para> can be set to..</para>
Note that group permissions are such that you need to be a member <programlisting>
of <emphasis>all</emphasis> the groups a bug is in, for whatever Product A...
reason, to see that bug. Similarly, you must be a member AccessA: ENTRY, MANDATORY/MANDATORY
of <emphasis>all</emphasis> of the entry groups for a product Product B...
to add bugs to a product and you must be a member AccessB: ENTRY, MANDATORY/MANDATORY
of <emphasis>all</emphasis> of the canedit groups for a product </programlisting>
in order to make <emphasis>any</emphasis> change to bugs in that <para>Optionally, the support group could be permitted to make
product. bugs inaccessible to the users and could be permitted to publish
</para> 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>
<section id="upgrading"> <section id="upgrading">
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment