追記(2026/4/25)
Patchが当たったのかWorkspaceでもACL拒否時のエラーが表示されるようになっていました。
追記(2026/3/14)
PDIで触っていると上記の処理ではHeading 1コンポーネントのラベルがちらつくことが分かりました。
他の方法が分かったらまた修正致します。
はじめに
WorkspaceでACL拒否された時に白いページが出るのでその対処方法を調べました。
PDI環境
試したPDI環境はこんな感じです。
Version: Zurich
検証
この記事で作成したワークスペースを使って検証します。
まずはテスト用のユーザーを作成します。
新しくtest.taroさんを作成します。
この時点でまだワークスペースのロールは付与せずにいます。
ユーザーが作成出来たらなりすますしをして、ワークスペースにアクセスしてみます。
ロールを付与していない状態だとSecurity constraints prevent access to requested pageという権限エラーが表示されます。
次にロールを付与し、ACLで拒否してみます。
まずはワークスペースの一般ロールをtest.taroさんに付与します。
Workspace側にAudience設定をしていなかったのでそれも作成します。
LogTestApp用の一般ユーザーロールとadminロールをAudienceに登録します。
この設定でワークスペースの一般ロールを付与されているtest.taroさんでもを見ることが出来るようになります。
次にACLの設定をしたいのでsecurity_adminに昇格します。
ここでは標準で作成された一般ロールユーザー用のACLにPriority:1-Critical以外のデータであればアクセス可能となる設定を追加します。
現状のACLは以下のようになります。
| Priority | x_1603370_logtes_0_user | x_1603370_logtes_0_admin |
|---|---|---|
| 1 - Critical | ❌ 参照不可 | ⭕ 参照可能 |
| 2 - High | ⭕ 参照可能 | ⭕ 参照可能 |
| 3 - Moderate | ⭕ 参照可能 | ⭕ 参照可能 |
| 4 - Low | ⭕ 参照可能 | ⭕ 参照可能 |
| 5 - Planning | ⭕ 参照可能 | ⭕ 参照可能 |
検証用に各Priorityの値を変えたレコードを作成しておきます。
test.taroさんになりすましをしてワークスペースにアクセスします。
https://dev202820.service-now.com/x/1603370/logtestapp/record/x_1603370_logtes_0_logtesttable/7454246a83753e10678dfbb6feaad36c
Listを見ると全体5件ですが、ACLによってPriority:1-Criticalのレコードは参照できないので4件のみ表示されています。
直接Priority:1-CriticalのレコードURLをブラウザにペーストしてアクセスするとロールを持たない時のようにアクセス拒否の画像やメッセージが出てほしいのですが、以下のように真っ白な画面だけ表示されます。
今回はこの真っ白なページに何らかの画像やメッセージを表示できるようにしていきたいと思います。
ちなみにPlatform側のURLで該当のレコードにアクセスするとロールを持っていない時と同じような表示がされます。
ACL失敗時にメッセージを表示する
標準的な方法でやりたかったのですが調べてもよくわからず、とりあえず実現出来た方法を1つ紹介します。
今回は検証してないですが、UIBuilderのeventを組み合わせればポップアップとかも出せるかもしれません。
1.Security constraintsコンポーネントを修正する
Workspace作成時、RecordのPageにWarning Messages Containerが自動で作成されているのですが、
これがうまく動いていないのか良くわからないですが、Security constraints prevent access to requested pageというロールを持っていない時に表示されるメッセージのラベルがあります。
Component Visibilityで普段はHideされているようなので、ACL却下時にこれを表示してあげればいいのかなと考えました。というか表示されていないのがおかしい？よくわかりません。
中の条件を見てみるとなんとなく以下のような条件で表示/非表示が切り替えられているようです。
| パターン | isValid | canRead | 式の結果 | コンポーネントの状態 |
|---|---|---|---|---|
| ① ロード中 / 空 | null | (不問) | True | 非表示 (Hidden) |
| ② 無効なデータ | false | (不問) | True | 非表示 (Hidden) |
| ③ 権限あり | true | true | True | 非表示 (Hidden) |
| ④ 権限なし | true | false | False | 表示 (Visible) |
何故これでACLが拒否された時に表示されないのかわかりませんが、仕方ないので一つ条件を追加します。
|| ((@data.record.isValid == true) && (@data.record.acl.canRead == false))
全体の条件にORを追加し、isValid==trueかつcanRead==falseの時に表示します。
これでsaveして、test.taroさんになりすまし、アクセスできないレコードを開いてみます。
まだ真っ白です。
saveした条件を見てみると、思っていた感じになっていないようです。
元の条件と追加した条件がどちらもFalseにならないと表示されないになっていました。
(((((@data.record.isValid != true) && (@data.record.isValid != false)) || (@data.record.isValid == false)) || ((@data.record.isValid == true) && (@data.record.acl.canRead == true))) || ((@data.record.isValid == true) && (@data.record.acl.canRead == false)))
仕方がないのでコンポーネントをもう一つ増やして対応します。
Security constraintsコンポーネントをDuplicateで複製します。
Heading 1というコンポーネントが出来るので、その条件をシンプルにcanReadだけにします。
これでsaveして、test.taroさんになりすまし、アクセスできないレコードを開いてみます。
Heading 1コンポーネントのラベルが出ました。
真っ白になっているのはZurichのバグ？なのでしょうか。
一応、これでメッセージとかは表示できそうです。
画像も同じようにコンポーネント条件で付けてあげれば、ロールがない時に表示される状態と同じ表示の仕方が出来ると思います。
終わりに
仕様なのか不具合なのか不明ですが、Workspaceにて権限不足の場合にエラーメッセージを表示する方法を調べました。
標準的にACL不足時はメッセージを出してくれるのだとは思いますが、更にカスタマイズ・ユーザビリティの高い表示をしたい場合は今回の検証が役に立つこともあるかもしれません。
いつかのどなたかの参考になれば幸いです。
参考URL
以下のURLを参考にしました。有益なサイト達に感謝します。