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 の変更は無効化されることが多い

参考