グループによるデータ権限

概要

あるグループに所属しているアカウント同士では登録したデータの参照・更新は可能だが、別のグループに所属するアカウントからは参照のみで更新はさせない、といったような使い方ができます。

これはモデル単位で設定します。

グループモデル - jgroup

データ権限管理は Wagby が提供する「グループ」モデルである jgroup を用います。ログオンアカウントを管理するモデルである juser と連携しており、ログオンアカウントは複数のグループに所属することができます。

グループの作成方法は"アカウント > グループの使い方"をお読みください。

データ権限のパターン

モデル毎に「R:読み取り権限」「W：書き込み権限」の2つの権限を組み合わせたパターンを選択します。

各パターンはそれぞれ下表のように設定されています。

パターンは制約の厳しい順に並んでいます。初期値は「パターン6」（制約なし）が設定されています。

データ所有者の入力欄

データ権限を設定したとき、システム管理者およびグループ管理者で登録・更新画面データを開くと、所有者を変更するための入力欄が用意されます。

この入力欄は項目表示群の末尾に自動的に用意されます。（繰り返しコンテナや外部キー子モデルなどがあった場合、これらを除いた「最初の」項目群の末尾に配置されます。これは画面最下部という意味ではありません。）この位置を変更する方法は用意されていません。

データ権限の動作の仕組み

本機能を使用すると、Wagby はモデルに（内部で利用するデータ権限管理用の）「データ所有者」及び「データ所有者の所属グループ」項目を追加します。データの登録や更新時、この項目に値が自動セットされます。この値を使って利用者（アカウント）の操作を制限します。

データ登録後にユーザの所属グループを変更した場合

データ登録後にユーザの所属グループを変更しても既存のデータは影響を受けません。「データ登録時に設定された所有者の所属グループ」が維持されます。

これを「パターン5」のデータ権限を例に説明します。

用意するグループ

用意するアカウント

佐藤がデータを登録した場合

佐藤が顧客データ(ID:1)を登録します。

佐藤はデータを登録した本人のため、読み書きできます。
鈴木は同一グループのため、読み書きできます。
山田は異なるグループのため、読み取りのみ許可されます。

佐藤の所属グループを変更した後

"satou" (佐藤) の所属グループを技術開発部に変更します。この操作はすでに登録済みのデータには影響がありません。

佐藤のグループを変更したにも関わらず、鈴木が読み書きでき、山田は読み取りのみです。 これは、登録済みデータは登録時の所属グループのIDを保持しているためです。

佐藤が新しいデータを登録した場合

所属グループ変更後に登録を行ったデータについては、変更後のグループが適用されます。

佐藤が過去に登録したデータの「データ所有者」を変更したい場合

顧客IDが1のデータは、佐藤の所属グループが変わっても（データ作成者が佐藤であるため）佐藤はそのまま読み書き可能です。運用ポリシー上、データ所有者を変更したいという場合、次の手順を行ってください。

1. システム管理者またはグループ管理者（後述）でログオンします。
2. 当該データの更新画面を開きます。
3. 「データ所有者」という項目が表示されますので、こちらを佐藤以外のアカウントへ修正します。このとき、データ所有者の所属グループも同時に変更されます。

佐藤がデータ所有者であることはそのままに、データ所有者の所属グループだけを変更したい場合 (1)

対象データが一回でも更新されれば、そのタイミングで（内部で保持されている）「データ所有者の所属グループ」の値も更新されます。この性質を応用して、次の手順で変更することができます。

1. システム管理者またはグループ管理者（後述）でログオンします。
2. 当該データの更新画面を開きます。
3. 「データ所有者」という項目が表示されますので、こちらをいったん佐藤以外のアカウントへ修正します。（例：admin）
4. 再度、更新画面を開きます。「データ所有者」に再び"satou"を選択し、保存します。

佐藤がデータ所有者であることはそのままに、データ所有者の所属グループだけを変更したい場合 (2) 一括変更

