2
1
0

JIRA Cloudのトライアルから契約前提でテスト中です。
プロジェクト単位で閲覧権限を中心に権限の設定をしたいと思います。
ドキュメント等を読んではいるものの、なかなか理解が進みません。

一般的にグループを作り、そのグループに権限を設定しようと思っていたところ、ロールベースの方が良いということを見つけました。次のスレッドは読ませていただきました。

JIRA/Confuenceの検索対象/権限設定について


いくつか質問させていただきます。

  1. グループとロールの違いについて グループとロールの違いがいまいちよくわかりません。
    グループは管理者が権限設定するのに対して、ロールはロールの管理者にロールの管理自体を移譲することができるということが簡単な違いでしょうか?

  2.  ロールの設定について管理のUIの日本語化がいまいちで良くわからない
     /admin/accessconfigからUserとGroupsの設定ができるので、グループはここで設定するかと思います。
    ロールはどこで設定すれば良いのでしょうか? 
    /secure/project/ViewProjectRoles.jspaからで良いのでしょうか?

  3. atlassian-addons-project-accessとはなんでしょうか?
    デフォルトではAdministratorsとatlassian-addons-project-accessの2つが存在します。3つのプロジェクトのうち1つ(テストJIRA)だけを制限したいと思います。
    test-jira-accessというロールを作成する流れだと思いますが、 atlassian-addons-project-accessの継承関係は無いと無視して良いのでしょうか?test-jira-accessの設定したものは単独で動作するという意味です。

  4. デフォルトではAdministratorsでさえも私の管理者のさえメンバーとして入ってませんが、グループや他の設定を継承しているのでしょうか?
    TESTJIRAプロジェクトは管理者の私だけ閲覧できるとするとき、Administratorsに私を追加するのか、test-jira-accessに私を追加するのか。。。
    test-jira-accessには他者を一切追加しないで、私は総合的なAdminなのでプロジェクトでだれもメンバーのいないtest-jira-accessを使う設定にすれば、自動的に私だけが使えることになりますでしょうか?

  5. 管理者の私は、ロールやグループに都度登録した方が良いのでしょうか? 


