Skip to content

bugzilla
bugzilla
Switch branch/tag
Find file
BlameHistoryPermalink
programadmin.html 21.7 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 
<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%"
>&nbsp;</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
>