【pleasanter】試して理解するアクセス制御～レコード単位の権限設定～

１．はじめに

プリザンターのアクセス制御って、奥が深い。。。と常に思います。
業務アプリ作成に当たって、様々なケースがあります。
この人たちには見せたいけど、この人たちには見せたくない。この場面でだけ、この部署の人に編集権限を渡したい。。。etc
まず、業務フロー上でどうしたいのか整理するのが難しい。しかし、整理ができたらプリザンターは様々な手法でアクセス制御を実装できる。すばらしい。

今般、レコードごとに店舗にアクセス権を付けていたものを、母店も見れるようにしてほしいという要望を受け、ふんぎゅ？と思ったのですが、案外簡単にできたので、いろいろやってみたことをここに記載します。

２．やってみること

以下のパターンをやってみようと思います。

no	パターン	補足
1	支店が作成したレコードを統括母店も閲覧できる
2	支店が作成したレコードを統括母店も編集できる
3	レコードをグループ内の支店で相互編集できる	グループを利用して閲覧権限を制御
4	レコードごとに指定したユーザーが閲覧・編集できる	レコード更新時の許可の利用サンプル
5	同じチーム内の文書を同じグループ内のユーザーが書き込みできる	テーブルを利用して閲覧権限を制御
6	サーバースクリプトを使用した閲覧権限の制御	view.Filtersを利用して閲覧権限を制御

３．やってみる

（１）支店が作成したレコードを統括母店も閲覧できる

以下のフローを想定しています。

・支店のユーザーがレコードを作成
・作成したレコードを同じ支店所属のユーザーは編集できる
・その支店の統括母店所属のユーザーが閲覧できる
・その他の支店のユーザーは閲覧できない。

■ アクセス制御の設定

１）サイトのアクセス制御

[サイトのアクセス制御] タブ
各支店・本部のユーザーがレコードを作成することを想定しているため、各支店・本部に「作成」の権限のみ付与しています。

２）レコードのアクセス制御

[レコードのアクセス制御] タブ
選択肢に「ユーザー」「組織」「グループ」を指定した項目は右の[選択肢一覧]に表示されています。
（表示されていない場合は、一度「更新」をクリックし、一覧画面に戻り、再度テーブルの管理画面を表示すると表示されます）

・ 作成したユーザーの店舗が設定されている項目「店舗名」：[読取り]および[更新]にチェックを入れます
・ その店舗の統括母店が指定される項目「母店」：「読取り」にチェックを入れます

これで、作成した支店のユーザーは当該レコードを読取り・更新できて、母店は当該レコードを閲覧することができます。

■ 使用イメージ

狭山支店 のユーザーが見ると、狭山支店のレコードのみが見えます。
統括母店 埼玉本部 のユーザーが見ると、狭山支店と埼玉本部のレコードが見えます。ただし、狭山支店のレコードを開いても「読み取り専用」となり、更新することはできません。

■ テーブルの設定について

今回は、
①ユーザーがレコードを作成
②ユーザーの所属組織が「店舗名」項目に、その店舗の統括母店が「母店」項目に、文書作成時に自動設定されるようにしています。

