0

Bugzillaでのデプロイメントの1つに対するソリューションが必要です。

シナリオの例は次のとおりです。

グループ：スタッフ、学生

プロジェクト/製品のバグ：projectA、projectB

私たちは知る必要があります：

1）ユーザーのグループがプロジェクトにアクセスすることを制限します。

Example= Students cannot access or view bugs in projectA.

2）他のユーザーグループがバグステータスを確認または変更することを制限します

Example= Students cannot change the bug status of projectB  from  NEW to RESOLVED

3）グループの一部のメンバーセットは、バグを報告することはできますが、ファイルを閉じることはできません

Example= StaffA can only file a bug in ProjectA but cannot closed it whereas StaffB can file the bug and also can close the bug

私が検索/グーグルで持っているものから、bugzillaでこの機能を説明できるドキュメントはありませんが、どういうわけか見落としているかもしれません。現在のBugzillaはバージョン3.2rc1です

前もって感謝します。

4

1 に答える 1

1

使用しているBugzillaのバージョンが実際にはわからなかったため、URLは最新リリース4.2のものです。ただし、同じ概念が最新バージョンにも適用されます。たとえば、3.6を使用して、特定のユーザーが以下で説明するのと同じ方法で特定のものを変更できるかどうかを制御します。

1）グループに属していないユーザーにバグが表示されないように制限することは、Bugzillaのグループセキュリティが行うことです。

http://www.bugzilla.org/docs/4.2/en/html/groups.html

あなたの場合の1つの問題は、グループセキュリティがネガティブアクセスではなくポジティブアクセスを制御することです。つまり、表示できないグループではなく、製品のバグを表示できるグループを指定できます。のメンバーがのバグを表示しないようにするには、ユーザーがそのグループにアクセスできないようにする方法を考案してアクセスできるグループが必要です。studentsprojectAprojectAstudents

または、カスタムコードを、、に配置Bugzilla::User::can_see_bugするBugzilla::User::visible_bugsかBugzilla::Bug::check_is_visible、グループ内のユーザーがバグを確認studentsできないように、より厳密な制御を行うことができます。projectA

2）変更を許可する際に多くの細分性を行使できます。

http://www.bugzilla.org/docs/4.2/en/html/cust-change-permissions.html

私たちはこのようなことをします。読み取り/書き込みアクセスを明示的に許可していない限り、読み取り専用アクセスを許可する一連のユーザーがいます。これを行うために、allspecialusersこれらのユーザーが電子メールアドレスに基づいて属するというグループがあります。approved_specialusersこれらのユーザーの一部が手動で追加されるという別のグループがあります。

したがって、私たちの中には、次のBugzilla::Bug::check_can_change_fieldようなコードがあります。

if ($user->in_group('specialusers') &&
    !$user->in_group('approved_specialusers')) {
    $$PrivilegesRequired = 3;
    return 0;
}

projectBバグが製品にあり、変更を加えようとしているユーザーがグループに属しているかどうかを確認することで、やりたいことができますstudents

于 2012-11-01T18:10:15.280 に答える