<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>3.4. Products</title><link rel="stylesheet" type="text/css" href="../../style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><meta name="keywords" content="Bugzilla, Guide, installation, FAQ, administration, integration, MySQL, Mozilla, webtools"><link rel="home" href="index.html" title="The Bugzilla Guide - 4.4.12 Release"><link rel="up" href="administration.html" title="Chapter 3. Administering Bugzilla"><link rel="prev" href="classifications.html" title="3.3. Classifications"><link rel="next" href="components.html" title="3.5. Components"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">3.4. Products</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="classifications.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Administering Bugzilla</th><td width="20%" align="right"> <a accesskey="n" href="components.html">Next</a></td></tr></table><hr></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="products"></a>3.4. Products</h2></div></div></div><p>
<a class="glossterm" href="glossary.html#gloss-product"><em class="glossterm">
Products</em></a> typically represent real-world
shipping products. Products can be given
<a class="xref" href="classifications.html" title="3.3. Classifications">Classifications</a>.
For example, if a company makes computer games,
they could have a classification of "Games", and a separate
product for each game. This company might also have a
<span class="quote">“<span class="quote">Common</span>”</span> product for units of technology used
in multiple games, and perhaps a few special products that
represent items that are not actually shipping products
(for example, "Website", or "Administration").
</p><p>
Many of Bugzilla's settings are configurable on a per-product
basis. The number of <span class="quote">“<span class="quote">votes</span>”</span> available to
users is set per-product, as is the number of votes
required to move a bug automatically from the UNCONFIRMED
status to the CONFIRMED status.
</p><p>
When creating or editing products the following options are
available:
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">
Product
</span></dt><dd><p>
The name of the product
</p></dd><dt><span class="term">
Description
</span></dt><dd><p>
A brief description of the product
</p></dd><dt><span class="term">
Default milestone
</span></dt><dd><p>
Select the default milestone for this product.
</p></dd><dt><span class="term">
Closed for bug entry
</span></dt><dd><p>
Select this box to prevent new bugs from being
entered against this product.
</p></dd><dt><span class="term">
Maximum votes per person
</span></dt><dd><p>
Maximum votes a user is allowed to give for this
product
</p></dd><dt><span class="term">
Maximum votes a person can put on a single bug
</span></dt><dd><p>
Maximum votes a user is allowed to give for this
product in a single bug
</p></dd><dt><span class="term">
Confirmation threshold
</span></dt><dd><p>
Number of votes needed to automatically remove any
bug against this product from the UNCONFIRMED state
</p></dd><dt><span class="term">
Version
</span></dt><dd><p>
Specify which version of the product bugs will be
entered against.
</p></dd><dt><span class="term">
Create chart datasets for this product
</span></dt><dd><p>
Select to make chart datasets available for this product.
</p></dd></dl></div><p>
When editing a product there is also a link to edit Group Access Controls,
see <a class="xref" href="products.html#product-group-controls" title="3.4.4. Assigning Group Controls to Products">Section 3.4.4, “Assigning Group Controls to Products”</a>.
</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="create-product"></a>3.4.1. Creating New Products</h3></div></div></div><p>
To create a new product:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
Select <span class="quote">“<span class="quote">Administration</span>”</span> from the footer and then
choose <span class="quote">“<span class="quote">Products</span>”</span> from the main administration page.
</p></li><li class="listitem"><p>
Select the <span class="quote">“<span class="quote">Add</span>”</span> link in the bottom right.
</p></li><li class="listitem"><p>
Enter the name of the product and a description. The
Description field may contain HTML.
</p></li><li class="listitem"><p>
When the product is created, Bugzilla will give a message
stating that a component must be created before any bugs can
be entered against the new product. Follow the link to create
a new component. See <a class="xref" href="components.html" title="3.5. Components">Components</a> for more
information.
</p></li></ol></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="edit-products"></a>3.4.2. Editing Products</h3></div></div></div><p>
To edit an existing product, click the "Products" link from the
"Administration" page. 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.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="comps-vers-miles-products"></a>3.4.3. Adding or Editing Components, Versions and Target Milestones</h3></div></div></div><p>
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.
</p><p>
For more information on components, see <a class="xref" href="components.html" title="3.5. Components">Components</a>.
</p><p>
For more information on versions, see <a class="xref" href="versions.html" title="3.6. Versions">Section 3.6, “Versions”</a>.
</p><p>
For more information on milestones, see <a class="xref" href="milestones.html" title="3.7. Milestones">Section 3.7, “Milestones”</a>.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="product-group-controls"></a>3.4.4. Assigning Group Controls to Products</h3></div></div></div><p>
On the <span class="quote">“<span class="quote">Edit Product</span>”</span> page, there is a link called
<span class="quote">“<span class="quote">Edit Group Access Controls</span>”</span>. The settings on this page
control the relationship of the groups to the product being edited.
</p><p>
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 <a class="xref" href="groups.html" title="3.15. Groups and Group Security">Section 3.15, “Groups and Group Security”</a>.
</p><p>
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.
</p><p>
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
<a class="xref" href="products.html#group-control-examples" title="3.4.4.1. Common Applications of Group Controls">Section 3.4.4.1, “Common Applications of Group Controls”</a> for examples of
product and group relationships.
</p><div class="note" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><td align="left" valign="top"><p>
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.
</p></td></tr></table></div><p>
If any group has <span class="emphasis"><em>Entry</em></span> selected, then the
product will restrict bug entry to only those users
who are members of <span class="emphasis"><em>all</em></span> the groups with
<span class="emphasis"><em>Entry</em></span> selected.
</p><p>
If any group has <span class="emphasis"><em>Canedit</em></span> selected,
then the product will be read-only for any users
who are not members of <span class="emphasis"><em>all</em></span> of the groups with
<span class="emphasis"><em>Canedit</em></span> selected. <span class="emphasis"><em>Only</em></span> users who
are members of all the <span class="emphasis"><em>Canedit</em></span> 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.
</p><p>
The following settings let you
choose privileges on a <span class="emphasis"><em>per-product basis</em></span>.
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.
</p><p>
Any group having <span class="emphasis"><em>editcomponents</em></span>
selected allows users who are in this group to edit all
aspects of this product, including components, milestones
and versions.
</p><p>
Any group having <span class="emphasis"><em>canconfirm</em></span> selected
allows users who are in this group to confirm bugs
in this product.
</p><p>
Any group having <span class="emphasis"><em>editbugs</em></span> selected allows
users who are in this group to edit all fields of
bugs in this product.
</p><p>
The <span class="emphasis"><em>MemberControl</em></span> and
<span class="emphasis"><em>OtherControl</em></span> 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.
</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="group-control-examples"></a>3.4.4.1. Common Applications of Group Controls</h4></div></div></div><p>
The use of groups is best explained by providing examples that illustrate
configurations for common use cases. The examples follow a common syntax:
<span class="emphasis"><em>Group: Entry, MemberControl, OtherControl, CanEdit,
EditComponents, CanConfirm, EditBugs</em></span>. 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.
</p><p>
Basic Product/Group Restriction
</p><p>
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:
</p><pre class="programlisting">
Product Bar:
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
</pre><p>
Perhaps such strict restrictions are not needed for product "Bar". A
more lenient way to configure product "Bar" and group "Foo" would be:
</p><pre class="programlisting">
Product Bar:
foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
</pre><p>
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".
</p><p>
General User Access With Security Group
</p><p>
To permit any user to file bugs against "Product A",
and to permit any user to submit those bugs into a
group called "Security":
</p><pre class="programlisting">
Product A:
security: SHOWN/SHOWN
</pre><p>
General User Access With A Security Product
</p><p>
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):
</p><pre class="programlisting">
Product Security:
securityworkers: DEFAULT/MANDATORY
</pre><p>
Product Isolation With a Common Group
</p><p>
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:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Support Group: Contains members of the support staff.</p></li><li class="listitem"><p>AccessA Group: Contains users of product A and the Support group.</p></li><li class="listitem"><p>AccessB Group: Contains users of product B and the Support group.</p></li></ol></div><p>
Once these three groups are defined, the product group controls
can be set to:
</p><pre class="programlisting">
Product A:
AccessA: ENTRY, MANDATORY/MANDATORY
Product B:
AccessB: ENTRY, MANDATORY/MANDATORY
</pre><p>
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:
</p><pre class="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
</pre><p>
Make a Product Read Only
</p><p>
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:
</p><pre class="programlisting">
Product A:
ReadOnly: ENTRY, NA/NA, CANEDIT
</pre><div class="note" style="margin-left: 1em; margin-right: 1em"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.gif"></td><th align="left"></th></tr><tr><td align="left" valign="top"><p>
For more information on Groups outside of how they relate to products
see <a class="xref" href="groups.html" title="3.15. Groups and Group Security">Section 3.15, “Groups and Group Security”</a>.
</p></td></tr></table></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="classifications.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="administration.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="components.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">3.3. Classifications </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 3.5. Components</td></tr></table></div></body></html>
