ここでは、カスタマイズのアクセス権限設定についてには未記載の、付加情報について説明します。

アクセス権限設定で実現されること

アクセス権限設定で権限を付与すると、指定されたアプリに対して以下のことが出来るようになります。

• kintoneアプリなど各種カスタマイズの新規作成

• 既存カスタマイズの読み込み

• kintoneアプリへの登録

例えば新規作成の場合、カスタマイズを作成するアプリを選択した後の画面で、権限チェックが実行されます。

このような仕様のため、以下を実現するものではありません。

• カスタマイズのアプリ選択一覧に、アプリを表示しないようにしたい

これを実現したい場合、kintone上で、kintone接続ユーザーのアクセス権限で制御してください。こちらの関連記事も参照してください。

• カスタマイズの中から、権限のないアプリへのアクセスを制御したい

仮に権限設定がこのような状態だとします。

　アプリA： 権限あり

　アプリB： 権限なし

この状態で、アプリAに対するカスタマイズを作成して、「全レコードを取得する」でアプリBからレコードを取得するカスタマイズを作成することは可能です。

もしアプリBへのアクセスを制御したい場合、カスタマイズはkintoneにログインしているユーザーの権限で実行されることを念頭に置いてください。

レコードやフィールドへのアクセス権の制御は、kintone側のアプリ自体の、例えばレコードのアクセス権の設定で行ってください。

kintoneアプリのWebhookについて

kintoneアプリのWebhookに対するアクセス権限の設定は、kintoneアプリカスタマイズに対する権限と共通です。

例えば、アプリID=1に対する設定であれば、アプリID=1に対するkintoneアプリカスタマイズと、アプリID=1に対するWebhookカスタマイズの両方に適用されます。

定期実行タスクについて

定期実行タスクのカスタマイズに対する権限を設定する場合は、アプリID=-2 (マイナス2) を指定して設定します。

定期実行タスクはアプリIDを指定して作成するものではありませんので、1つの設定ですべての定期実行タスクのカスタマイズに適用されます。

ポータルのカスタマイズについて

ポータルのカスタマイズに対する権限を設定する場合は、アプリID=-1 (マイナス1) を指定して設定します。

ポータルのカスタマイズも、この1つの設定ですべてのポータルカスタマイズに適用されます。

Deploitで管理されたプロジェクトについて

カスタマイズ対象が Deploit プロジェクトの場合、一番左の環境のドメインで権限をチェックします。

グループの特殊な設定方法について

グループをあるgusukuユーザーのメールアドレスと同じ名前にした場合、権限設定上はそのメールアドレスはグループと認識されます。

これを応用すると以下のようなことが実現可能です。

• 退社したユーザーのグループを作ってメンバーを空にする（不要な権限の削除）

• メールアドレスが変更になった場合に、旧メールアドレスでグループを作成し、新しいメールアドレスをメンバーに追加する

いずれも、大規模な権限設定メンテナンスまでのつなぎの設定とし、利用可能ですので、お試しください。