397168f490
I added related information to the Bugzilla Guide, and tacked in a couple of last-minute additions. Also fixed the annoying "Tip: HINT:" thing. git-svn-id: svn://10.0.0.236/trunk@93103 18797224-902f-48f8-a5cc-f745e15eee43
923 lines
22 KiB
HTML
923 lines
22 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Product, Component, Milestone, and Version Administration</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="The Bugzilla Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Administering Bugzilla"
|
|
HREF="administration.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="User Administration"
|
|
HREF="useradmin.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Bugzilla Security"
|
|
HREF="security.html"></HEAD
|
|
><BODY
|
|
CLASS="SECTION"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Bugzilla Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="useradmin.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 3. Administering Bugzilla</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="security.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H1
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="PROGRAMADMIN"
|
|
>3.3. Product, Component, Milestone, and Version Administration</A
|
|
></H1
|
|
><TABLE
|
|
BORDER="0"
|
|
WIDTH="100%"
|
|
CELLSPACING="0"
|
|
CELLPADDING="0"
|
|
CLASS="EPIGRAPH"
|
|
><TR
|
|
><TD
|
|
WIDTH="45%"
|
|
> </TD
|
|
><TD
|
|
WIDTH="45%"
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><I
|
|
><P
|
|
><I
|
|
>Dear Lord, we have to get our users to do WHAT?</I
|
|
></P
|
|
></I
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="PRODUCTS"
|
|
>3.3.1. Products</A
|
|
></H2
|
|
><FONT
|
|
COLOR="RED"
|
|
>Formerly, and in some spots still, called "Programs"</FONT
|
|
><P
|
|
> <A
|
|
HREF="glossary.html#GLOSS_PRODUCT"
|
|
><I
|
|
CLASS="GLOSSTERM"
|
|
>Products</I
|
|
></A
|
|
> are the
|
|
broadest category in Bugzilla, and you should have the least of these.
|
|
If your company makes computer games, you should have one product per game,
|
|
and possibly a few special products
|
|
(website, meetings...)
|
|
</P
|
|
><P
|
|
> A Product (formerly called "Program", and still referred to that way
|
|
in some portions of the source code) controls some very important functions.
|
|
The number of "votes" available for users to vote for the most important bugs
|
|
is set per-product, as is the number of votes required to move a bug automatically
|
|
from the UNCONFIRMED status to the NEW status. One can close a Product for further
|
|
bug entry and define various Versions available from the Edit Product screen.
|
|
</P
|
|
><P
|
|
>To create a new product:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Select "components" from the yellow footer
|
|
</P
|
|
><DIV
|
|
CLASS="TIP"
|
|
><BLOCKQUOTE
|
|
CLASS="TIP"
|
|
><P
|
|
><B
|
|
>Tip: </B
|
|
> It may seem counterintuitive to click "components" when you want
|
|
to edit the properties associated with Products. This is one of a long
|
|
list of things we want in Bugzilla 3.0...
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Select the "Add" link to the right of "Add a new product".
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Enter the name of the product and a description.
|
|
The Description field is free-form.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><DIV
|
|
CLASS="TIP"
|
|
><BLOCKQUOTE
|
|
CLASS="TIP"
|
|
><P
|
|
><B
|
|
>Tip: </B
|
|
> Don't worry about the "Closed for bug entry", "Maximum Votes per person",
|
|
"Maximum votes a person can put on a single bug", "Number of votes a bug in
|
|
this Product needs to automatically get out of the UNCOMFIRMED state",
|
|
and "Version" options yet.
|
|
We'll cover those in a few moments.
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="COMPONENTS"
|
|
>3.3.2. Components</A
|
|
></H2
|
|
><P
|
|
> Components are subsections of a Product.
|
|
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN850"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-1. Creating some Components</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN852"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> The computer game you are designing may a "UI" component, an "API" component,
|
|
a "Sound System" component, and a "Plugins" component, each overseen by a different
|
|
programmer. It often makes sense to divide Components in Bugzilla according to the
|
|
natural divisions of responsibility within your Product or company.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
>
|
|
|
|
Each component has a owner and (if you turned it on in the parameters), a qa
|
|
contact. The owner should be the primary person who fixes bugs in that component. The QA
|
|
Contact should be the person who will ensure these bugs are completely fixed. The Owner,
|
|
QA Contact, and Reporter will get email when new bugs are created in this Component and
|
|
when these bugs change. Default Owner and Default QA Contact fields only dictate the
|
|
<EM
|
|
>default assignments</EM
|
|
>; the Owner and Q/A Contact fields in a bug
|
|
are otherwise unrelated to the Component.
|
|
</P
|
|
><P
|
|
> To create a new Component:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Select the "Edit components" link from the "Edit Product" page
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Select the "Add" link to the right of the "Add a new component" text
|
|
on the "Select Component" page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Fill out the "Component" field, a short "Description", and the "Initial Owner".
|
|
The "Component" field should not contain a space. The "Description" field is
|
|
free-form. The "Initial Owner" field must be that of a valid user already
|
|
existing in the database. If the initial owner does not exist, Bugzilla
|
|
will refuse to create the component.
|
|
<DIV
|
|
CLASS="TIP"
|
|
><BLOCKQUOTE
|
|
CLASS="TIP"
|
|
><P
|
|
><B
|
|
>Tip: </B
|
|
> Is your "Default Owner" a user who is not yet in the database?
|
|
No problem.
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="a"
|
|
><LI
|
|
><P
|
|
> Select the "Log out" link on the footer of the page.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Select the "New Account" link on the footer of the "Relogin" page
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Type in the email address of the default owner you want to create
|
|
in the "E-mail address" field, and her full name in the "Real name"
|
|
field, then select the "Submit Query" button.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Now select "Log in" again, type in your login information, and you
|
|
can modify the product to use the Default Owner information
|
|
you require.
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Either "edit" more components or return to the "query" page on the ensuing
|
|
"Addming new component" page. To return to the Product you were editing, you
|
|
must select the "components" link as before.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="VERSIONS"
|
|
>3.3.3. Versions</A
|
|
></H2
|
|
><P
|
|
> Versions are the revisions of the product, such as "Flinders 3.1", "Flinders 95",
|
|
and "Flinders 2000". Using Versions helps you isolate code changes and are an aid
|
|
in reporting.
|
|
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN879"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-2. Common Use of Versions</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN881"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> A user reports a bug
|
|
against Version "Beta 2.0" of your product. The current Version of your software
|
|
is "Release Candidate 1", and no longer has the bug. This will
|
|
help you triage and classify bugs according to their relevance. It is also
|
|
possible people may report bugs against bleeding-edge beta versions that are
|
|
not evident in older versions of the software. This can help isolate code
|
|
changes that caused the bug
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
>
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN883"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-3. A Different Use of Versions</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN885"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> This field has been used to good effect by an online service provider in a slightly
|
|
different way. They had three versions of the product: "Production", "QA",
|
|
and "Dev". Although it may be the same product, a bug in the development
|
|
environment is not normally as critical as a Production bug, nor does it
|
|
need to be reported publicly. When used in conjunction with Target Milestones,
|
|
one can easily specify the environment where a bug can be reproduced, and
|
|
the Milestone by which it will be fixed.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
>
|
|
</P
|
|
><P
|
|
> To create and edit Versions:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> From the "Edit Product" screen, select "Edit Versions"
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You will notice that the product already has the default version "undefined".
|
|
If your product doesn't use version numbers, you may want to leave this as it is
|
|
or edit it so that it is "---". You can then go back to the edit versions page
|
|
and add new versions to your product.
|
|
</P
|
|
><P
|
|
> Otherwise, click the "Add" button to the right of the "Add a new version" text.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Enter the name of the Version. This can be free-form characters up to the limit of the
|
|
text box. Then select the "Add" button.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> At this point you can select "Edit" to edit more Versions, or return to the "Query"
|
|
page, from which you can navigate back to the product through the "components" link
|
|
at the foot of the Query page.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="MILESTONES"
|
|
>3.3.4. Milestones</A
|
|
></H2
|
|
><P
|
|
> Milestones are "targets" that you plan to get a bug fixed by. For example, you have a bug that
|
|
you plan to fix for your 3.0 release, it would be assigned the milestone of 3.0. Or, you have a
|
|
bug that you plan to fix for 2.8, this would have a milestone of 2.8.
|
|
</P
|
|
><DIV
|
|
CLASS="NOTE"
|
|
><BLOCKQUOTE
|
|
CLASS="NOTE"
|
|
><P
|
|
><B
|
|
>Note: </B
|
|
> Milestone options will only appear for a Product if you turned the "usetargetmilestone" field
|
|
in the "Edit Parameters" screen "On".
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
><P
|
|
> To create new Milestones, set Default Milestones, and set Milestone URL:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Select "edit milestones"
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Select "Add" to the right of the "Add a new milestone" text
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Enter the name of the Milestone in the "Milestone" field.
|
|
You can optionally set the "Sortkey", which is a positive or negative number (-255 to 255)
|
|
that defines where in the list this particular milestone appears.
|
|
Select "Add".
|
|
</P
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN911"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-4. Using SortKey with Target Milestone</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN913"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> Let's say you create a target milestone called "Release 1.0", with Sortkey set to "0".
|
|
Later, you realize that you will have a public beta, called "Beta1".
|
|
You can create a Milestone called "Beta1", with a Sortkey of "-1" in order to ensure
|
|
people will see the Target Milestone of "Beta1" earlier on the list than "Release 1.0"
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If you want to add more milestones, select the "Edit" link.
|
|
If you don't, well shoot, you have to go back to the "query" page and select "components"
|
|
again, and make your way back to the Product you were editing.
|
|
<DIV
|
|
CLASS="NOTE"
|
|
><BLOCKQUOTE
|
|
CLASS="NOTE"
|
|
><P
|
|
><B
|
|
>Note: </B
|
|
> This is another in the list of unusual user interface decisions that
|
|
we'd like to get cleaned up. Shouldn't there be a link to the effect of
|
|
"edit the Product I was editing when I ended up here"? In any case,
|
|
clicking "components" in the footer takes you back to the "Select product"
|
|
screen, from which you can begin editing your product again.
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> From the Edit Product screen again (once you've made your way back), enter the URL
|
|
for a description of what your milestones are for this product in the "Milestone URL" field.
|
|
It should be of the format "http://www.foo.com/bugzilla/product_milestones.html"
|
|
</P
|
|
><P
|
|
> Some common uses of this field include product descriptions, product roadmaps,
|
|
and of course a simple description of the meaning of each milestone.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> If you're using Target Milestones, the "Default Milestone" field must have some
|
|
kind of entry. If you really don't care if people set coherent Target Milestones,
|
|
simply leave this at the default, "---". However, controlling and regularly updating the Default
|
|
Milestone field is a powerful tool when reporting the status of projects.
|
|
</P
|
|
><P
|
|
>Select the "Update" button when you are done.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="VOTING"
|
|
>3.3.5. Voting</A
|
|
></H2
|
|
><P
|
|
> The concept of "voting" is a poorly understood, yet powerful feature for the management
|
|
of open-source projects. Each user is assigned so many Votes per product, which they can
|
|
freely reassign (or assign multiple votes to a single bug).
|
|
This allows developers to gauge user need for a particular enhancement
|
|
or bugfix. By allowing bugs with a certain number of votes to automatically move from
|
|
"UNCONFIRMED" to "NEW", users of the bug system can help high-priority bugs garner
|
|
attention so they don't sit for a long time awaiting triage.
|
|
</P
|
|
><P
|
|
> The daunting challenge of Votes is deciding where you draw the line for a "vocal majority". If you
|
|
only have a user base of 100 users, setting a low threshold for bugs to move from UNCONFIRMED
|
|
to NEW makes sense. As the Bugzilla user base expands, however, these thresholds must be
|
|
re-evaluated. You should gauge whether this feature is worth the time and close monitoring involved,
|
|
and perhaps forego implementation until you have a critical mass of users who demand it.
|
|
</P
|
|
><P
|
|
>To modify Voting settings:</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Navigate to the "Edit Product" screen for the Product you wish to modify
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Set "Maximum Votes per person" to your calculated value. Setting this field
|
|
to "0" disables voting.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Set "Maximum Votes a person can put on a single bug" to your calculated value. It
|
|
should probably be some number lower than the "Maximum votes per person".
|
|
Setting this field to "0" disables voting, but leaves the voting options open
|
|
to the user. This is confusing.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Set "Number of votes a bug in this product needs to automatically get out of the
|
|
UNCONFIRMED state" to your calculated number. Setting this field to "0"
|
|
disables the automatic move of bugs from UNCONFIRMED to NEW. Some people
|
|
advocate leaving this at "0", but of what use are Votes if your Bugzilla
|
|
user base is unable to affect which bugs appear on Development radar?
|
|
<DIV
|
|
CLASS="TIP"
|
|
><BLOCKQUOTE
|
|
CLASS="TIP"
|
|
><P
|
|
><B
|
|
>Tip: </B
|
|
> You should probably set this number to higher than a small coalition of
|
|
Bugzilla users can influence it. Most sites use this as a "referendum"
|
|
mechanism -- if users are able to vote a bug out of UNCONFIRMED, it
|
|
is a <EM
|
|
>really</EM
|
|
> bad bug!
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Once you have adjusted the values to your preference, select the "Update" button.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="GROUPS"
|
|
>3.3.6. Groups and Group Security</A
|
|
></H2
|
|
><P
|
|
> Groups can be very useful in bugzilla, because they allow users to isolate
|
|
bugs or products that should only be seen by certain people. Groups can also
|
|
be a complicated minefield of interdependencies and weirdness if mismanaged.
|
|
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN949"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-5. When to Use Group Security</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN951"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> Many Bugzilla sites isolate "Security-related" bugs from all other bugs.
|
|
This way, they can have a fix ready before the security vulnerability
|
|
is announced to the world. You can create a "Security" product which, by
|
|
default, has no members, and only add members to the group (in their individual
|
|
User page, as described under User Administration) who should have
|
|
priveleged access to "Security" bugs. Alternately, you may create a Group
|
|
independently of any Product, and change the Group mask on individual bugs
|
|
to restrict access to members only of certain Groups.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
>
|
|
|
|
Groups only work if you enable the "usebuggroups" paramater.
|
|
In addition, if the "usebuggroupsentry" parameter is "On", one can restrict access
|
|
to products by groups, so that only members of a product group are able to view
|
|
bugs within that product.
|
|
Group security in Bugzilla can be divided into two categories:
|
|
Generic and Product-Based.
|
|
</P
|
|
><DIV
|
|
CLASS="NOTE"
|
|
><BLOCKQUOTE
|
|
CLASS="NOTE"
|
|
><P
|
|
><B
|
|
>Note: </B
|
|
> Groups in Bugzilla are a complicated beast that evolved out of very simple user
|
|
permission bitmasks, apparently itself derived from common concepts in UNIX access
|
|
controls. A "bitmask" is a fixed-length number whose value can describe one, and
|
|
only one, set of states. For instance, UNIX file permissions are assigned bitmask
|
|
values: "execute" has a value of 1, "write" has a value of 2,
|
|
and "read" has a value of 4. Add them together,
|
|
and a file can be read, written to, and executed if it has a bitmask of "7". (This
|
|
is a simplified example -- anybody who knows UNIX security knows there is much
|
|
more to it than this. Please bear with me for the purpose of this note.) The only
|
|
way a bitmask scheme can work is by doubling the bit count for each value. Thus
|
|
if UNIX wanted to offer another file permission, the next would have to be a value of
|
|
8, then the next 16, the next 32, etc.
|
|
</P
|
|
><P
|
|
> Similarly, Bugzilla offers a bitmask to define group permissions, with an internal
|
|
limit of 64. Several are already occupied
|
|
by built-in permissions. The way around this limitation is
|
|
to avoid assigning groups to products if you have many products, avoid bloating
|
|
of group lists, and religiously prune irrelevant groups. In reality, most installations
|
|
of Bugzilla support far fewer than 64 groups, so this limitation has not hit
|
|
for most sites, but it is on the table to be revised for Bugzilla 3.0
|
|
because it interferes with the security schemes of some administrators.
|
|
</P
|
|
></BLOCKQUOTE
|
|
></DIV
|
|
><P
|
|
> To enable Generic Group Security ("usebuggroups"):
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Turn "On" "usebuggroups" in the "Edit Parameters" screen.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You will generally have no groups set up. Select the "groups" link
|
|
in the footer.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Take a moment to understand the instructions on the "Edit Groups" screen.
|
|
Once you feel confident you understand what is expected of you, select the
|
|
"Add Group" link.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Fill out the "New Name" (remember, no spaces!), "New Description", and "New
|
|
User RegExp" fields. "New User RegExp" allows you to automatically place
|
|
all users who fulfill the Regular Expression into the new group.
|
|
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN966"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 3-6. Creating a New Group</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN968"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> I created a group called "DefaultGroup" with a description of "This is simply
|
|
a group to play with", and a "New User RegExp" of "*@velio.com". This
|
|
new group automatically includes all Bugzilla users with "@velio.com" at the
|
|
end of their user id. When I finished, my new group was assigned bit #128.
|
|
</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
>
|
|
|
|
When you have finished, select the "Add" button.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> To enable Product-Based Group Security ("usebuggroupsentry"):
|
|
</P
|
|
><DIV
|
|
CLASS="WARNING"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="WARNING"
|
|
BORDER="1"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="CENTER"
|
|
><B
|
|
>Warning</B
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
><P
|
|
> Don't forget that you only have 64 groups masks available, total, for
|
|
your installation of Bugzilla! If you plan on having more than 50
|
|
products in your individual Bugzilla installation, and require group
|
|
security for your products, you should
|
|
consider either running multiple Bugzillas or using Generic Group Security
|
|
instead of Product-Based ("usebuggroupsentry") Group Security.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Turn "On" "usebuggroups" and "usebuggroupsentry" in the "Edit Parameters" screen.
|
|
</P
|
|
><DIV
|
|
CLASS="WARNING"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="WARNING"
|
|
BORDER="1"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
ALIGN="CENTER"
|
|
><B
|
|
>Warning</B
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
><P
|
|
> "usebuggroupsentry" has the capacity to prevent the administrative user
|
|
from directly altering bugs because of conflicting group permissions.
|
|
If you plan on using "usebuggroupsentry", you should plan on restricting administrative
|
|
account usage to administrative duties only.
|
|
In other words, manage bugs with an unpriveleged user account, and
|
|
manage users, groups, Products, etc. with the administrative account.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You will generally have no Groups set up, unless you enabled "usebuggroupsentry"
|
|
prior to creating any Products. To create "Generic Group Security" groups,
|
|
follow the instructions given above. To create Product-Based Group security,
|
|
simply follow the instructions for creating a new Product. If you need to
|
|
add users to these new groups as you create them, you will find the option
|
|
to add them to the group available under the "Edit User" screens.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="useradmin.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="security.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>User Administration</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="administration.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Bugzilla Security</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |