ドメイン分離できないテーブルについて

d-aizawa
Kilo Sage

コミュニティの皆様

いつもお世話になっております。

 

ドメインセパレーションについて、導入を検討しているため調査しています。

ドメイン分離できないテーブルについて、

公式ドキュメント等を参照し

以下テーブルは、ドメイン分離できない認識です。

・Access Control

・Script Include

・System Property

・Security Exclusion/Inclusion List Entities

・Dictionary Entry

・Dictionary Entry Override

 

他にドメイン分離できないテーブルがありましたら、
ご教示頂きたいです。

1 ACCEPTED SOLUTION

Community Alums
Not applicable

Hi @d-aizawa ,

ほぼすべてのテーブルをドメインで分離できますが、(ご指摘のとおり) 一部のテーブルはドメイン分離できません。 貼り付けたリスト (およびドメイン分離 wiki で繰り返されている) は、ドメイン分離を強制するとインスタンスの機能が著しく損なわれる可能性があるテーブルです。

 

sys_domain フィールドを追加して、テーブルにドメイン分離を追加します。 これはウィキでも指摘されています。 sys_domain フィールドを持つテーブル (または、sys_domain フィールドを持つ拡張モデル チェーンの親のテーブル) は、ドメインで区切られています。 たとえば、インシデント、変更リクエスト、および問題は、共通の親であるタスクに sys_domain フィールドがあるため (プラグインがアクティブ化されている場合)、ドメインが分離されています。

 

ドメインで分離するカスタム テーブルがある場合は、sys_domain フィールドをテーブルに追加します。

 

ドメインの分離を扱うときは、常に最初に非本番インスタンスでテストしてください。 ドメイン分離プラグインを実際に非アクティブ化することはできないため、本番環境にロールアウトするときに何をしているのかを確認する必要があります。 これは、最初に非本番インスタンスで検証することによって行います。 追加のテーブルにドメイン分離を追加して実験する場合は、最初に非運用設定で実行し、必要な結果が得られることを確認するために全体をテストします。

 

ドメイン分離は、レコード アクセスを管理するための非常に強力なツールです。 ドメインを変更したり、テーブルにドメイン分離を追加したりするときは、変更の範囲を理解する必要があります。そうしないと、インスタンスが非常に使いにくくなる可能性があります。

ベストプラクティスが必要な場合は、
プラグイン自体でドメイン分離されていないテーブルをドメイン分離しないでください。

あなたが言及したテーブルに加えて、カタログアイテムはドメイン分離されていません

これらはユーザー基準によって制御されます。

テーブルにファイルされた sys_domain は、テーブルがレコード用にドメインで区切られていることを示します。

テーブルの sys_domain フィールドとともに sys_overrides フィールドは、テーブルがプロセスの分離を目的としていることを示します。 ビジネス ルール テーブルとクライアント スクリプト テーブルは、プロセス分離テーブルの例です。

ドメイン構造は Global> Top> domain1, domain2, domain3 です。 ここで、Top は親ドメインで、domain1、2、3 は並行する子ドメインです。 問題は、sys_domain 列を持たないテーブルがかなりあることです (本質的にドメインが分離されていません)。 これらのテーブルのいくつかは -

cmn_cost_center
cmn_department
cmn_location
core_company
core_country
sys_user_delegate
sys_user_geo_location
sys_user_grmember
sys_user_group
sys_user_group_type
sys_user_has_license
sys_user_has_role
sys_user_license_exclude
sys_user_license_source
sys_user_pending_license
sys_user_preference
sys_user_presence
sys_user_role
sys_user_role_contains
sys_user_session
sys_user_set
sys_user_token

 

 

View solution in original post

1 REPLY 1

Community Alums
Not applicable

Hi @d-aizawa ,

ほぼすべてのテーブルをドメインで分離できますが、(ご指摘のとおり) 一部のテーブルはドメイン分離できません。 貼り付けたリスト (およびドメイン分離 wiki で繰り返されている) は、ドメイン分離を強制するとインスタンスの機能が著しく損なわれる可能性があるテーブルです。

 

sys_domain フィールドを追加して、テーブルにドメイン分離を追加します。 これはウィキでも指摘されています。 sys_domain フィールドを持つテーブル (または、sys_domain フィールドを持つ拡張モデル チェーンの親のテーブル) は、ドメインで区切られています。 たとえば、インシデント、変更リクエスト、および問題は、共通の親であるタスクに sys_domain フィールドがあるため (プラグインがアクティブ化されている場合)、ドメインが分離されています。

 

ドメインで分離するカスタム テーブルがある場合は、sys_domain フィールドをテーブルに追加します。

 

ドメインの分離を扱うときは、常に最初に非本番インスタンスでテストしてください。 ドメイン分離プラグインを実際に非アクティブ化することはできないため、本番環境にロールアウトするときに何をしているのかを確認する必要があります。 これは、最初に非本番インスタンスで検証することによって行います。 追加のテーブルにドメイン分離を追加して実験する場合は、最初に非運用設定で実行し、必要な結果が得られることを確認するために全体をテストします。

 

ドメイン分離は、レコード アクセスを管理するための非常に強力なツールです。 ドメインを変更したり、テーブルにドメイン分離を追加したりするときは、変更の範囲を理解する必要があります。そうしないと、インスタンスが非常に使いにくくなる可能性があります。

ベストプラクティスが必要な場合は、
プラグイン自体でドメイン分離されていないテーブルをドメイン分離しないでください。

あなたが言及したテーブルに加えて、カタログアイテムはドメイン分離されていません

これらはユーザー基準によって制御されます。

テーブルにファイルされた sys_domain は、テーブルがレコード用にドメインで区切られていることを示します。

テーブルの sys_domain フィールドとともに sys_overrides フィールドは、テーブルがプロセスの分離を目的としていることを示します。 ビジネス ルール テーブルとクライアント スクリプト テーブルは、プロセス分離テーブルの例です。

ドメイン構造は Global> Top> domain1, domain2, domain3 です。 ここで、Top は親ドメインで、domain1、2、3 は並行する子ドメインです。 問題は、sys_domain 列を持たないテーブルがかなりあることです (本質的にドメインが分離されていません)。 これらのテーブルのいくつかは -

cmn_cost_center
cmn_department
cmn_location
core_company
core_country
sys_user_delegate
sys_user_geo_location
sys_user_grmember
sys_user_group
sys_user_group_type
sys_user_has_license
sys_user_has_role
sys_user_license_exclude
sys_user_license_source
sys_user_pending_license
sys_user_preference
sys_user_presence
sys_user_role
sys_user_role_contains
sys_user_session
sys_user_set
sys_user_token