リストフィルターの ACL エラー:「読み取りセキュリティルールのため、インシデントのクエリの一部が無視されました」Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事では、プラットフォームリスト、リストレポート、およびルックアップリストのリストクエリで観測された、新たに浮上した問題のシナリオについて詳しく説明します。これは、実際には最新の ACL 動作の変更に関連しています。 背景： 以前は、ユーザーがフィルター内のフィールドにアクセスできない場合でも、ユーザーがフィールドを持つテーブルでクエリを作成できるようにしました。 たとえば、次のような incident.list のフィルターを考えてみましょう。つまり、Caller.User ID = alex.ray です。ここで、ユーザー「Beth.Anglin」がフィルター「Caller.User ID = Alex.Ray」を使用して上記のリストにアクセスしているとします。「Beth.Anglin」はsys_userテーブルにアクセスできますが、「sys_user」にはアクセスできないとします。User ID」フィールドでも、クエリ内のフィールドではなく、クエリ結果の出力のみが ACL に適用されるため、結果は以下のようにレンダリングされます。 根本原因: これにはセキュリティ上のリスクが伴います。フィールドへのアクセス権を持たないユーザーがリスト内のこれらのフィールドでフィルタリングを試みると、アクセス権のない詳細情報が悪用される可能性があります。 To address は Washington リリースで修正されPRB1716537 Utah/Vancouver の最新パッチにバックポートされました。この結果、顧客が Washington/Xanadu リリースにアップグレードしたり、最新の Vancouver パッチに移行したりすると、以前に機能していた同じリストクエリが次に示すように中断され、「incident.caller_id.user_name の読み取りセキュリティルールが原因で、インシデントのクエリの一部が無視されました」というエラーが発生します。 ソリューション： この問題を軽減するには、それぞれのテーブルとフィールドを使用して新しい query_range/query_exact タイプの ACL を作成する必要があります。 query_exact → ユーザーが一致クエリ ("is"、"is not"、"is empty" など) を送信できるようにします。query_range → ユーザーは範囲クエリ (「次で始まる」、「次で終わる」、「は次の値を含む」など) を送信でき、ソートは制限されません。詳細については、以下のドキュメントを参照してください。 ACL ルールのタイプ - ACL ルールの作成クエリ ACL:詳細なアクセス制御 さらに、以下のプロパティを作成して false に設定することで、このエラーメッセージを非表示にすることができます。 名前:glide.db.encoded_query.field_acl_error_msg タイプ:true |偽 値：false