この部分は、基本機能と、サーバースクリプトを用いて実装しています。
サーバースクリプトは、マスタテーブルから当該支店の「母店」を持ってくるために利用しています。
なお、マスターテーブルの分類Aに店舗名(選択肢[[Depsts]]）を設定していますが、うまく拾ってこれなかったため、タイトルに組織IDを 数字で持たせ、タイトルで フィルタ しています。

日報テーブルのエディタ設定（抜粋）

日報テーブルのサーバースクリプト（「店舗名」に応じた「母店」をマスタテーブルから持ってくる処理）

//計算式の後
const siteId = 9390;
const data = {
    View: {
        ColumnFilterHash: {
            Title: model.ClassA
        }
    }
};
const results = items.Get(siteId, JSON.stringify(data));
if (results.Length > 0) {
  model.ClassB = results[0].ClassB;
}

サーバースクリプトタブ（イメージ）

■ 店舗マスタ（サイトID：9390）

テーブル構成（抜粋）

タイトルに「店舗」の組織IDを数字で持ちます。
今回は、計算式（拡張）で「店舗」（分類A）を指定し、選択肢の値（つまり組織ID）をタイトルに自動で持ってくるようにしています。

手入力や、Excelなどでテーブルを作成しcsvインポートでも。

■ レコードのアクセス権を確認する

サイトの管理者もしくは「権限の管理」の権限を持っているユーザーは、作成済のレコードのアクセス制御を確認することができます。

確認したいレコードの [レコードのアクセス制御] タブ をクリックすると、アクセス権の設定状況が確認できます。
下図は、狭山支店のレコードのイメージです。「狭山支店」「埼玉本部」にアクセス権が付与されていることが確認できます。

■ アクセス権をあとから変更する

サイトの管理者もしくは「権限の管理」および「更新」の権限を持っているユーザーは、作成済のレコードのアクセス制御を変更することができます。

例えば、狭山支店のとあるレコードに対し、「埼玉本部」ユーザーが書き込みできるようにしたい場合。
当該レコードの [レコードのアクセス制御]タブ をクリックして表示し、「埼玉本部」を選択、[詳細設定]で権限設定を開き、「更新」にチェックを入れます。
これで、このレコードについては「埼玉本部」のユーザーが編集できるようになりました。

（２）支店が作成したレコードを統括母店も編集できる

上記の 「アクセス制御の設定」の「レコードのアクセス制御」で「店舗」「母店」の両方に「読取り」と「更新」の権限を付与すればOK！

上記（１）のテーブルとそのほかの設定が同じ状況の場合、
支店が作成したレコードは支店および統括母店が読取、編集できます。
母店が作成したレコードは、母店のみ読取、編集できます。

（３）レコードをグループ内の支店で相互編集できる

グループレポートを本部の総務部がそれぞれのグループ分作成、
グループの店舗が閲覧書き込みをする、という想定。

以下に、作成手順を記載します。

１）グループを作成する

まず、グループを作成します。
管理＞グループ＞新規作成 でグループを作成していきます。

埼玉グループ：狭山支店、所沢支店、埼玉本部
東京グループ：武蔵村山支店、多摩支店、東京本部

２）テーブルの作成（エディタ）

分類A を表示名「グループ」、選択肢 [[Groups]] とします。

３）サイトのアクセス制御

営業部：書き込み（または管理者）
支店およびグループ：「作成」または「メール送信」等。「読取り」は外すこと。
　　　　　　　　　　（何かしらの権限を与えないと、サイトを開けないので）

４）レコードのアクセス制御

分類Aの 「グループ」が選択肢に表示されているので、左の枠内へ移動。
[詳細設定]で「読取り」「更新」にチェック。

※ 普通の[グループ] と [項目]グループ とあるので、注意。（紛らわしい項目名にしてしまいました。）

５） 完成イメージ

営業部が[グループ]を指定して、レコードを作成。
[グループ] 項目に「埼玉グループ」を指定したレコードは、狭山支店、所沢支店、埼玉本部 が閲覧、更新できます。
[グループ] 項目に「東京グループ」を指定したレコードは、武蔵村山支店、多摩支店、東京本部 が閲覧、更新できます。

（４）レコードごとに指定したユーザーが閲覧・編集できる

レコードごとに指定したユーザーが書き込みできる、というのをやってみます。

１）テーブルの設定

分類A を以下の設定とします。その他必要な項目を配置します。

項目名	表示名	選択肢	補足
分類A	対象者	[[Users]]	複数選択

２）サイトのアクセス制御

すべてのユーザーに「作成」を設定。（「メール送信」等でもOK。レコードのアクセス制御を効かせるため「読取り」権限以外 ）

※「作成」権限を付与しても、レコードの作成をしてほしくない場合は、サーバースクリプトで新規作成のボタンを非表示にするとよいです。以下、参考。

//サーバースクリプト。条件「画面表示の前」
//総務部（組織ID2、administrator(id1)以外は「新規作成」ボタン非表示
if ( context.DeptId !== 2 && context.UserId !== 1 ) {
  elements.DisplayType("NewMenuContainer", 1);
}

３）レコードのアクセス制御

上部の「レコード作成時の許可」にて 項目「対象者」を指定し、「読取り」「更新」のアクセス権を付与します。
今回は、途中で閲覧できるメンバーの追加・削除を行いたいので、「レコード更新時の許可」も、同様に指定します。

４）使用イメージ

総務部の人が対象者を指定し、連絡事項を入力したレコードを作成しました。

さて、伊藤太郎さんが「伊藤さんの会」が開催されるらしいよと、伊藤啓太さんからうわさを聞きサイトを開きました。しかし、伊藤太郎さんは「伊藤さんの会」レコードの対象者として指定されていないため見れませんでした。伊藤太郎さんはしょんぼりしてしまいました。

うわさを聞いた総務部担当者はあわてて「伊藤さんの会」レコードに伊藤太郎さんを追加しました。
すると、伊藤太郎さんも見れるようになりました。めでたしめでたし。

また、緑のボランティアメンバーから「岡田真由美」さんはすでに脱退すみで、「吉田みゆき」さんが加入していたことが判明しました。
総務部担当者はあわてて「緑のボランティア」レコードの対象者から「岡田真由美」さんを削除し、「吉田みゆき」さんを追加しました。
これで、岡田真由美さんからは「緑のボランティア」レコードは見えず、吉田みゆきさんはじめ、緑のボランティアメンバーはレコードを見ることができます。めでたしめでたし。

（６）サーバースクリプトを使用した閲覧権限の制御

最後にサーバースクリプトを利用した閲覧権限制御をやってみます。
サーバースクリプト view.Filters でレコードごとの閲覧制御を行います。
また、今回は、店舗マスタからルックアップで指定した店舗のエリアグループを持ってくる、というのもやっています。

テーブル名は「エリア情報共有」。同じエリア内でレコードを閲覧・編集できる、という想定です。

１）店舗マスタ の設定

店舗マスタを作成します。「エリア情報共有」テーブルからのルックアップ、およびサーバースクリプトでもこのマスタテーブルを利用します。

今回は、タイトルを文字列入力の店舗名としています。選択肢 [[Depts]] は使用していません。
代わりに「組織ID」を 分類Aに持ちます。こちらも 選択肢 [[Depts]] は使用せず、数値の直入力としています。
分類Bに持ってきたい「エリア区分」を設定しています。

２）「エリア情報共有」テーブルの設定

テーブルのエディタの設定（抜粋）

発信店舗を選択肢から入力し、ルックアップで「組織ID」「エリア区分」にエリアマスタからの情報を転記する設定としています。

３）ルックアップの設定

「エリア情報共有」テーブルの分類A「発信店舗」の選択肢欄に以下のコードを入力します。
分類Aの自動ポストバックはONとしています。

[
    {
        "SiteId": 9476,
        "Lookups": [
            {
                "From": "ClassA",
                "To": "ClassB"
            },
            {
                "From": "ClassB",
                "To": "ClassC"
            }
        ]
    }
]

４）サーバースクリプトの設定

「エリア情報共有」テーブルの「サーバースクリプト」タブに以下のコードを入力します。
条件は「ビュー処理時」です。

//条件：ビュー処理時
//ログインユーザーのDeptIdを取得
const deptId = context.DeptId;

//エリアマスタテーブルから取得する値のフィルタ設定
const siteId = 9476;
const data = {
    View: {
        ColumnFilterHash: {
            ClassA: deptId
        }
    }
};
//エリアマスタテーブルから情報取得
const results = items.Get(siteId, JSON.stringify(data));

//テーブル分類C「エリア区分」がログインユーザー所属店舗のエリア区分と一致するレコードのみ表示
//ただし、ユーザーID1、組織ID2（総務部）の場合はフィルタを適用しない。
if (results.Length > 0 && context.UsetId !== 1 && deptId !== 2 ) {
  view.Filters.ClassC = '["' + results[0].ClassB + '"]'
}

５）アクセス制御

サイトのアクセス制御は必要店舗に「書き込み」、営業部に「管理者」の設定
レコードのアクセス制御は設定なしです。

６）利用イメージ

各店舗は自身が所属するエリアのレコードが見えます。総務部ユーザーに対してはフィルタが適用されないので、すべてのレコードが見えます。

４.さいごに

繰り返しになりますが、プリザンターのアクセス制御って、奥が深い。。。
そんな複雑な要件、システム屋じゃないんだから実装できない。。。と、やってみたら機能の組み合わせなどで案外できちゃったり。
「はっ！こうやればよいのでは！」と思いついたときの達成感が、たまらない。
でも、思い込みで「できた！」と思っていると、事故ったり。。。アクセス制御は十分理解を深めて、注意深くやらなくてはいけませんね。
まだまだ道半ばです。が、奥が深いので面白い！

お読みいただきありがとうございました。

５.参考文献、記事

公式マニュアル

アクセス制御の概要
サイトのアクセス制御
レコードのアクセス制御（テーブルの管理）
レコードのアクセス制御（レコードの編集）
項目のアクセス制御
FAQ：自分が作成したレコード、または自分が所属するグループや組織が作成したレコードのみ閲覧できるようにしたい
開発者向け機能：サーバスクリプト：view.Filters
テーブルの管理：エディタ：項目の詳細設定：選択肢一覧：ルックアップ
テーブルの管理：プロセス管理：アクセス制御タブ

参考とさせていただいた記事
プリザンターのレコードのアクセス制御を使いこなす
プリザンターのアクセス制御について改めて整理してみる
【プリザンター】 第79回）「レコードのアクセス制御」って使ってますか？
【プリザンター】 第137回）同じテーブル内で常に他人には見えないレコードを作成する設定
【プリザンター】 第138回）サイトのアクセス制御での注意点

内部リンク
【pleasanter】レコードのアクセス制御についてあれこれやってみた①
【pleasanter】レコードのアクセス制御についてあれこれやってみた②