サービスポータルのリダイレクトを設定する方法Issue この記事では、ログイン後のユーザーに対してサービスポータルのリダイレクトを設定する手順について説明します。この記事の「手順」セクションで概説されている手順に従うか、このビデオに従ってください。 ユーザーがログインする場所を構成する方法については、次の記事を参照してください: Service Portal をインスタンスのログインページとして設定する方法。このトピックについて、以下に記載されていない追加の質問がある場合は、このテーマに関する FAQ ナレッジ記事を参照するか、上のビデオをご覧ください。 このリダイレクトは、ログインルールやインストール終了など、いくつかの異なる方法を使用して設定されるのがプラットフォームにおける慣例でした。サービス ポータルへのリダイレクトが図に含まれている場合は、これらの古いメソッドを削除し、プライマリ構成を SPEntryPage スクリプト インクルードで処理する必要があります。 手順 システムプロパティ glide.entry.first.page.script を作成または更新します。 これは既に存在している場合もありますが、多くの場合は、文字列型のプロパティとして作成する必要があります。SPEntryPage スクリプトを呼び出すには、必ず値を new SPEntryPage().getFirstPageURL() に設定してください。 ベースシステムでは、これは、ユーザーが何らかのロールを持ち、サービスポータルに直接アクセスしようとしていないかどうかを確認するように設定されます。両方が合格すると、glide.login.home プロパティの値またはログイン前にロードしようとしていたページにユーザーを送ります。 ユーザーにロールがない場合、ユーザーは、サービスポータルのそのページに相当するページに送られます 例えば、 https://<instance_name>.service-now.com/nav_to.do?uri=change_request_list.do これは、ロールのないユーザーを次のページに送ります。 https://<instance_name>.service-now.com/sp/?id=list&table=change_request 特定のニーズに対応するように SPEntryPage スクリプトインクルードを構成します。注：これには、ベースシステムコードのカスタマイズが必要です。 このガイドを参考にそのようなカスタマイズを行うことができますが、上記以外の構成はサポート対象外となります。 SPEntryPage スクリプトの 69 行目と 70 行目で ユーザーをリダイレクトするかどうかを決定します。デフォルトでは、ユーザーにロールがあり、既存のリダイレクト URL (login_redirect) がなく、ユーザーがサービスポータルに移動しようとしていない場合、スクリプトは戻ってきます。つまり、ユーザーはリダイレクトされません。この機能をカスタマイズするには、この機能を変更する必要があります。次の 2 つのチェックはそのままにしておくと、既存の機能が壊れる可能性があります。user.hasRoles チェックは、変更できる唯一の部分です。たとえば、特定のロールを持つユーザーをデフォルトでプラットフォーム UI に移動させる場合は、条件を次のように変更できます。 if(user.hasRole("my_cool_role") && !redirectURL && !isServicePortalURL) Related Linksこのリダイレクトを設定する際に考慮すべき点がいくつかあります。 spEntryPage の目的は、2 つあります。1 つ目はユーザーはどこにログインするか、2 つ目はログインが終わった後、どこに移動するかです。これは、ユーザーがプラットフォームの UI にアクセスするのを完全に防ぐことを意図しているわけではありません。 他の既存のリダイレクトロジック (ログインルール、インストールの終了など) がある場合、このロジックと競合し、意図しない結果につながる可能性が高くなります。admin ロールを持つユーザーは、特定のロールを持っているかどうかに関係なく、常に hasRole チェックに合格します。そのため、特定のロールを持つユーザーをチェックするために、SPEntryPage をカスタマイズする場合は注意が必要です。実際には、複数のポータル間でリダイレクトする方法はサポートされていません。これは単一のポータル構成を想定しています。 このトピックの詳細については、リダイレクトに関する FAQ を参照してください。