はじめに
kintone内のすべてのアプリを別のアプリで一元管理してみましょう。
本稿内では、これを「アプリ管理」と呼ぶことにします。
アプリ管理をすることで、アプリを一覧で把握でき、管理が容易になり、業務効率の向上が期待できます。
これは、全社のシステム管理をする情報システム部門や部門システム管理者の管理業務に役立ちます。
また、アプリ設定APIを活用すると、さらなる効率化を図ることが可能です。
今回はアプリのアクセス権を一覧化します。
本来アプリのアクセス権は各アプリの設定画面から確認・設定が可能ですが、一覧化することで、アクセス権の運用・管理を効率的に行うことが可能です。
カスタマイズでは、全アプリのアクセス権を取得し、あらかじめ設定したポリシーに違反しているアプリを絞りこむことをめざします。
アプリのアクセス権の管理を行うアプリ
できあがりのイメージ
kintoneのフィールド設定
まずは、アクセス権をレコードに保存するためのアプリを準備します。
設定するフィールドは次のとおりで、1アプリを1レコードで管理し、アクセス権をテーブルに保存する構成です。
「アプリID」フィールドはレコード更新APIを利用する際のkeyとして利用するので、重複禁止の設定を入れておきます。
「アクセス権のポリシー不適合」フィールドは後述しますが、アクセス権の設定ポリシーへの適合状況を管理するために利用します。
フィールド名 | フィールド形式 | フィールドコード | 選択肢 | その他必要な設定 |
---|---|---|---|---|
アプリID | 文字列(1行) | アプリID | 重複禁止 | |
アプリ名 | 文字列(1行) | アプリ名 | ||
アプリのアクセス権 | テーブル | アプリのアクセス権 | ||
アクセス権のポリシー不適合 | チェックボックス | アクセス権のポリシー不適合 | アプリ管理、レコード閲覧、レコード追加、レコード編集、レコード削除、ファイル読み込み、ファイル書き出し |
「アプリのアクセス権」のテーブル内フィールドは次のように設定します。
アプリのアクセス権の設定画面を模しています。
アプリ作成者のユーザーには「アプリ作成者」フィールドにチェックを入れて表現します。
フィールド名 | フィールドタイプ | フィールド形式 | 選択肢 |
---|---|---|---|
ユーザー | ユーザー選択 | ユーザー | |
アプリ作成者 | チェックボックス | アプリ作成者 | アプリ作成者 |
組織 | 組織選択 | 組織 | |
グループ | グループ選択 | グループ | |
許可する操作 | チェックボックス | 許可する操作 | レコード閲覧、レコード追加、レコード編集、レコード削除、アプリ管理、ファイル読み込み、ファイル書き出し、アクセス権の継承 |
アプリを使ったアクセス権運用
アクセス権運用のために、今回は大きく2つのカスタマイズを行います。
- 複数アプリのアクセス権の設定状況を取得し、レコードに一括保存する。
- 複数アプリのアクセス権の設定状況がポリシーに適合しているかチェックし、不適合の際には「アクセス権のポリシー不適合」のフィールドにチェックを入れる。
これらのカスタマイズによって、アクセス権の設定状況が一覧化され、確認しやすくなります。
また、ポリシーが不適合のアプリを絞り込んで適切な設定に更新するといった運用を効率的に実践できます。
アクセス権の設定ポリシーとして、今回2つのケースを例として紹介します。
- アプリ管理者として2名以上のユーザーが設定されている。
- Everyoneにはレコード削除させない。
これらのポリシーに不適合の場合は、「アクセス権のポリシー不適合」の「アプリ管理」や「レコード削除」フィールドにチェックを入れるようなカスタマイズを行います。
カスタマイズのコーディング例
今回のコーディング例ではロジックにフォーカスして、ローディングアイコンの設置や要素のスタイリングは行っていません。
また、アプリやレコードのAPI操作において全件処理に対応させていないので、必要に応じて
@kintone/rest-api-client
を利用する等で対応させてください。
アプリのアクセス権の保存
レコード一覧画面にアプリのアクセス権を取得するボタンを配置します。
そのボタンを押すと、アクセス権が保存されるようにします。
大まかな流れは以下のとおりです。
- 複数のアプリの情報を取得するAPI でアプリの情報一覧を取得する。
- アプリのアクセス権の設定を取得するAPI で各アプリのアクセス権情報を取得する。
- レコード更新のAPI を利用してレコードとして保存する。
|
|
buildPermissionTable()
で各アプリのアクセス権取得からテーブルフィールドの値への整形しています。
アプリ作成者の情報をアクセス権取得のAPIは持っていないので、引数で与えられなければ取得するような形にしています(今回は引数が与えられていますが、この関数の汎用性確保のための記述です)。
ポリシー適合状況の確認
レコード一覧画面に「アプリアクセス権のポリシー適合状況確認」のボタンを配置します。
そのボタンを押下すると各アプリにおけるアクセス権ポリシー適合状況がチェックされます。
不適合の場合は、「アクセス権のポリシー不適合」のフィールドにチェックを入れるようにします。
アプリ管理権限に関するポリシー例
「アプリ管理者として2名以上のユーザーが設定されている」というポリシー例をチェックするカスタマイズは次のとおりです。
ロジックとしては、ここではシンプルにアプリ管理者が1名のみということを判定します。
|
|
レコード削除権限に関するポリシー例
「Everyoneにはレコード削除させない」というポリシー例をチェックするカスタマイズを見ていきたいと思います。
シンプルにEveryoneグループにレコード削除権限が含まれているかの判定をしています。
|
|
まとめ
アプリのアクセス権を管理するアプリのカスタマイズ例を紹介しました。
また、アクセス権のポリシーについて2つ例を紹介しましたが、自社のアプリ運用の考え方に応じたロジックを組み込んでいただければと思います。
本記事がアクセス権運用の効率化のヒントになれば幸いです。