3.3.2.2.2. 登録者の代理(編集時)¶
ここでは、スケジュール認可における登録者の代理としてスケジュールを編集する場合についての権限の動作を学びます。例として以下のような操作を行いたいとします。[凡例]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に所属するユーザのスケジュールに対して参照および登録が行えます。上記操作を行うための認可設定は以下の通りです。コラム
スケジュール認可の設定方法に関しましては、「 intra-mart Accel Collaboration スケジュール 管理者操作ガイド 」-「 スケジュール認可を設定する 」を参照してください。上記の設定のもとユーザBはユーザCを参加者とするようなスケジュールを登録済みです。ユーザ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の場合><ケースB2の場合><ケースB3の場合>コラム
ケースB3で更新後、ユーザAが再度編集画面を開き、ユーザC2を追加して更新しようとしても更新はできません。ユーザC2はユーザAの権限では登録できないユーザのためです。コラム
ここでのポイントは、代理先ユーザが代理人として編集画面を開き更新を行う際に、参加者に追加されたユーザのみ確認するということです。追加されたユーザの確認は代理先ユーザが登録が行えるか否かです。追加されたユーザに対して代理元ユーザが登録が行えるか否かは考慮しないため注意が必要です。