フィールド共有を設定するための権限構成

ログインユーザがフィールド共有を設定できるように、セキュリティロールの構成を紹介します。

フィールド共有はレコード共有の一部なので、フィールド共有するために、まずレコード共有するための権限が必要です。下図右側の「共有」列で設定します。

フィールド共有の設定情報は、「フィールド共有」というエンティティに格納されます。フィールド共有設定は、「フィールド共有」エンティティに、共有情報を追加すると考えていいです。

一つのフィールドを複数のユーザ、または複数のチームに共有できるので、以下４エンティティのへ権限を適切に構成すれば、この権限を持つユーザがフィールド共有を設定できるようになります。
・共有フィールドエンティティ
・共有対象フィールが含まれるエンティティ
・ユーザエンティティ
・チームエンティティ

また、共有しようとするセキュリティフィールドの特権を持たないといけません。

では、以下シナリオの設定を確認します。
・「フィールド共有テキスト」というエンティティがあります。
・「セキュリティ項目」というセキュリティフィールドが前記エンティティにあります。
・ユーザAに、「営業課長」というセキュリティロールを付与します。
・ユーザAが、フィールド共有設定できるよう、権限を与えます。

1.セキュリティロール設定画面で、下表の要領で設定します。

※アクセスレベルは全て組織全体とします

「追加」と「追加先」の意味はセキュリティロールの追加と追加先を検証をご参照ください。

2.セキュリティフィールドプロファイルにて、読込と更新を「あり」にします。

以上要領で設定したセキュリティロールとセキュリティフィールドプロファイルが付与されたユーザがフィールド共有を設定できるようになります。

以上

チームからのセキュリティロール継承

Dynamicsでは、ユーザにも、チームにもセキュリティロールを付与できます。ユーザが複数のセキュリティロールを持つ場合、もっとも制限のゆるい権限が適用されることになります。

ユーザをチームに追加した場合、チームとユーザのセキュリティロールの付与方法は三つのケースに分けられます。

※○：付与する　×：付与しない

ケース1では、二つのセキュリティロールがユーザに付与することになり、最も制限のゆるい権限が適用されることを確認できています。

ケース2は一般的な運用パターンです。
一つだけ注意するところがあります。レコードをチームに割り当てて保存すると、エラーになります。チームに、レコードを持つための作成権限がないからです。適切なセキュリティロールをチームに付与すれば、問題解決です。

ケース3では、ユーザにセキュリティロールがありません。チームのセキュリティロールを継承できるかどうかは今回のテイマです。

まず、以下要領で、セキュリティロール、チーム、ユーザを作ります。
・セキュリティロール名：試験ロール　　※取引先企業に、組織全体の読取権限だけ設定
・チーム名：試験チーム
・ユーザ名：試験ユーザ　　※試験チームに追加

つぎに、検証を三つ行います。

検証1：
試験チームにシステム管理者ロールを付与します。
試験ユーザにセキュリティロールを付与しません。

以下の検証結果を確認できました。
・試験ユーザは正常にログインできます。
・一覧画面を開けます。
・フォーム画面を開けません。

よって、ユーザにセキュリティロールを付与しない場合、チームの権限を不完全継承できます。

検証2：
検証１の続きです。試験ユーザに、試験ロールを付与します。

以下検証結果を確認できました。
・試験ユーザはシステム管理者のすべて操作を行えます。

よって、ユーザにセキュリティロールを付与すれば、チームの権限を完全に継承できます。
※検証2で、取引先企業の作成・修正・削除を正常に行いました。

検証3：
検証2の続きです。試験ユーザから、試験ロールを削除します。

検証1と同じ結果になると思いましたが、そうではなかった。
検証2で行った取引先企業の作成・修正・削除は引き続きできます。
他の画面については検証1と同じ結果になります。

よって、権限の設定が不可逆になってしまうときがあります。これは不備でしょう。

最後に、下記結論を纏めます。
・ユーザにセキュリティロールの設定は必須です。
・ユーザにセキュリティロールを設定すれば、チームのセキュリティロールを継承できます。

以上

セキュリティロールとレコード共有とフィールド共有

セキュリティロール、レコード共有、フィールド共有といったセキュリティ設定は、
「特権」と「アクセスレベル」をセットで設定して始めて、完了となります。

まず、セキュリティロール、レコード共有、フィールド共有で設定できる項目を確認します。

・セキュリティロール

セキュリティロール設定画面で、八つの特権と五つのアクセスレベルを定義できます。
特権：作成、読み込み、書き込み、削除、追加、追加先、割り当て、共有
アクセスレベル：選択なし、ユーザ、部署、部署配下、組織全体
※「選択なし」は、アクセスレベルを設定しないと考えてください。

・レコード共有

レコード共有設定画面で、六つの特権を設定できます。
特権：読み込み、書き込み、削除、追加、共有

・フィールド共有

フィールド共有設定画面で、二つの特権を設定できます。
特権：読み込み、更新　
※更新は、書き込みと考えてOKです。

以上３つの設定画面から、アクセスレベルを定義できるのは、セキュリティロール設定画面だけであることが分かります。共有で特権を設定しても、アクセスレベル設定を漏れてしまうと、レコードをいじれません。
※レコード共有画面とフィールド共有画面では、特権の追加はできますが、特権の削除はできない見方もあります。

特定のレコードに対して、
・レコード共有で、読み込みと書き込みを
・セキュリティフィールドを、フィールド共有で読み込みと更新
と設定した場合に、書き込みできるようにするため、セキュリティロールで、書き込み特権をユーザ以上のアクセスレベルに設定することが必要です。

以上

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

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

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

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

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

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

よって、

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

ってことがわかります。

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

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

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

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

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

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

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

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

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

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

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

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


以上