TEXT   13

categorization

Guest on 23rd July 2022 01:48:51 PM

  1. Classifications, Products, Components, Versions, and Milestones
  2. ***************************************************************
  3.  
  4. Bugs in Bugzilla are classified into one of a set of admin-defined
  5. Components. Components are themselves each part of a single Product.
  6. Optionally, Products can be part of a single Classification, adding a
  7. third level to the hierarchy.
  8.  
  9.  
  10. Classifications
  11. ===============
  12.  
  13. Classifications are used to group several related products into one
  14. distinct entity.
  15.  
  16. For example, if a company makes computer games, they could have a
  17. classification of "Games", and a separate product for each game. This
  18. company might also have a "Common" classification, containing products
  19. representing units of technology used in multiple games, and perhaps
  20. an "Other" classification containing a few special products that
  21. represent items that are not actually shipping products (for example,
  22. "Website", or "Administration").
  23.  
  24. The classifications layer is disabled by default; it can be turned on
  25. or off using the useclassification parameter in the *Bug Fields*
  26. section of Parameters.
  27.  
  28. Access to the administration of classifications is controlled using
  29. the *editclassifications* system group, which defines a privilege for
  30. creating, destroying, and editing classifications.
  31.  
  32. When activated, classifications will introduce an additional step when
  33. filling bugs (dedicated to classification selection), and they will
  34. also appear in the advanced search form.
  35.  
  36.  
  37. Products
  38. ========
  39.  
  40. Products usually represent real-world shipping products. Many of
  41. Bugzilla's settings are configurable on a per-product basis.
  42.  
  43. When creating or editing products the following options are available:
  44.  
  45. Product
  46.    The name of the product
  47.  
  48. Description
  49.    A brief description of the product
  50.  
  51. Open for bug entry
  52.    Deselect this box to prevent new bugs from being entered against
  53.    this product.
  54.  
  55. Enable the UNCONFIRMED status in this product
  56.    Select this option if you want to use the UNCONFIRMED status (see
  57.    Workflow)
  58.  
  59. Default milestone
  60.    Select the default milestone for this product.
  61.  
  62. Version
  63.    Specify the default version for this product.
  64.  
  65. Create chart datasets for this product
  66.    Select to make chart datasets available for this product.
  67.  
  68. It is compulsory to create at least one component in a product, and so
  69. you will be asked for the details of that too.
  70.  
  71. When editing a product you can change all of the above, and there is
  72. also a link to edit Group Access Controls; see Assigning Group
  73. Controls to Products.
  74.  
  75.  
  76. Creating New Products
  77. ---------------------
  78.  
  79. To create a new product:
  80.  
  81. 1. Select "Administration" from the footer and then choose
  82.    "Products" from the main administration page.
  83.  
  84. 2. Select the "Add" link in the bottom right.
  85.  
  86. 3. Enter the details as outlined above.
  87.  
  88.  
  89. Editing Products
  90. ----------------
  91.  
  92. To edit an existing product, click the "Products" link from the
  93. "Administration" page. If the useclassification parameter is turned
  94. on, a table of existing classifications is displayed, including an
  95. "Unclassified" category. The table indicates how many products are in
  96. each classification. Click on the classification name to see its
  97. products. If the useclassification parameter is not in use, the table
  98. lists all products directly. The product table summarizes the
  99. information defined when the product was created. Click on the product
  100. name to edit these properties, and to access links to other product
  101. attributes such as the product's components, versions, milestones, and
  102. group access controls.
  103.  
  104.  
  105. Adding or Editing Components, Versions and Target Milestones
  106. ------------------------------------------------------------
  107.  
  108. To add new or edit existing Components, Versions, or Target Milestones
  109. to a Product, select the "Edit Components", "Edit Versions", or "Edit
  110. Milestones" links from the "Edit Product" page. A table of existing
  111. Components, Versions, or Milestones is displayed. Click on an item
  112. name to edit the properties of that item. Below the table is a link to
  113. add a new Component, Version, or Milestone.
  114.  
  115. For more information on components, see Components.
  116.  
  117. For more information on versions, see Versions.
  118.  
  119. For more information on milestones, see Milestones.
  120.  
  121.  
  122. Assigning Group Controls to Products
  123. ------------------------------------
  124.  
  125. On the "Edit Product" page, there is a link called "Edit Group Access
  126. Controls". The settings on this page control the relationship of the
  127. groups to the product being edited.
  128.  
  129. Group Access Controls are an important aspect of using groups for
  130. isolating products and restricting access to bugs filed against those
  131. products. For more information on groups, including how to create,
  132. edit, add users to, and alter permission of, see Groups and Security.
  133.  
  134. After selecting the "Edit Group Access Controls" link from the "Edit
  135. Product" page, a table containing all user-defined groups for this
  136. Bugzilla installation is displayed. The system groups that are created
  137. when Bugzilla is installed are not applicable to Group Access
  138. Controls. Below is description of what each of these fields means.
  139.  
  140. Groups may be applicable (i.e. bugs in this product can be associated
  141. with this group), default (i.e. bugs in this product are in this group
  142. by default), and mandatory (i.e. bugs in this product must be
  143. associated with this group) for each product. Groups can also control
  144. access to bugs for a given product, or be used to make bugs for a
  145. product totally read-only unless the group restrictions are met. The
  146. best way to understand these relationships is by example. See Common
  147. Applications of Group Controls for examples of product and group
  148. relationships.
  149.  
  150. Note: Products and Groups are not limited to a one-to-one
  151.   relationship. Multiple groups can be associated with the same
  152.   product, and groups can be associated with more than one product.
  153.  
  154. If any group has *Entry* selected, then the product will restrict bug
  155. entry to only those users who are members of *all* the groups with
  156. *Entry* selected.
  157.  
  158. If any group has *Canedit* selected, then the product will be read-
  159. only for any users who are not members of *all* of the groups with
  160. *Canedit* selected. *Only* users who are members of all the *Canedit*
  161. groups will be able to edit bugs for this product. This is an
  162. additional restriction that enables finer-grained control over
  163. products rather than just all-or-nothing access levels.
  164.  
  165. The following settings let you choose privileges on a *per-product
  166. basis*. This is a convenient way to give privileges to some users for
  167. some products only, without having to give them global privileges
  168. which would affect all products.
  169.  
  170. Any group having *editcomponents* selected  allows users who are in
  171. this group to edit all aspects of this product, including components,
  172. milestones, and versions.
  173.  
  174. Any group having *canconfirm* selected allows users who are in this
  175. group to confirm bugs in this product.
  176.  
  177. Any group having *editbugs* selected allows users who are in this
  178. group to edit all fields of bugs in this product.
  179.  
  180. The *MemberControl* and *OtherControl* are used in tandem to determine
  181. which bugs will be placed in this group. The only allowable
  182. combinations of these two parameters are listed in a table on the
  183. "Edit Group Access Controls" page. Consult this table for details on
  184. how these fields can be used. Examples of different uses are described
  185. below.
  186.  
  187.  
  188. Common Applications of Group Controls
  189. -------------------------------------
  190.  
  191. The use of groups is best explained by providing examples that
  192. illustrate configurations for common use cases. The examples follow a
  193. common syntax: *Group: Entry, MemberControl, OtherControl, CanEdit,
  194. EditComponents, CanConfirm, EditBugs*, where "Group" is the name of
  195. the group being edited for this product. The other fields all
  196. correspond to the table on the "Edit Group Access Controls" page. If
  197. any of these options are not listed, it means they are not checked.
  198.  
  199.  
  200. Basic Product/Group Restriction
  201. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  202.  
  203. Suppose there is a product called "Bar". You would like to make it so
  204. that only users in the group "Foo" can enter bugs in the "Bar"
  205. product. Additionally, bugs filed in product "Bar" must be visible
  206. only to users in "Foo" (plus, by default, the reporter, assignee, and
  207. CC list of each bug) at all times. Furthermore, only members of group
  208. "Foo" should be able to edit bugs filed against product "Bar", even if
  209. other users could see the bug. This arrangement would achieved by the
  210. following:
  211.  
  212.    Product Bar:
  213.    foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
  214.  
  215. Perhaps such strict restrictions are not needed for product "Bar".
  216. Instead, you would like to make it so that only members of group "Foo"
  217. can enter bugs in product "Bar", but bugs in "Bar" are not required to
  218. be restricted in visibility to people in "Foo". Anyone with permission
  219. to edit a particular bug in product "Bar" can put the bug in group
  220. "Foo", even if they themselves are not in "Foo".
  221.  
  222. Furthermore, anyone in group "Foo" can edit all aspects of the
  223. components of product "Bar", can confirm bugs in product "Bar", and
  224. can edit all fields of any bug in product "Bar". That would be done
  225. like this:
  226.  
  227.    Product Bar:
  228.    foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
  229.  
  230.  
  231. General User Access With Security Group
  232. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  233.  
  234. To permit any user to file bugs against "Product A", and to permit any
  235. user to submit those bugs into a group called "Security":
  236.  
  237.    Product A:
  238.    security: SHOWN/SHOWN
  239.  
  240.  
  241. General User Access With A Security Product
  242. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  243.  
  244. To permit any user to file bugs against product called "Security"
  245. while keeping those bugs from becoming visible to anyone outside the
  246. group "SecurityWorkers" (unless a member of the "SecurityWorkers"
  247. group removes that restriction):
  248.  
  249.    Product Security:
  250.    securityworkers: DEFAULT/MANDATORY
  251.  
  252.  
  253. Product Isolation With a Common Group
  254. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  255.  
  256. To permit users of "Product A" to access the bugs for "Product A",
  257. users of "Product B" to access the bugs for "Product B", and support
  258. staff, who are members of the "Support Group" to access both, three
  259. groups are needed:
  260.  
  261. 1. Support Group: Contains members of the support staff.
  262.  
  263. 2. AccessA Group: Contains users of product A and the Support
  264.    group.
  265.  
  266. 3. AccessB Group: Contains users of product B and the Support
  267.    group.
  268.  
  269. Once these three groups are defined, the product group controls can be
  270. set to:
  271.  
  272.    Product A:
  273.    AccessA: ENTRY, MANDATORY/MANDATORY
  274.    Product B:
  275.    AccessB: ENTRY, MANDATORY/MANDATORY
  276.  
  277. Perhaps the "Support Group" wants more control. For example, the
  278. "Support Group"  could be permitted to make bugs inaccessible to users
  279. of both groups "AccessA" and "AccessB". Then, the "Support Group"
  280. could be permitted to publish bugs relevant to all users in a third
  281. product (let's call it "Product Common") that is read-only to anyone
  282. outside the "Support Group". In this way the "Support Group" could
  283. control bugs that should be seen by both groups. That configuration
  284. would be:
  285.  
  286.    Product A:
  287.    AccessA: ENTRY, MANDATORY/MANDATORY
  288.    Support: SHOWN/NA
  289.    Product B:
  290.    AccessB: ENTRY, MANDATORY/MANDATORY
  291.    Support: SHOWN/NA
  292.    Product Common:
  293.    Support: ENTRY, DEFAULT/MANDATORY, CANEDIT
  294.  
  295.  
  296. Make a Product Read Only
  297. ~~~~~~~~~~~~~~~~~~~~~~~~
  298.  
  299. Sometimes a product is retired and should no longer have new bugs
  300. filed against it (for example, an older version of a software product
  301. that is no longer supported). A product can be made read-only by
  302. creating a group called "readonly" and adding products to the group as
  303. needed:
  304.  
  305.    Product A:
  306.    ReadOnly: ENTRY, NA/NA, CANEDIT
  307.  
  308. Note: For more information on Groups outside of how they relate to
  309.   products see Groups and Security.
  310.  
  311.  
  312. Components
  313. ==========
  314.  
  315. Components are subsections of a Product. E.g. the computer game you
  316. are designing may have a "UI" component, an "API" component, a "Sound
  317. System" component, and a "Plugins" component, each overseen by a
  318. different programmer. It often makes sense to divide Components in
  319. Bugzilla according to the natural divisions of responsibility within
  320. your Product or company.
  321.  
  322. Each component has a default assignee and, if you turned it on in the
  323. Parameters, a QA Contact. The default assignee should be the primary
  324. person who fixes bugs in that component. The QA Contact should be the
  325. person who will ensure these bugs are completely fixed. The Assignee,
  326. QA Contact, and Reporter will get email when new bugs are created in
  327. this Component and when these bugs change. Default Assignee and
  328. Default QA Contact fields only dictate the *default assignments*;
  329. these can be changed on bug submission, or at any later point in a
  330. bug's life.
  331.  
  332. To create a new Component:
  333.  
  334. 1. Select the "Edit components" link from the "Edit product" page.
  335.  
  336. 2. Select the "Add" link in the bottom right.
  337.  
  338. 3. Fill out the "Component" field, a short "Description", the
  339.    "Default Assignee", "Default CC List", and "Default QA Contact" (if
  340.    enabled). The "Component Description" field may contain a limited
  341.    subset of HTML tags. The "Default Assignee" field must be a login
  342.    name already existing in the Bugzilla database.
  343.  
  344.  
  345. Versions
  346. ========
  347.  
  348. Versions are the revisions of the product, such as "Flinders 3.1",
  349. "Flinders 95", and "Flinders 2000". Version is not a multi-select
  350. field; the usual practice is to select the earliest version known to
  351. have the bug.
  352.  
  353. To create and edit Versions:
  354.  
  355. 1. From the "Edit product" screen, select "Edit Versions".
  356.  
  357. 2. You will notice that the product already has the default version
  358.    "undefined". Click the "Add" link in the bottom right.
  359.  
  360. 3. Enter the name of the Version. This field takes text only. Then
  361.    click the "Add" button.
  362.  
  363.  
  364. Milestones
  365. ==========
  366.  
  367. Milestones are "targets" that you plan to get a bug fixed by. For
  368. example, if you have a bug that you plan to fix for your 3.0 release,
  369. it would be assigned the milestone of 3.0.
  370.  
  371. Note: Milestone options will only appear for a Product if you turned
  372.   on the usetargetmilestone parameter in the "Bug Fields" tab of the
  373.   Parameters page.
  374.  
  375. To create new Milestones and set Default Milestones:
  376.  
  377. 1. Select "Edit milestones" from the "Edit product" page.
  378.  
  379. 2. Select "Add" in the bottom right corner.
  380.  
  381. 3. Enter the name of the Milestone in the "Milestone" field. You
  382.    can optionally set the "sortkey", which is a positive or negative
  383.    number (-32768 to 32767) that defines where in the list this
  384.    particular milestone appears. This is because milestones often do
  385.    not occur in alphanumeric order; for example, "Future" might be
  386.    after "Release 1.2". Select "Add".
  387.  
  388. ======================================================================
  389.  
  390. This documentation undoubtedly has bugs; if you find some, please file
  391. them here.

Raw Paste


Login or Register to edit or fork this paste. It's free.