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

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

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

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

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

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

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

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

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

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

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

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

以上

レコードの所有者であるユーザとチームの違い

1.レコード所有者の基本

エンティティの属性である「企業形態」を「ユーザまたはチーム」に設定した場合に、「所有者」というフィールドが自動的に作成されます。

所有者はレコードの所有者のことです。ユーザまたはチームになります。デフォルト所有者はユーザです。また、部署は「既定のチーム」として、レコードの所有者に設定できます。

レコードの所有者と、所有者の部署を使い合わせて、エンティティへのアクセスレベルを5段階で構成できます。
・選択なし、ユーザ、部署、部署配下、組織全体

逆に、レコードに所有者がない場合、エンティティへのアクセスレベルは2段階でしか構成できません。
・選択なし、組織全体

2.所有者をチームにする場合の注意点

データを新規登録するとき、デフォルトの所有者はログインユーザになっているので、ログインユーザのチームに書き換えると、カスタマイズが必要です。

このため、以下運用的な協力も必要です。
・ユーザを事前にチームに登録しておく
・同じユーザを複数のチームに登録した場合、どのチームをデフォルト所有者にするのかを決めておく

また、ユーザとチーム両方に、セキュリティロールを設定しなければいけません。
データの閲覧にログインユーザの権限が聞かれます。データを保存するときに、所有者であるチームの権限が求められます。

3.所属異動と組織変更への対応

所有者がユーザ、チーム別に、所属異動時と部署統廃合時に必要な処理を下表に纏めています。

レコードの割り当てはエンティティ毎に行うので、エンティティ数とデータ量の多い場合、大変な操作になります。

よって、部署統廃合が多い組織では、所有者をユーザに、所属異動の多い組織では、所有者をチームにすると検討してはいかがでしょうか。

以上

複数の部署を動的に検索する

まず、検索条件を動的に設定できる項目を確認します。

1.個々のエンティティに存在する動的検索可能項目および条件

2.個々のエンティティから、関連エンティティ経由で設定できる動的に検索可能項目および条件

上記2つの表が示すように、ログインユーザの所属部署を動的に、検索条件に追加できます。
Dynamicsでは、ユーザはただ一つの部署に所属するので、一つの部署だけ、検索条件に追加できることも分かります。

ここで、部署とチームをフルに活用して、複数の部署を動的に検索する方法を紹介します。

まず、下図のように、組織を構成します。

この組織構造を説明します。
・ユーザをチームに所属させます。Dynamicsでは任意ですが、ここでは必須です。
・ユーザを部署に所属させます。Dynamicsでは必須です。
・チームを部署に所属させます。Dynamicsでは必須です。
・Dynamicsのチームを実務の中の部署として使います。

更に、レコードの所有者(OwnerId)はチームとします。

こうすると、ユーザ、組織、データの関係は次のようになります。

最後に、
ビューのフィルター条件で、「所有チーム（チーム）の部署が現在の部署に等しい」と設定します。

チームを部署と見直せば、複数部署を動的に検索できるようになったと思いませんか。

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上

エンティティ関連付けのデータ構造 （N：N）

二つのエンティティに、N：N関連付けを作成すると、関連情報を格納する「関連エンティティ」が自動的に作成されます。

関連エンティティを画面経由でアクセスできません。データベースを直接確認すると、以下４列で構成されいることがわかります。
・.一つ目のエンティティのレコードID
・二つ目のエンティティのレコードID
・システムユーザID
・バージョンナンバー

N対Nの関連を持つ部署と従業員を例に、N：N関連付けの作成画面を確認します。

関連エンティティ名項目が設けられていることから、エンティティが作成されていることがわかります。表示オプションは、フォームナビゲーションに、相手エンティティのサブグリッド画面に遷移するリンクを表示するかどうかの選択です。

Dynamicsでは、エンティティ間の関連付けを確認しやすいように、N：N関係を持つエンティティのどちらからでも、関連付を確認できます。

関連エンティティに、N：N関係を持つ二つのエンティティのレコードID（外部キー）を格納します。データの追加と削除は次のタイミングで行われます。

例の部署と従業員を用いて説明すると、
・部署に、従業員を追加、または削除するとき
・従業員に、部署を追加、または削除するとき

１：N関連と違って、部署データまたは従業員データを新規作成するとき、相手データと関連付けできません。必ずデータを作成してから、追加する形で、関連付けしなければいけません。

また、部署から、従業員を削除すること、または従業員から部署を削除することは、関連エンティティのデータを削除することです。決して従業員、または部署そのものを削除するわけではないことを理解すれば、N：Nの関連付けは理解できていると思います。

エンティティ関連付けのデータ構造 （１：N）

「１：N」関連付けを理解するには、「関連名」と「検索フィールド」を抑えればいいと思います。

一つのエンティティに、複数の関連付けを追加できます。関連付けを識別するのに、関連名を使います。Dynamicsでは、親エンティティからでも、子エンティティからでも関連を確認できます。親エンティティから見た「１：N」の関連は子エンティティから見たN：１の関連になります。

検索フィールドは、子エンティティ側が持ちます。親エンティティのレコードID（外部キー)を格納します。

下図は、親エンティティにて、「１：N」関連付けを作成する画面です。

主エンティティが「親」、関連エンティティが「子」なので、親からみて、子と１：Nの関連を持ちます。
この画面に、検索フィールドを設定するので、「親」エンティティに検索フィールドを追加すると誤解しがちですが、検索フィールドは子エンティティに作られることを理解するのが肝心です。

関連名は親からも、子からも確認できる画面を見てみましょう。
下記画面が示している通り、「new_new_oya_new_ko」という関連名は親にも子にもあります。

関連付けと検索フィールドはセットで作られますが、検索フィールドは子エンティティにあることを次の画面で確認できます。

では、子が持っている検索フィールドに、値（親のレコードID）がいつ格納されるのでしょうか。タイミングは二つあります。

一つは、親のフォームナビゲーションから、子を作成するとき、親のレコードIDが自動的に、子が持つ検索フィールドに入ります。

子のフォーム画面に、検索項目を設置しなくても、親のレコードIDが入ります。これは、上記手順で子データを作ると、親から子へのマッピングが動作しているからです。
※マッピングは関連付けを作成するときに、自動的に作られます。

もう一つは、子のフォーム画面に、検索フィールドを設置します。検索入力するときに、親のレコードIDが入ります。



アプリケーションナビゲーションから、子データを作成すると、親画面を経由しないので、マッピングが動作しません。しかし、検索項目を画面に設置することによって、親レコードIDをいつでも追加または削除できます。


最後に、子データの表示を考えます。

アプリケーションナビゲーションから、子エンティティ一覧を表示する場合、親に関わらす、すべての子データを一覧表示できます。

親のフォームナビゲーションから、子データを一覧表示する場合、検索フィールドを、表示中の親のレコードIDで検索し、一致するものだけ表示することになります。

以上

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

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

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

・セキュリティロール

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

・レコード共有

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

・フィールド共有

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

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

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

以上