Record Producer １０：表示項目における状態の優先度について【ServiceNow】

※この記事はServiceNow初心者が学習用のために記載した記事です。内容について誤っている場合がございます。不足点などございましたらコメントいただけますと幸いです。

# 表示項目の状態における優先度
- Record Producerにおける、表示項目の状態について、適応される優先度がある
- フィールドの状態 (必須、表示、読み取り専用) について記載する
- 数字が小さいほど優先度は高い

### 1.ACL (Access Control List)
- 優先度: 🔥最優先（1位）
- 役割: アクセス権を管理し、フィールドの表示や編集を制御
- 影響:
    - read ACL → フィールドの表示/非表示を制御（アクセスできない場合は完全に非表示）
    - write ACL → 編集の可否を制御
    - create ACL → レコード作成時の編集可否
- 例:
    - "admin" 以外のユーザーには vip_status フィールドを非表示
    - "IT Support" ロールを持っている場合のみ issue_details を編集可能
- 影響範囲: フォーム全体に適用（制約が厳しい）
- ✅ Data Policy のほうが UI Policy より強力！
- ✅ Data Policy はサーバーでも適用されるため、UI Policy では変更できない！
- ✅ UI Policy はクライアントサイドのみなので、Data Policy のルールがあれば従うしかない！

### 2.Dictionary Entry
- 優先度: 🟠高（2位）
- 役割: フィールドのデフォルトのプロパティを定義
- 影響:
    - Mandatory → フィールドを必須にする
    - Read-Only (Disabled) → デフォルトで編集不可
- 例:
- category は常に必須 (Mandatory = true)
- created_by はデフォルトで編集不可 (Read-Only = true)
- 影響範囲: 全フォームに適用（変更しない限り固定）
- ✅ ACL の制約がある場合、Dictionary Entry の設定は適用されない（ACL > Dictionary）

### 3.Data Policy as UI
- 優先度: 🟡中（3位）
- 役割: サーバーサイドでのデータ検証（UI にも影響）
- 影響:
    - Mandatory → 必須フィールドの強制
    - Disabled → フィールドを編集不可にする
- 例:
    - レコードを保存する際に resolution_notes を必須
    - 保存前に state="Closed" の場合 closure_code を必須
    - 影響範囲: フォーム & サーバーで適用（フォームだけでなく API やインポートにも適用される）
- ✅ UI Policy の変更は Data Policy の強制を無視できない
- ✅Data Policy はサーバー側でも適用されるため、UI Policy より強力


### 4.UI Policy
- 優先度: 🟢中（4位）
- 役割: 特定の条件に基づいて UI の挙動を変更
- 影響:
    - Mandatory → 条件によって必須にする
    - Visible → 条件によって表示/非表示を切り替え
    - Disabled → 条件によって編集不可にする
- 例:
    - state="Closed" の場合、resolution_notes を必須
    - category="IT Support" のときだけ sub_category を表示
- 影響範囲: クライアントサイド（フォーム上）でのみ動作（サーバー側には影響なし）
- ✅ ACL や Dictionary Entry によって制限されている場合、UI Policy では上書きできない


### 5.Client Script 
- 優先度: 🔵低（5位）
- 役割: 動的なスクリプトで UI の振る舞いを制御
- 影響:
    - Mandatory → スクリプトで必須設定を変更
    - Visible → スクリプトで表示/非表示を切り替え
    - Disabled → スクリプトで編集不可にする
- 例:
```
if (g_form.getValue('category') == 'IT Support') {
    g_form.setMandatory('sub_category', true);
}
```
- 影響範囲: クライアントサイドでのみ動作（フォーム上のみ適用）
- ✅ ACL や Dictionary Entry による制限がある場合、Client Script では変更できない

---

通常、優先順位（ACL → Dictionary Entry → UI Policy → Data Policy → Client Script）は変わらないが、設定や環境によって逆転するケースはある

# 逆転する可能性があるケース
### ① Dictionary Entry より UI Policy や Client Script が優先される場合
📌 ケース：Dictionary Entry で Read-Only なのに、UI Policy や Client Script で編集可能になる

- 原因: Dictionary Entry で Read-Only に設定していても、UI Policy や Client Script で g_form.setReadOnly('field', false); を実行すると、画面上では編集可能になる
- 制約: ただし、これは 画面上の制御だけで、保存時には適用されない（サーバー側での制約があると無効）
- 例:
    - created_by を Dictionary Entry で Read-Only にしている
    - UI Policy で g_form.setReadOnly('created_by', false); 
- 設定
    - 画面上では編集可能になるが、保存時には制限される


### ② UI Policy が Data Policy より強くなる場合
📌 ケース：UI Policy で「非表示」にすると、Data Policy の必須ルールが無効になる

- 原因: UI Policy で g_form.setDisplay('field', false); を設定すると、そのフィールドは 完全に非表示 になり、Data Policy の Mandatory ルールが機能しなくなる
- 制約: ただし、API 経由でデータを送信すると Data Policy が適用されるため、完全に無効にはならない
- 例:
    - Data Policy で comments を必須
    - UI Policy で g_form.setDisplay('comments', false);
    - フォーム上では「必須チェック」が無効になる（ただし API では適用）

✅ 対策:
UI Policy で Visible を変更するのではなく、Mandatory を false にしておくと Data Policy の影響を受けにくくなる

### ③ ACL の制限を UI Policy や Client Script で回避できる場合
📌 ケース：Client Script で g_form.setDisplay('field', true); しても、ACL によって制限されるとは限らない
- 原因: ACL で 「読み取り不可」 に設定している場合でも、クライアントスクリプトで setDisplay(true) を使うと画面上では表示できることがある。（ただしデータの取得はできない）
- 例:
    - ACL で vip_status を read 権限なし
    - Client Script で g_form.setDisplay('vip_status', true); を実行
    - 画面上では項目が見えるが、データは表示されない

✅ 対策:
完全に制限するなら ACL だけでなく Business Rule や Server Script を使って制御 する

### まとめ
✅ 通常の優先順位は変わらないが、設定次第で UI Policy や Client Script が一時的に強く見えることはある
✅ サーバー側（Data Policy, ACL）が関わると、最終的には UI Policy や Client Script の変更は無効化されることが多い

# 参考
https://www.servicenow.com/community/itom-forum/hierarchy-of-client-script-ui-policy-and-business-rule-and-acl/m-p/1028702