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

最終更新日: 2022年3月24日
R8 | R9

概要

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

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

グループモデル - jgroup

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

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

グループモデルとアカウントモデル

データ権限のパターン

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

データ権限の設定

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

パターン データ登録者 同一の所属グループ その他の所属グループ
R W R W R W
パターン1 - - - -
パターン2 - - -
パターン3 - -
パターン4 - -
パターン5 -
パターン6 (初期値)

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

ワンポイント

システム管理者は(パターンの設定に関わらず)すべてのデータの閲覧と更新を行うことができます。

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

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

注意

そのため、設定変更後はテーブル構造が変わります。既存のテーブルをすべて削除したあと、テーブルの再作成を行ってください。

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

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

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

用意するグループ

グループID (主キー) グループ名
1000総務部
1001営業部
1002技術開発部

用意するアカウント

アカウント 名前 所属グループ
satou佐藤総務部
suzuki鈴木総務部
yamada山田技術開発部

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

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

顧客ID 作成者(データ所有者) データ所有者の所属グループ 佐藤の操作 鈴木の操作 山田の操作
RWRWRW
1satou1000 -

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

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

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

顧客ID 作成者(データ所有者) データ所有者の所属グループ 佐藤の操作 鈴木の操作 山田の操作
RWRWRW
1satou1000 -

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

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

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

顧客ID 作成者(データ所有者) データ所有者の所属グループ 佐藤の操作 鈴木の操作 山田の操作
RWRWRW
2satou1002 -

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

顧客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"へ戻し、再度アップロード更新を行います。

グループ管理者

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

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

パターン 同一の所属グループ グループ管理者の権限
R W
パターン1 - - RW
パターン1 - - R
パターン2 - RW
パターン4 - RW

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

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

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

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

二つのグループ管理者プリンシパル

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

代理登録

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

グループ管理者の権限が "RW" となっている必要があります。"R" では代理登録はできません。

準備(プリンシパルの設定)

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

グループ管理者とアカウント閲覧者のプリンシパルを与える

代理登録を行う

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

データ所有者項目が表示される

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

データ所有者を変更した

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

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

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

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

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

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

スクリプトを利用する

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

modelname.useridjshparam = null;
"modelname" の部分は適切なモデルIDに読み替えてください。

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

重要

この値を消去したデータは、グループ管理者で変更できなくなります。(この項目の必須チェックにより、保存が失敗します。)

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

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

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

データ所有者項目の必須チェックを行わない

グループ階層を利用する

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

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

用意したグループ階層

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

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

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

ワンポイント

更新/削除ボタンの表示制御も所属グループのみだけではなく、下位層グループについても考慮するようになります。そのため、下位層グループのデータについても更新/削除ボタンが表示されるようになります。

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

システム管理者(admin)アカウントではグループ階層は表示されません。システム管理者以外のアカウントでお試しください。
ユーザーの登録

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

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

データを一件登録する

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

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

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

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

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

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

条件を記述せず $owner.group().displayChart(); とすると常に階層図が表示されますが、下位階層グループをもたないユーザーの場合、空のダイアログが表示されるため意味がありません。そのため上のように下位階層がある場合のみ、という条件をつけるとよいでしょう。
スクリプトの設定
設定したスクリプトは WEB-INF/script/<モデルID>/<モデルID>PHelper_groupSelection.js として保存されます。

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

階層図の表示

注意

この "グループ階層図" は、ログオンユーザの所属グループではなく、"データ所有者の所属グループの階層図" となります。
ログオンユーザ "ユーザ1" のグループ階層図という意味ではありません。このデータに関する "データ所有者" のグループ階層図が表示されています。

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

下位グループの選択

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

下位グループの選択を完了した

権限の動作確認

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

user2ではデータを閲覧できる

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

user3はデータを閲覧できない

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

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

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

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

modelname.jgroupidjshparam = $owner.group().descendants().jgroupid();
  • データ所属グループを表す jgroupidjshparam 項目に、自身の下位層すべてのグループIDを格納しています。
"modelname" の部分は適切なモデルIDに読み替えてください。

運用上の注意

この機能はデータ所有者(データの登録者)の所属グループよりも下位の階層に対して権限を付与するために用意されています。上位階層に属するユーザーでデータを登録することでダイアログにグループ階層が表示され、下位階層の操作権限を付与することができます。

仕様・制約

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