バージョンはXanaduです。
ServiceNowのACL改修を初めて経験したのでメモ。
お客さんからの要望
今までA社だけで利用していたシステムに、B社、C社のユーザーを追加したい。ただし、B社はB社だけのレコードを、C社はC社だけのレコードを閲覧可とする。A社は全レコードを無条件で閲覧可とする。
最初にやってしまった誤った改修
お客さんからの要望を受け、以下のように改修しました。
①OOTBのテーブルread ACLを すべて非アクティブ化
②要望通りのテーブルread ACLを新規作成
何が問題だったのか？
改修後に動作確認してみて気になったことがありました。
自分で起票したレコードが、起票した瞬間に閲覧不可となる場合があったのです。
例：会社Bのユーザーが会社Cのレコードを起票するパターン
この時点の改修では閲覧制御は以下のようになっていました。
| ユーザー | ユーザーの所属会社 | レコードの会社 | 閲覧可否 |
|---|---|---|---|
| 会社Aのユーザー | 会社A | 会社A | 〇 |
| 会社Aのユーザー | 会社A | 会社B | 〇 |
| 会社Aのユーザー | 会社A | 会社C | 〇 |
| 会社Bのユーザー | 会社B | 会社A | ✕ |
| 会社Bのユーザー | 会社B | 会社B | 〇 |
| 会社Bのユーザー | 会社B | 会社C | ✕ |
| 会社Cのユーザー | 会社C | 会社A | ✕ |
| 会社Cのユーザー | 会社C | 会社B | ✕ |
| 会社Cのユーザー | 会社C | 会社C | 〇 |
一見お客さんがやりたいことを実現できているようですが、 会社名を間違って起票してしまった場合、自分でレコードの修正 or 削除ができない という致命的な問題がありました。
あくまでユーザーの会社とレコードの会社が一致しているかのみを基準に設計したからです。
そもそもの考え方
今回のように複数社でシステムを利用したいという場合、特権をもたないB社ユーザーやC社ユーザーが他社のレコードを起票することはまずないということと、もしそのようなレコードが存在するならそれは誤起票である、ということにもっと早く気付くべきでした。
改修にあたって私が早々に非アクティブ化したOOTBのread ACLに答えがありました。
「自身が起票したレコードは無条件で閲覧可とする」read ACLが標準で用意されていたのです。
OOTBを尊重するということ
ServiceNowではOOTBをなるべく活かして開発しましょうという考え方があり、現在のプロジェクトでもOOTBを壊しすぎずそのまま使えるように、既存の業務フローとすり合わせながら開発してきました。OOTBの尊重はフローだけでなく、ACLにおいても大事な考え方でした。まずOOTBがどうなっているか、なぜOOTBではこのACLが用意されているのか、非アクティブ化する前によく検討する必要があったと思います。
最終的な改修
上記の問題を解消するため、最終的には以下のように改修しました。
①基準： 作成者が自身か
OOTBのテーブルread ACLの 「自身が起票したレコードは無条件で閲覧可とする」read ACLを除きすべて非アクティブ化
②基準： レコードの会社と自身の会社が一致するか
要望通りのテーブルread ACLを新規作成
余談
最初に問題に気付いたとき、「他の会社のレコードを起票すると起票した瞬間レコードを閲覧できなくなってしまいますが問題ありませんか」とお客さんに投げてしまい、無駄に悩ませてしまいました。
お客さんの要望の通りに改修するのではなく、システムとしてあるべき姿をまず考えて提案できるようになりたいですね...