上の説明は一件ごと画面操作で変更するものでしたが、複数のデータを一括変更する場合は次の方法を利用できます。

1. "satou"の所属グループをAに変更します。
2. "satou"が所有者となっているデータを Excel または CSV ファイルとしてダウンロードします。
3. ダウンロードしたデータの「データ所有者」を"satou"からシステム管理者(admin)へ変更してアップロード更新を行います。なお admin への変更は一時的なものです。
4. 続けて、ダウンロードデータの「データ所有者」を"satou"へ戻し、再度アップロード更新を行います。

グループ管理者

各グループには、グループ内のデータに対して特別な権限を持つ「グループ管理者」を用意することができます。

「グループ管理者」はプリンシパルとして提供されますが、これが選択できるのはグループ管理者の権限が（同一の所属）グループの権限を超える運用を行うときに限定されます。具体的には次のパターンです。

パターン2を例にあげて説明します。同一グループに属するアカウントは通常、読み取りが許可されています。しかしグループ管理者は通常の権限を強化したものとなっているため、書き込み（データの登録、更新、削除）が行えます。

グループ管理者プリンシパルの選択

グループ管理者はプリンシパルとして用意されます。そのため複数のアカウントをグループ管理者に任命することができます。

図4に示すように、プリンシパルは2種類用意されます。

「グループ管理者」は、グループ管理者の権限でデータを操作することに加え、代理登録を行うことができます。
「グループ管理者（代理登録不可）」は、グループ管理者の権限でデータを操作できますが、代理登録を行うことはできません。

代理登録

システム管理者またはグループ管理者は「データ所有者」という項目を変更することにより、データの代理登録を行うことができます。

準備（プリンシパルの設定）

代理登録できるアカウントに、プリンシパル「グループ管理者」と「アカウント閲覧者」を与えます。（なお、システム管理者はこれらを別途、与えなくても常に代理登録が可能です。）

代理登録を行う

図5で用意したアカウント佐藤で、顧客データの登録画面を開きます。図6に示すように「データ所有者」という項目が表示され、かつ変更できるようになっていることがわかります。（この項目はシステム管理者またはグループ管理者以外では不可視です。）

別のアカウントに変更することができます。（図7）なお、佐藤はグループ管理者のため、所属する同じグループのアカウントに限定されます。

データ権限設定を解除する

データ権限管理を解除するには、「権限パターン」の設定をパターン6（初期値; 制約なし）にします。

データをグループの持ち物とする

例として、グループ A に所属しているユーザがデータを登録したとします。このモデルの権限パターンが "3" のとき 、登録した本人とグループ A の人々で読み書きが可能です。

このユーザがグループ A から B に異動しました。Wagbyのアカウント情報のグループを A から B に変更します。

グループ B に移動したので、グループ A のデータの閲覧や更新は不可としたいのですが、パターン3ではデータを登録した本人は所属グループに関係なくデータを閲覧、更新可能です。

スクリプトを利用する

この問題を解消し、「データはグループの持ち物」とするためにスクリプトを利用する方法を説明します。 データ登録時や更新時にスクリプトでデータ所有者項目の値を消去します。

modelname.useridjshparam = null;

これによってデータ登録者との紐付けがなくなるため、このデータはユーザではなくグループのみで管理されるようになります。

データ所有者の必須チェックを無効化する

更新時に上のスクリプトを設定したとき、更新時にデータ所有者が空欄となります。一般の利用者は問題ありませんが、システム管理者やグループ管理者はデータ所有者項目の閲覧権限が適用され、必須チェックによってエラーとなります。

このため、上記スクリプトを設定する場合、あわせて「データ所有者項目の必須チェックを行わない」を有効にしてください。

グループ階層を利用する

グループ階層を利用すると、上位階層グループの所属ユーザーは、下位階層のグループにも所属していると判定されるようになります。そのため、階層構造の登録前と登録後ではデータの閲覧や編集範囲が広くなります。

ここでは、"アカウント > グループの使い方 > グループ階層" で用意したグループを利用するものとします。設定方法はこちらのリンクにあるマニュアルをお読みください。

