diff options
Diffstat (limited to 'docs/html/programadmin.html')
| -rw-r--r-- | docs/html/programadmin.html | 1003 |
1 files changed, 102 insertions, 901 deletions
diff --git a/docs/html/programadmin.html b/docs/html/programadmin.html index 4f2b7be40..f047dbcad 100644 --- a/docs/html/programadmin.html +++ b/docs/html/programadmin.html @@ -1,8 +1,7 @@ <HTML ><HEAD ><TITLE ->Product, Component, Milestone, and Version - Administration</TITLE +>Product, Component, Milestone, and Version Administration</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ @@ -17,8 +16,8 @@ REL="PREVIOUS" TITLE="User Administration" HREF="useradmin.html"><LINK REL="NEXT" -TITLE="Bugzilla Security" -HREF="security.html"></HEAD +TITLE="Voting" +HREF="voting.html"></HEAD ><BODY CLASS="section" BGCOLOR="#FFFFFF" @@ -54,13 +53,13 @@ ACCESSKEY="P" WIDTH="80%" ALIGN="center" VALIGN="bottom" ->Chapter 4. Administering Bugzilla</TD +>Chapter 5. Administering Bugzilla</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A -HREF="security.html" +HREF="voting.html" ACCESSKEY="N" >Next</A ></TD @@ -74,64 +73,33 @@ CLASS="section" ><H1 CLASS="section" ><A -NAME="programadmin">4.3. Product, Component, Milestone, and Version - Administration</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 +NAME="programadmin">5.3. Product, Component, Milestone, and Version Administration</H1 ><DIV CLASS="section" ><H2 CLASS="section" ><A -NAME="products">4.3.1. Products</H2 -><FONT -COLOR="RED" ->Formerly, and in some spots still, called - "Programs"</FONT +NAME="products">5.3.1. Products</H2 ><P -> <A +> <A HREF="glossary.html#gloss-product" ><I CLASS="glossterm" ->Products</I +> 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 +> + + are the broadest category in Bugzilla, and tend to represent real-world + shipping products. E.g. if your company makes computer games, + you should have one product per game, perhaps a "Common" product for + units of technology used in multiple games, and maybe a few special + products (Website, Administration...)</P +><P +>Many of Bugzilla's settings are configurable on a per-product + basis. The number of "votes" 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 + NEW status.</P ><P >To create a new product:</P ><P @@ -140,227 +108,76 @@ CLASS="glossterm" TYPE="1" ><LI ><P -> Select "components" from the yellow footer - </P -><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 -> 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 +>Select "products" from the footer</P ></LI ><LI ><P -> Select the "Add" link to the right of "Add a new product". - </P +>Select the "Add" link in the bottom right</P ></LI ><LI ><P -> Enter the name of the product and a description. The - Description field is free-form. - </P +>Enter the name of the product and a description. The + Description field may contain HTML.</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 +>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 ></DIV ><DIV CLASS="section" ><H2 CLASS="section" ><A -NAME="components">4.3.2. Components</H2 -><P -> Components are subsections of a Product. - - <DIV -CLASS="example" -><A -NAME="AEN1405"><P -><B ->Example 4-1. Creating some Components</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1407"><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 +NAME="components">5.3.2. Components</H2 +><P +>Components are subsections of a Product. E.g. 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 +> 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 +>; + these can be changed on bug submission, or at any later point in + a bug's life.</P ><P -> To create a new Component: - </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 +>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 +>Select the "Add" link in the bottom right.</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="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 -> 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 +>Fill out the "Component" field, a short "Description", + the "Initial Owner" and "Initial QA Contact" (if enabled.) + The Component and Description fields may contain HTML; + the "Initial Owner" field must be a login name + already existing in the database. + </P ></LI ></OL ></DIV @@ -369,108 +186,32 @@ CLASS="section" ><H2 CLASS="section" ><A -NAME="versions">4.3.3. Versions</H2 +NAME="versions">5.3.3. Versions</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="AEN1434"><P -><B ->Example 4-2. Common Use of Versions</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1436"><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="AEN1438"><P -><B ->Example 4-3. A Different Use of Versions</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1440"><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: +>Versions are the revisions of the product, such as "Flinders + 3.1", "Flinders 95", and "Flinders 2000". Version is not a multi-select + field; the usual practice is to select the most recent version with + the bug. </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 +>From the "Edit product" screen, select "Edit Versions"</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 +>You will notice that the product already has the default + version "undefined". Click the "Add" link in the bottom right.</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 +>Enter the name of the Version. This field takes text only. + Then click the "Add" button.</P ></LI ></OL ></DIV @@ -479,14 +220,11 @@ CLASS="section" ><H2 CLASS="section" ><A -NAME="milestones">4.3.4. Milestones</H2 +NAME="milestones">5.3.4. Milestones</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 +>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.</P ><DIV CLASS="note" ><P @@ -508,200 +246,44 @@ ALT="Note"></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 +>Milestone options will only appear for a Product if you turned + on the "usetargetmilestone" Param in the "Edit Parameters" screen. + </P ></TD ></TR ></TABLE ></DIV ><P -> To create new Milestones, set Default Milestones, and set - Milestone URL: - </P +>To create new Milestones, set Default Milestones, and set + Milestone URL:</P ><P ></P ><OL TYPE="1" ><LI ><P -> Select "edit milestones" - </P +>Select "Edit milestones" from the "Edit product" page.</P ></LI ><LI ><P -> Select "Add" to the right of the "Add a new milestone" - text - </P +>Select "Add" in the bottom right corner. + 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="AEN1466"><P -><B ->Example 4-4. Using SortKey with Target Milestone</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1468"><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 +>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. This is because milestones often do not + occur in alphanumeric order For example, "Future" might be + after "Release 1.2". Select "Add".</P ></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="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 -> 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 +>From the Edit product screen, you can enter the URL of a + page which gives information about your milestones and what + they mean. </P ><DIV -CLASS="section" -><H2 -CLASS="section" -><A -NAME="voting">4.3.5. Voting</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 @@ -722,397 +304,16 @@ ALT="Tip"></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</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="AEN1502"><P -><B ->Example 4-5. When to Use Group Security</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1504"><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 +>If you want your milestone document to be restricted so + that it can only be viewed by people in a particular Bugzilla + group, the best way is to attach the document to a bug in that + group, and make the URL the URL of that attachment.</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="AEN1519"><P -><B ->Example 4-6. Creating a New Group</B -></P -><DIV -CLASS="informalexample" -><A -NAME="AEN1521"><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="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 -> "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="AEN1536"><P -><B ->Example 4-7. Bugzilla Groups</B -></P -><P -CLASS="literallayout" -><br> -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 privileges, 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 @@ -1149,7 +350,7 @@ WIDTH="33%" ALIGN="right" VALIGN="top" ><A -HREF="security.html" +HREF="voting.html" ACCESSKEY="N" >Next</A ></TD @@ -1173,7 +374,7 @@ ACCESSKEY="U" WIDTH="33%" ALIGN="right" VALIGN="top" ->Bugzilla Security</TD +>Voting</TD ></TR ></TABLE ></DIV |