ユーザー基準で gs.getUser()、gs.getUserID()、gs.getSession() などの GlideSystem オブジェクトを使用すると断続的な問題が発生するサービスポータルでフォームが「送信中...」のまま停止する。ユーザーはアクセス権のないカタログアイテムを表示でき、その逆も発生する。説明 お客様がサービスポータルでフォームを送信し、「送信中...」のまま停止する問題が断続的に生じます。この問題はごく少数のお客様のインスタンスで発生しており、この問題の正確な根本原因はまだ不明です。 問題を再現すると、開発者ツールのコンソールに 400 (要求が不正確) エラーが表示されます。展開すると、次のようなエラーメッセージが表示されます。「セキュリティ上の制約により、アイテムを注文できません (Security constraints prevent ordering of Item)」このメッセージは、次の Scripted REST リソース (sys_ws_operation) の 1 つから表示されます。1.Submit a Record Producer2.Buy Item上記の Scripted REST リソースの canView() が失敗しているようです。この問題のもう 1 つの症状として、お客様がアクセス権のないカタログアイテムを表示でき、その逆も発生します。 再現手順 この問題は、そのまま使用可能なインスタンスでは再現されていません。この問題に直面しているすべてのインスタンスに共通している構成は、影響を受けたカタログアイテムにスクリプト化されたユーザー基準が 1 つ以上あることです。 ユーザー基準には、gs.getUsedID、gs.getUser、gs.getSession などの GlideSystem オブジェクトがあります。この問題を引き起こす可能性のあるユーザー基準の例を次に示します。var udc=gs.getUser().getRecord().getValue('u_company_code'); //重要部分は gs.getUser() if (udc=="xyz"){answer = true;} else {answer = false;}この問題は、ユーザー基準が断続的にグローバルから sn_sc (サービスカタログ Rest API) にスコープを変更し、gs.getUsedID()、gs.getUser()、gs.getSession() などのセッションオブジェクトを未定義にすることが原因である可能性があります。 ワークアラウンド スコープ内で動作しない API は gs.getUser().getRecord() の 1 つだけで、これは予期される動作です。 しかし、ユーザー基準に sys_user レコードが必要なのはなぜでしょうか。 ユーザー基準で使用可能なフィールドが十分でなく、お客様が [sys_user] テーブルのフィールドをさらに必要とする場合は、ユーザー基準を拡張してください。 https://docs.servicenow.com/csh?topicname=t_ExtendUserCriteria.html&version=latest これにより、スクリプト化されたユーザー基準が作成されなくなります。 hr_profile のようにユーザー ID が必要なテーブルが他にある場合は、スクリプト化されたユーザー基準で gs.getUserID() またはセッション API を使用しないでください。 これを行うと、どの診断ツールでもユーザー基準の評価が中断されます。 ユーザー基準を評価するために使用されるユーザーを含む、利用可能なマジック変数「user_id」があります。これを、hr_profile の照会に使用してください。 スコープ指定のユーザー基準の場合、お客様に PRB1353133 が表示される可能性があり、その KE にワークアラウンドが掲載されています。 関連する問題:PRB1319258