階層構造登録を行わない場合、例えば「自治体事業本部」と「自治体東日本事業部」は別々のグループとして扱われます。 「自治体事業本部」グループのみに所属するユーザーは「自治体東日本事業部」グループに所属するユーザーのデータを閲覧/編集することはできません。

そこで「自治体事業本部」を「自治体東日本事業部」の親グループとして登録しました。（図10）

すると「自治体事業本部」のみに所属するユーザーであっても（下位グループである）「自治体東日本事業部」に所属するユーザーのデータを閲覧/編集することができるようになります。

テストのためにuser1,user2,user3を用意します。それぞれ第一階層、第二階層、第三階層のグループに所属しているものとします。

テストで用意した「顧客」モデルには、データ権限3 のパターンを割り当てています。データの登録者および所属グループで読み書きできるというものです。

user1 でログオンし、顧客データを一件、登録します。データ所有者とデータ所属グループは表示されませんが、自動的に設定されます。データ所属グループは自分が所属するグループ（ここでは「自治体事業本部」）が設定されています。

ダイアログから任意のグループ階層を設定させるWDN

ここでデータ所有グループを設定できるようにします。階層図から直接、選択できるようにすることができます。

権限 > データ権限 タブに用意された「グループ階層表示条件スクリプト」を設定します。このスクリプトでは、条件を満たしたときに階層図を表示する、というルールを規定します。（条件を満たさない場合は、空のダイアログが表示されます。）

ここでは下位階層が存在するユーザーのみ階層図を表示するようにしています。

if ($owner.group().children().size() > 0) {
   $owner.group().displayChart();
}

スクリプトでは特別な暗黙変数 $owner が利用できます。この実体は UserElement クラスです。詳細は "スクリプトによって承認者・決裁者を動的に決定する > グループ階層" をお読みください。

データ所有グループ項目の「検索...」ボタンを押下すると、階層図が表示されます。

自グループの「下位」のグループにも操作を許諾する場合、これらをマウスで選択します。

グループの設定を行いました。チェックボックスだけで操作するよりも、階層構造を理解しながら選択できるようになります。

権限の動作確認

user2でログオンします。グループ階層で許容されているため、このデータを閲覧することができます。

次にuser3でログオンします。グループ階層で許容されていないため、データを閲覧することができないことがわかります。

選択させず、常に下位層グループのすべてのユーザーが閲覧可能なデータとするWDN

データ権限のパターンを2とします。データ登録者は読み書き可能で、グループは閲覧可能というものです。

ここで、データ登録時に、常に自グループおよび下位層グループのすべてのユーザーが閲覧可能なデータとするという要件を想定します。ダイアログを使って選択する必要はない、というものです。

この場合、ヘルパの登録および更新のタイミングに次のスクリプトを記述します。

modelname.jgroupidjshparam = $owner.group().descendants().jgroupid();

• データ所属グループを表す jgroupidjshparam 項目に、自身の下位層すべてのグループIDを格納しています。

仕様・制約

• この "グループ階層図" は、ログオンユーザの所属グループではありません。このデータに関する "データ所有者" の "所属グループの階層図" となります。
• そのモデルの検索・一覧表示画面を用意しなかった場合、データ権限は利用できません。（設定は無効となります。）
• データ権限を有効にして更新制限を行っているモデルの一覧表示画面で更新ボタンを用意しないようにしてください。データ権限利用時、詳細画面に用意される更新ボタンは権限を有するユーザーのみが押せるような制御が働きますが、一覧表示画面には未対応です。
• jgroup モデルの "REST API 機能を有効にする" 設定を有効にしてください。（標準では有効となっています。旧版から移行した場合、手動で設定してください。）
• juserモデルにデータ権限を設定することはできません。
• グループ階層図はシステム管理者(admin)では表示させることができません。（システム管理者はグループに所属させて運用することを想定していないためです。）
• 詳細画面では「データ所属グループ」を確認することはできません。