3.3.2.2.3. 参加者の代理（操作ユーザが参加者に含まれていない場合）¶

ここでは、スケジュール認可における代理先ユーザが参加しておらず代理元ユーザが参加しているスケジュールについての権限の動作を学びます。

例として以下のような操作を行いたいとします。

[凡例]

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に所属するユーザは組織Dに所属するユーザのスケジュールに対して参照が行えますが、登録は行えません。

組織Xに所属するユーザは組織B、組織Cに所属するユーザのスケジュールに対して参照および登録が行えます。

上記操作を行うための認可設定は以下の通りです。

コラム

スケジュール認可の設定方法に関しましては、「 intra-mart Accel Collaboration スケジュール 管理者操作ガイド 」-「 スケジュール認可を設定する 」を参照してください。

上記の設定のもとユーザXはユーザB、ユーザCを参加者とするようなスケジュールを登録済みです。

• スケジュールC1・・・ユーザB、ユーザC
• スケジュールC2・・・ユーザB、ユーザD

ユーザAはユーザBから代理権限を付与されているとします。（代理元：ユーザB、代理先：ユーザA）

ユーザAが下記ケースでそれぞれのユーザを追加して代理編集するときスケジュールの更新が可能なのか、結果は以下の表の通りです。

• ケースC1・・・ユーザAがスケジュールC1にユーザD（ユーザAが登録が行えない組織のユーザ）を追加して、参加者：ユーザB、ユーザC、ユーザDで更新
• ケースC2・・・ユーザAがスケジュールC1にユーザE（ユーザAが登録が行える組織のユーザ）を追加して、参加者：ユーザB、ユーザC、ユーザEで更新
• ケースC3・・・ユーザAがスケジュールC2を編集しようとする

凡例

○・・・処理可能

×・・・処理不可

ケース	結果
ケースC1	×
ケースC2	○
ケースC3	×（編集画面へ遷移できない）

＜ケースC1の場合＞

[凡例]

Edit・・・スケジュールの編集を示します。

Agent・・・代理指定を示します。矢印の方向に向かって代理を指定します。

• ユーザAはケースC1においてスケジュールC1の更新は行えません。

  まずは代理元の権限を確認し編集画面に遷移できるかチェックをします。

  参加者であるユーザCは代理元のユーザBが編集することが出来るユーザであるため、このスケジュールはユーザBにとって編集可能なスケジュールです。

  つまり、ユーザBの代理先であるユーザAもこのスケジュールを編集可能ということになり、編集画面へ遷移可能です。

  次に、ユーザAはユーザDを追加して更新を行う場合、追加されたユーザDはユーザAが登録できないユーザのため、スケジュールの更新は行えません。

＜ケースC2の場合＞

[凡例]

Edit・・・スケジュールの編集を示します。

Agent・・・代理指定を示します。矢印の方向に向かって代理を指定します。

• ユーザAはケースC2においてスケジュールC1の更新が可能です。

  まずは代理元の権限を確認し編集画面に遷移できるかチェックをします。

  参加者であるユーザCは代理元のユーザBが編集することが出来るユーザであるため、このスケジュールはユーザBにとって編集可能なスケジュールです。

  つまり、ユーザBの代理先であるユーザAもこのスケジュールを編集可能ということになり、編集画面へ遷移可能です。

  次に、ユーザAはユーザEを追加して更新を行う場合、追加されたユーザEはユーザAが登録が行えるユーザのため、スケジュールの更新が可能です。

＜ケースC3の場合＞

[凡例]

Edit・・・スケジュールの編集を示します。

Agent・・・代理指定を示します。矢印の方向に向かって代理を指定します。

• ユーザAはケースC3においてスケジュールC2の更新は行えません。

  まずは代理元の権限を確認し編集画面に遷移できるかチェックをします。

  参加者であるユーザDは代理元のユーザBは登録が行えないユーザであるため、このスケジュールはユーザBにとって編集が行えないスケジュールです。

  つまり、ユーザBの代理先であるユーザAもこのスケジュールを編集不可ということになり、編集画面へ遷移不可です。

コラム

ここでのポイントは、代理元ユーザが参加者であり、代理ユーザ本人がスケジュールの参加者に含まれていない場合、2段階でのチェックを行う点です。

第1段階目のチェックは代理元のユーザがそのスケジュールを編集できるかどうかで、

第2段階目のチェックは登録者の代理と同じように代理先ユーザが追加したユーザに対して登録が行えるかどうかです。

第1段階目の権限チェックでは代理元ユーザの権限のみを利用しますが、第2段階目の権限チェックでは代理先ユーザの権限のみを利用します。