3.4. プロダクト

3.4.1. 新規プロダクトの作成

プロダクトを新規作成するには:

1. フッタの "管理" を選択し、"プロダクト" を管理メニューから選択してください。

2. 右下の "追加" リンクを選択してください。

3. プロダクトの名前と説明を入力してください。 説明には HTML も利用可能です。

4. プロダクトを作成後、Bugzilla は、登録したプロダクトにバグを追加する前に、 コンポーネントを作成する必要があるというメッセージを表示します。 新規コンポーネント作成のリンクから作成してください。 詳細に関しては、Components を参照してください。

3.4.2. プロダクトの編集

既存のプロダクトを編集するには、"管理" ページの "プロダクト" リンクをクリックしてください。もし、'useclassification' パラメータが有効な場合、 "Unclassified" カテゴリを含む、定義されている classification が表示されます。 この表はそれぞれの classification にどれだけのプロダクトがあるかを示します。 プロダクトを見るには classificatino 名をクリックしてください。 'useclassification' パラメータが無効の場合、 表にはプロダクトが直接リストされます。プロダクトの表は、 定義されているプロダクトの情報の概要を表示します。 設定を編集するには、プロダクト名をクリックしてください。 また、プロダクトのほかの属性、たとえば、プロダクトに定義されているコンポーネント、 バージョン、マイルストーン、グループによる制限などについては、 それぞれのリンクを選択してください。

3.4.3. コンポーネント、バージョン、ターゲットマイルストーンの追加・編集

プロダクトの、既存のコンポーネント、バージョン、ターゲットマイルストーンの編集、 もしくは新規追加を行うには、それぞれ "プロダクトの編集" 画面の "コンポーネントの編集"、"バージョンの編集"、"マイルストーンの編集" リンクをクリックしてください。既存のコンポーネント、バージョン、 マイルストーンが表示されます。それぞれの属性を編集するには、 それぞれの名前をクリックしてください。また、表の下側に、 新規コンポーネント、バージョン、マイルストーンを追加するためのリンクがあります。

コンポーネントに関しての詳細は Components を。

バージョンに関しての詳細は 項3.6 を。

マイルストーンに関しての詳細は 項3.7 を。

3.4.4. プロダクトにグループ制限を定義する

"プロダクトの編集" ページには、 "プロダクトのグループによる制限を編集" リンクがあります。 このページでの設定は、編集中のプロダクトで、 どのようにグループと関連した制限を行うかについてです。

グループによる制限は、対象となるプロダクトについて、 プロダクトを他から分離したり、バグへのアクセスを制限したりするために、 グループをどう利用するかの重要な概念です。 作成方法、編集やユーザの追加、そして制限の変更などを含む、 グループのより詳細情報に関しては、項3.15 を参照してください。

"プロダクトのグループによる制限を編集" リンクを "プロダクトの編集" 画面で選択すると、Bugzilla サイトでのすべてのユーザ定義グループを含む表が表示されます。 Bugzilla インストール時に作成されたシステムグループは、 このグループによる制限には利用できません。以下の説明は、 それぞれのフィールドがどういう意味であるかを解説します。

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 項3.4.4.1 for examples of product and group relationships.

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.

If any group has Entry selected, then the product will restrict bug entry to only those users who are members of all the groups with Entry selected.

If any group has Canedit selected, then the product will be read-only for any users who are not members of all of the groups with Canedit selected. Only users who are members of all the Canedit 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.

The following settings let you choose privileges on a per-product basis. 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.

Any group having editcomponents selected allows users who are in this group to edit all aspects of this product, including components, milestones and versions.

Any group having canconfirm selected allows users who are in this group to confirm bugs in this product.

Any group having editbugs selected allows users who are in this group to edit all fields of bugs in this product.

The MemberControl and OtherControl 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.

3.4.4.1. Common Applications of Group Controls

The use of groups is best explained by providing examples that illustrate configurations for common use cases. The examples follow a common syntax: Group: Entry, MemberControl, OtherControl, CanEdit, EditComponents, CanConfirm, EditBugs. 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.

Basic Product/Group Restriction

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:

Product Bar: foo: ENTRY, MANDATORY/MANDATORY, CANEDIT

Perhaps such strict restrictions are not needed for product "Bar". A more lenient way to configure product "Bar" and group "Foo" would be:

Product Bar: foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS

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".

General User Access With Security Group

To permit any user to file bugs against "Product A", and to permit any user to submit those bugs into a group called "Security":

Product A: security: SHOWN/SHOWN

General User Access With A Security Product

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):

Product Security: securityworkers: DEFAULT/MANDATORY

Product Isolation With a Common Group

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:

1. Support Group: Contains members of the support staff.

2. AccessA Group: Contains users of product A and the Support group.

3. AccessB Group: Contains users of product B and the Support group.

Once these three groups are defined, the product group controls can be set to:

Product A: AccessA: ENTRY, MANDATORY/MANDATORY Product B: AccessB: ENTRY, MANDATORY/MANDATORY

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:

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

Make a Product Read Only

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:

Product A: ReadOnly: ENTRY, NA/NA, CANEDIT

For more information on Groups outside of how they relate to products see 項3.15.