intra-mart Accel Collaboration 権限設定ファーストガイド 第3版 2017-08-01

3.3.2.2.4. 参加者の代理(操作ユーザが参加者に含まれている場合)

ここでは、スケジュール認可における代理先ユーザおよび代理元ユーザの両方が参加しているスケジュールについての権限の動作を学びます。
例として以下のような操作を行いたいとします。
../../../../_images/authz_agency_4_1.png
[凡例]
Dev.A・・・組織A(組織Aに所属しているユーザをユーザAとします)
Dev.B・・・組織B(組織Bに所属しているユーザをユーザBとします)
Dev.C・・・組織C(組織Cに所属しているユーザをユーザCとします)
Dev.D・・・組織D(組織Dに所属しているユーザをユーザDとします)
Dev.E・・・組織E(組織Eに所属しているユーザをユーザEとします)
Dev.X・・・組織X(組織Xに所属しているユーザをユーザXとします)
Register・・・登録を示します。
Refer・・・参照を示します。
[操作詳細]
組織Aに所属するユーザは組織B、組織C、組織Dに所属するユーザのスケジュールに対して参照が行えますが、登録は行えません。
組織Aに所属するユーザは組織Eに所属するユーザのスケジュールに対して参照および登録が行えます。
組織Bに所属するユーザは組織A、組織Cに所属するユーザのスケジュールに対して参照および登録が行えます。
組織Bに所属するユーザは組織Dに所属するユーザのスケジュールに対して参照が行えますが、登録は行えません。
組織Xに所属するユーザは組織A、組織B、組織Cに所属するユーザのスケジュールに対して参照および登録が行えます。
上記操作を行うための認可設定は以下の通りです。
../../../../_images/authz_agency_4_2.png

コラム

スケジュール認可の設定方法に関しましては、「 intra-mart Accel Collaboration スケジュール 管理者操作ガイド 」-「 スケジュール認可を設定する 」を参照してください。
上記の設定のもとユーザXはユーザA、ユーザB、ユーザCを参加者とするようなスケジュールを登録済みです。
../../../../_images/authz_agency_4_3.png
  • スケジュールD1・・・ユーザA、ユーザB、ユーザC
ユーザAはユーザBから代理権限を付与されているとします。(代理元:ユーザB、代理先:ユーザA)
ユーザAが上記のスケジュールに対して、下記ケースでそれぞれのユーザを追加して代理編集するとき更新可能なのか、結果は以下の表の通りです。
  • ケースD1・・・ユーザAがユーザD(ユーザAが登録が行えない組織のユーザ)を追加して、参加者:ユーザA、ユーザB、ユーザC、ユーザDで更新
  • ケースD2・・・ユーザAがユーザE(ユーザAが登録が行える組織のユーザ)を追加して、参加者:ユーザA、ユーザB、ユーザC、ユーザEで更新
凡例
○・・・処理可能
×・・・処理不可
ケース 結果
ケースD1 ×
ケースD2
<ケースD1の場合>
../../../../_images/authz_agency_4_4.png
[凡例]
Edit・・・スケジュールの編集を示します。
Agent・・・代理指定を示します。矢印の方向に向かって代理を指定します。
  • ユーザAはケースD1においてスケジュールD1の更新は行えません。
    まずは代理先、代理元の権限を確認し編集画面に遷移できるかチェックをします。
    代理先のユーザAは別の参加者であるユーザB、ユーザCが登録の出来ないユーザであるため、このスケジュールの編集は行えません。
    代理元のユーザBは別の参加者であるユーザA、ユーザCが登録の出来るユーザであるため、このスケジュールはユーザBにとって編集が可能なスケジュールです。
    つまり、ユーザA自身の権限では編集不可ですが、代理元であるユーザBの権限では編集が可能であるため、その代理先であるユーザAも編集画面への遷移が可能です。
    次に、ユーザAはユーザDを追加して更新を行う場合、追加されたユーザDはユーザAが登録が行えないユーザであるため、スケジュールの更新が行えません。
<ケースD2の場合>
../../../../_images/authz_agency_4_5.png
[凡例]
Edit・・・スケジュールの編集を示します。
Agent・・・代理指定を示します。矢印の方向に向かって代理を指定します。
  • ユーザAはケースD2においてスケジュールD1の更新が可能です。
    まずは代理先、代理元の権限を確認し編集画面に遷移できるかチェックをします。
    代理先のユーザAは別の参加者であるユーザB、ユーザCが登録の出来ないユーザであるため、このスケジュールの編集は行えません。
    代理元のユーザBは別の参加者であるユーザA、ユーザCが登録の出来るユーザであるため、このスケジュールはユーザBにとって編集が可能なスケジュールです。
    つまり、ユーザA自身の権限では編集不可ですが、代理元であるユーザBの権限では編集が可能であるため、その代理先であるユーザAも編集画面への遷移が可能です。
    次に、ユーザAはユーザEを追加して更新を行う場合、追加されたユーザEはユーザAが登録が行えるユーザであるため、スケジュールの更新は可能です。

コラム

ここでのポイントは、代理元ユーザが参加者であり、代理ユーザ本人がスケジュールの参加者に含まれている場合、2段階でのチェックを行う点です。
第1段階目のチェックは代理先のユーザおよび代理元のユーザのどちらかがそのスケジュールを編集できるかどうかで、
第2段階目のチェックは登録者の代理と同じように代理先ユーザが追加したユーザに対して登録権限を付与されているかどうかです。
第1段階目の権限チェックでは代理元ユーザおよび代理先ユーザの両方の権限を利用し、第2段階目の権限チェックでは代理先ユーザの権限のみを利用します。