かなり多くの質問と整理ができておりませんが、よろしくお願いいたします。

    Commentコメントを追加...

    1 回答

    1.  
      3
      2
      1

      私の考えですが、以下の通りとなります。ご参考になれば幸いですが、不明な点がありましたらコメントを頂ければと思います。また、下記の Blog も参考になるかと思います。

      https://www.ricksoft.jp/blog/archives/8031/

      グループとロールの違いについて グループとロールの違いがいまいちよくわかりません。
      グループは管理者が権限設定するのに対して、ロールはロールの管理者にロールの管理自体を移譲することができるということが簡単な違いでしょうか?

      ご指摘の通りかと思います。

      グループやロールを使うのは、主にユーザーの権限を管理する事だと思います。権限スキームやワークフローの条件の指定で「ロール」を指定する方法と、「グループ」を指定する方法が有りますが、「ロール」を指定した方がお勧めです。そうしますと、ワークフローや権限スキームを使い回しにして、プロジェクト別の権限をロールで指定する事ができます。

      例えばロールで

      • プロジェクト管理者
      • マネージャー
      • ユーザー

      というロールを作成しておいて、各ロールの権限を権限スキームやワークフローで管理しておく。このスキームを各プロジェクトに適用して、各プロジェクトが「プロジェクト管理者」「マネージャー」「ユーザー」を指定するという事ができます。


       ロールの設定について管理のUIの日本語化がいまいちで良くわからない

       /admin/accessconfigからUserとGroupsの設定ができるので、グループはここで設定するかと思います。
      ロールはどこで設定すれば良いのでしょうか? 
      /secure/project/ViewProjectRoles.jspaからで良いのでしょうか?

       /admin/accessconfig でユーザーとグループが設定できますが、こちらで設定するのはアプリケーションを利用する権限の設定です。Atlassian Cloud ですと、Confluence, JIRA Software, JIRA Service Desk といったアプリケーションを利用するユーザーとグループの管理です。

      ロールの管理は、JIRA Software / JIRA Core / JIRA Service Desk というアプリケーションの中のプロジェクトの権限設定です。

      JIRA で利用するためのロールの定義は、ご指摘の通り /secure/project/ViewProjectRoles.jspa から実施します。また、この画面でデフォルトのロール割り当て(既定のメンバー管理)が定義できます。これはプロジェクトを作成した時に各ロールに割り当てられるユーザーとグループです。

      /secure/project/ViewProjectRoles.jspa でロールの定義とデフォルトのロールを管理して、各プロジェクトのロール設定はプロジェクト管理画面のユーザーと(/plugins/servlet/project-config/HT/people)で指定します。

      atlassian-addons-project-accessとはなんでしょうか?


      デフォルトではAdministratorsとatlassian-addons-project-accessの2つが存在します。3つのプロジェクトのうち1つ(テストJIRA)だけを制限したいと思います。
      test-jira-accessというロールを作成する流れだと思いますが、 atlassian-addons-project-accessの継承関係は無いと無視して良いのでしょうか?test-jira-accessの設定したものは単独で動作するという意味です。

      atlassian-addons-project-access はアドオンが利用するロールです。基本的にはデフォルトのままにしておいて良いと思います。

      ご参考:https://confluence.atlassian.com/servicedeskcloud/blog/2017/02/add-on-permissions-update?_ga=2.73321235.1282967017.1538978455-833602621.1523711250

      プロジェクトにアクセス制限を加える場合、権限スキームを変更する必要が有ります。Default Permission Scheme では、「プロジェクトの閲覧」が「アプリケーションアクセスログイン済のユーザー全員」になっています。これですと、当該アプリケーションを利用できる人全員がアクセス可能となります。これをロールに変更して管理する事をお奨めします。

      test-jira-access というプロジェクト固有のロールは作らない方が良いと思います。project-access という汎用的ロールを作っておいて、「テストJIRA」プロジェクトの設定画面の「ユーザー」で「テストJIRAにアクセスできる人とグループを指定します。こうしておくと、4つ目のプロジェクトで制限を加えたくなった場合に、権限スキームを流用できて ロールに割り当てるグループとユーザーを変更するだけで良くなります。

      デフォルトではAdministratorsでさえも私の管理者のさえメンバーとして入ってませんが、グループや他の設定を継承しているのでしょうか?
      TESTJIRAプロジェクトは管理者の私だけ閲覧できるとするとき、Administratorsに私を追加するのか、test-jira-accessに私を追加するのか。。。
      test-jira-accessには他者を一切追加しないで、私は総合的なAdminなのでプロジェクトでだれもメンバーのいないtest-jira-accessを使う設定にすれば、自動的に私だけが使えることになりますでしょうか?

      グルーバルパーミッションでJIRA 管理者に指定されていれば、全てのプロジェクトの管理権限を持ちます。ただ、管理画面は開けますが、課題を閲覧できるかどうかはパーミション・スキームの設定次第です。

      TESTJIRA プロジェクトを特定の人に制限する事も、パーミション・スキームで「プロジェクトの閲覧」を制限する事で閲覧できます。テスト用のユーザーを作ってテストする事をお奨めします。

      管理者の私は、ロールやグループに都度登録した方が良いのでしょうか? 

      JIRA 管理者であれば管理画面は開けますので、必要無いと思います。

      以上、ご確認のほどよろしくお願いします。

      1. 樋口晃

        長文のため五月雨式に回答しております。メールが随時送信される事をご容赦下さい。

      2. Smokey Blues

        樋口さま、すごくご丁寧にありがとうございました。おかげさまで一気に理解が進みました。

        ほどんどのプロジェクトを公開するが、一部だけ非公開にする運用として、各プロジェクトごとの使い回しが出来るような抽象名のロールを作成し、それを使い回すことが解とわかりました。

        汎用的なのは、ご教示いただいたとおり、

        • プロジェクト管理者
        • プロジェクトマネージャー
        • プロジェクトユーザー

        となりますね。そしてこれを使い回すので、非公開のプロジェクトだけ権限スキームをそのプロジェクトのロールに割り当てるということでしょうね。

        プロジェクトにアクセス制限を加える場合、権限スキームを変更する必要が有ります。Default Permission Scheme では、「プロジェクトの閲覧」が「アプリケーションアクセスログイン済のユーザー全員」になっています。これですと、当該アプリケーションを利用できる人全員がアクセス可能となります。これをロールに変更して管理する事をお奨めします。

        通常の公開プロジェクトはDefault Permission Schemeを使うものとし、しかしロールのプロジェクトユーザーに変更する。
        非公開プロジェクトは、前述のようにロールは同じプロジェクトユーザーを利用するが、非公開専用の権限スキームを別途作成しそれを割りあてる。
        こんな感じで大丈夫でしょうか?
        プロジェクトロールはプロジェクト固有のものを作らず、権限スキームのほうをプロジェクト固有のものを作るであってますでしょうか?

      3. Smokey Blues

        追記すみません。
        プロジェクト固有の権限スキームであるTESTJIRAパーミッションスキームを、Default Permission Schemeを複製して設定変更しようとしました。

        プロジェクト管理者というロールを作成してしまいましたが、Administratorsが既にありますが必要なかったでしょうか?ということは、プロジェクトマネージャー、プロジェクトユーザーの2つを作ればよかったかな。。。


        ラジオボタン下から2番目のプロジェクトリーダーとは何でしょうか?これはロールでは無いのでしょうか。。。

      4. 樋口晃

        Smokey Blues さん

        確認ありがとうございます。

        通常の公開プロジェクトはDefault Permission Schemeを使うものとし、しかしロールのプロジェクトユーザーに変更する。
        非公開プロジェクトは、前述のようにロールは同じプロジェクトユーザーを利用するが、非公開専用の権限スキームを別途作成しそれを割りあてる。
        こんな感じで大丈夫でしょうか?

        通常のプロジェクトで使う、Default Permission Scheme はそのままで良いかと思ってました。ロールのプロジェクトユーザーに変更するという事は、プロジェクト参照権限にロールを指定するという事ですか? そうすると登録した人しか利用できない制限が入ってしまうのではないでしょうか。
        3つのプロジェクトのうち、2つは制限しなくて良かったのでは?

        プロジェクト管理者というロールを作成してしまいましたが、Administratorsが既にありますが必要なかったでしょうか?ということは、プロジェクトマネージャー、プロジェクトユーザーの2つを作ればよかったかな。。。

        私が「プロジェクト管理者」と記載してしまったので混乱させてしまった様ですが、私は Administrator ロールの事を「プロジェクト管理者」と記載していました。2つ作れば良いと思います。

        ラジオボタン下から2番目のプロジェクトリーダーとは何でしょうか?これはロールでは無いのでしょうか。。。

        プロジェクトリーダーは似ていますが、ロールでは有りません。プロジェクトリーダーはプロジェクトの詳細画面で確認と変更ができます。プロジェクトリーダーについては、下記をご参照下さい。

        プロジェクトリーダーとは何ですか?

      5. Smokey Blues

        通常のプロジェクトで使う、Default Permission Scheme はそのままで良いかと思ってました。ロールのプロジェクトユーザーに変更するという事は、プロジェクト参照権限にロールを指定するという事ですか? そうすると登録した人しか利用できない制限が入ってしまうのではないでしょうか。
        3つのプロジェクトのうち、2つは制限しなくて良かったのでは?

        おっしゃるとおりですね。通常のプロジェクトはDefault Permission Schemeをそのまま使い、閲覧制限等したいプロジェクトをDefault Permission Schemeを複製して(複製しなくても良いけど)、ロールベースに変更する。となりますね。。。整理できました。


        私が「プロジェクト管理者」と記載してしまったので混乱させてしまった様ですが、私は Administrator ロールの事を「プロジェクト管理者」と記載していました。2つ作れば良いと思います。

        プロジェクト管理者すなわちAdministratorsロールはデフォルトで作られる、存在するということですね。


        プロジェクトリーダーは似ていますが、ロールでは有りません。プロジェクトリーダーはプロジェクトの詳細画面で確認と変更ができます。プロジェクトリーダーについては、下記をご参照下さい。

        プロジェクトリーダーは別枠なので、プロジェクトマネージャー、プロジェクトユーザーの2つを作ることとしました。


        おかげさまでだいぶ理解が進んできました。
        ロールの設定で挙動がうまく実現できなかったら、また追記で質問させていただきますm(__)m


      Commentコメントを追加...