セキュリティロールの「追加」と「追加先」の挙動を検証する

検証条件
・親と子と、二つのエンティティを作ります。
・親エンティティ対子エンティティは１対多とする。
・親画面に、「名前」という項目だけ設定します。
・子画面に、「名前」という項目に、「親」という検索項目があります。

分かりやすくするため、画面を張っておきます。

検証1：追加と追加先の正しい権限構成

子画面で、「親」という検索項目を使用するために、親エンティティと子エンティティの追加と追加先権限を正しく構成する必要があります。

アクセスレベルは組織全体と選択なしを使って、「親」の検索画面を正しく呼び出せて、セットした値を正常に保存・変更できるよう、必要最小限の正しい権限構成を洗い出します。

よって、

・子画面の検索項目を使うために、小エンティティは、追加権限が必要
・子画面から親エンティティを参照するために、親エンティティは、追加先権限が必要

ってことがわかります。

検証2：アクセスレベルの適用

では、親エンティティのアクセスレベルがユーザで、追加先が組織全体の場合に、親データをどこまでアクセスできるのでしょうか。

答えは、読取の設定が適用されます。

検証3：アクセスレベルがユーザの場合

追加と追加先のアクセスレベルをユーザに下げたら、どんなときに制限がかかってくるのかを確認します。

子の追加がユーザの場合、

自分が作成したデータしか、「親」を変更できません。
つまり、他人が作った「子」データを開いたら、「親」は表示のみになります。
また、新規登録するとき、データは自分のものになるので、「親」を設定できます。

親の追加がユーザの場合、

自分が作成した「親」しか、子に設定できません。
新規するときも、変更するときも、他人が作った親を設定して保存すると、エラーになります。

子と親の追加は両方ともユーザの場合、

自分の子に、自分の親しか追加できません。

ここまでの検証結果を元に、次の挙動になるよう、どんな設定をすればいいかを吟味しながら終わりにします。
・すべての親を検索できますが、自分が作った子にしか、親を設定できません。
・すべての親を検索できますが、自分が作った親しか、子に設定できません。


以上