7573dc0eaf
./images so we don't have multiple copies of the same image, fixed these doc bugs (in no particular order): 94949 97070 97071 97114 96498 95970 96677 94953 96501 96679 97068 97191 97192 git-svn-id: svn://10.0.0.236/trunk@101950 18797224-902f-48f8-a5cc-f745e15eee43
1213 lines
28 KiB
HTML
1213 lines
28 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Product, Component, Milestone, and Version
|
|
Administration</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.61
|
|
"><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 4. 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"
|
|
>4.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"
|
|
>4.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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="TIP"
|
|
WIDTH="90%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="TIP"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="COMPONENTS"
|
|
>4.3.2. Components</A
|
|
></H2
|
|
><P
|
|
> Components are subsections of a Product.
|
|
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN1461"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-1. Creating some Components</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1463"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> The computer game you are designing may have 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 QA 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 and Description fields
|
|
are free-form; the "Initial Owner" field must be that of a
|
|
user ID already existing in the database. If the initial
|
|
owner does not exist, Bugzilla will refuse to create the
|
|
component.
|
|
<DIV
|
|
CLASS="TIP"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="TIP"
|
|
WIDTH="90%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Either Edit more components or return to the Bugzilla
|
|
Query 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"
|
|
>4.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="AEN1490"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-2. Common Use of Versions</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1492"
|
|
></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="AEN1494"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-3. A Different Use of Versions</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1496"
|
|
></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"
|
|
>4.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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Milestone options will only appear for a Product if you
|
|
turned the "usetargetmilestone" field in the "Edit
|
|
Parameters" screen "On".
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></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="AEN1522"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-4. Using SortKey with Target Milestone</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1524"
|
|
></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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="90%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></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
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H2
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="VOTING"
|
|
>4.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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="TIP"
|
|
WIDTH="90%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/tip.gif"
|
|
HSPACE="5"
|
|
ALT="Tip"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></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"
|
|
>4.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="AEN1558"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-5. When to Use Group Security</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1560"
|
|
></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"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> 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
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></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="AEN1575"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-6. Creating a New Group</B
|
|
></P
|
|
><DIV
|
|
CLASS="INFORMALEXAMPLE"
|
|
><A
|
|
NAME="AEN1577"
|
|
></A
|
|
><P
|
|
></P
|
|
><P
|
|
> I created a group called DefaultGroup with a
|
|
description of <SPAN
|
|
CLASS="QUOTE"
|
|
>"This is simply a group to play
|
|
with"</SPAN
|
|
>, and a New User RegExp of <SPAN
|
|
CLASS="QUOTE"
|
|
>".*@mydomain.tld"</SPAN
|
|
>.
|
|
This new group automatically includes all Bugzilla
|
|
users with "@mydomain.tld" 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"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><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"
|
|
WIDTH="90%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><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
|
|
><P
|
|
> You may find this example illustrative for how bug groups work.
|
|
<DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="AEN1592"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 4-7. Bugzilla Groups</B
|
|
></P
|
|
><P
|
|
CLASS="LITERALLAYOUT"
|
|
>Bugzilla Groups example<br>
|
|
-----------------------<br>
|
|
<br>
|
|
For this example, let us suppose we have four groups, call them<br>
|
|
Group1, Group2, Group3, and Group4.<br>
|
|
<br>
|
|
We have 5 users, User1, User2, User3, User4, User5.<br>
|
|
<br>
|
|
We have 8 bugs, Bug1, ..., Bug8.<br>
|
|
<br>
|
|
Group membership is defined by this chart:<br>
|
|
(X denotes that user is in that group.)<br>
|
|
(I apologize for the nasty formatting of this table. Try viewing<br>
|
|
it in a text-based browser or something for now. -MPB)<br>
|
|
<br>
|
|
G G G G<br>
|
|
r r r r<br>
|
|
o o o o<br>
|
|
u u u u<br>
|
|
p p p p<br>
|
|
1 2 3 4<br>
|
|
+-+-+-+-+<br>
|
|
User1|X| | | |<br>
|
|
+-+-+-+-+<br>
|
|
User2| |X| | |<br>
|
|
+-+-+-+-+<br>
|
|
User3|X| |X| |<br>
|
|
+-+-+-+-+<br>
|
|
User4|X|X|X| |<br>
|
|
+-+-+-+-+<br>
|
|
User5| | | | |<br>
|
|
+-+-+-+-+<br>
|
|
<br>
|
|
Bug restrictions are defined by this chart:<br>
|
|
(X denotes that bug is restricted to that group.)<br>
|
|
<br>
|
|
G G G G<br>
|
|
r r r r<br>
|
|
o o o o<br>
|
|
u u u u<br>
|
|
p p p p<br>
|
|
1 2 3 4<br>
|
|
+-+-+-+-+<br>
|
|
Bug1| | | | |<br>
|
|
+-+-+-+-+<br>
|
|
Bug2| |X| | |<br>
|
|
+-+-+-+-+<br>
|
|
Bug3| | |X| |<br>
|
|
+-+-+-+-+<br>
|
|
Bug4| | | |X|<br>
|
|
+-+-+-+-+<br>
|
|
Bug5|X|X| | |<br>
|
|
+-+-+-+-+<br>
|
|
Bug6|X| |X| |<br>
|
|
+-+-+-+-+<br>
|
|
Bug7|X|X|X| |<br>
|
|
+-+-+-+-+<br>
|
|
Bug8|X|X|X|X|<br>
|
|
+-+-+-+-+<br>
|
|
<br>
|
|
Who can see each bug?<br>
|
|
<br>
|
|
Bug1 has no group restrictions. Therefore, Bug1 can be seen by any<br>
|
|
user, whatever their group membership. This is going to be the only<br>
|
|
bug that User5 can see, because User5 isn't in any groups.<br>
|
|
<br>
|
|
Bug2 can be seen by anyone in Group2, that is User2 and User4.<br>
|
|
<br>
|
|
Bug3 can be seen by anyone in Group3, that is User3 and User4.<br>
|
|
<br>
|
|
Bug4 can be seen by anyone in Group4. Nobody is in Group4, so none of<br>
|
|
these users can see Bug4.<br>
|
|
<br>
|
|
Bug5 can be seen by anyone who is in _both_ Group1 and Group2. This<br>
|
|
is only User4. User1 cannot see it because he is not in Group2, and<br>
|
|
User2 cannot see it because she is not in Group1.<br>
|
|
<br>
|
|
Bug6 can be seen by anyone who is in both Group1 and Group3. This<br>
|
|
would include User3 and User4. Similar to Bug5, User1 cannot see Bug6<br>
|
|
because he is not in Group3.<br>
|
|
<br>
|
|
Bug7 can be seen by anyone who is in Group1, Group2, and Group3. This<br>
|
|
is only User4. All of the others are missing at least one of those<br>
|
|
group priveleges, and thus cannot see the bug.<br>
|
|
<br>
|
|
Bug8 can be seen by anyone who is in Group1, Group2, Group3, and<br>
|
|
Group4. There is nobody in all four of these groups, so nobody can<br>
|
|
see Bug8. It doesn't matter that User4 is in Group1, Group2, and<br>
|
|
Group3, since he isn't in Group4.<br>
|
|
</P
|
|
></DIV
|
|
>
|
|
</P
|
|
></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
|
|
> |