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

3.3.2.2.2. 登録者の代理(編集時)

ここでは、スケジュール認可における登録者の代理としてスケジュールを編集する場合についての権限の動作を学びます。
例として以下のような操作を行いたいとします。
../../../../_images/authz_agency_2_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とします)
Register・・・登録を示します。
Refer・・・参照を示します。
[操作詳細]
組織Aに所属するユーザは組織B、組織C、組織Dに所属するユーザのスケジュールに対して参照は行えますが、登録は行えません。
組織Aに所属するユーザは組織Eに所属するユーザのスケジュールに対して参照および登録が行えます。
組織Bに所属するユーザは組織Cに所属するユーザのスケジュールに対して参照および登録が行えます。
上記操作を行うための認可設定は以下の通りです。
../../../../_images/authz_agency_2_2.png

コラム

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

コラム

ケースB3で更新後、ユーザAが再度編集画面を開き、ユーザC2を追加して更新しようとしても更新はできません。
ユーザC2はユーザAの権限では登録できないユーザのためです。

コラム

ここでのポイントは、代理先ユーザが代理人として編集画面を開き更新を行う際に、参加者に追加されたユーザのみ確認するということです。
追加されたユーザの確認は代理先ユーザが登録が行えるか否かです。
追加されたユーザに対して代理元ユーザが登録が行えるか否かは考慮しないため注意が必要です。