スコーピング/HR ロールに関する FAQIssue はじめに このドキュメントの目的は、HR プラグインとそれらに含まれるスコープ対象ロールのコンテキストでのスコーピングに関するベストプラクティスとよくある質問を定義することです。スコープ指定のロール、構成、スコーピングのベストプラクティスについて、かなりの数の質問をいただいています。このドキュメントには、必要に応じて他のドキュメントへのリンクも含まれています。 まず、スコーピングにかなり慣れていない場合、これは概念を大まかに説明する素晴らしいコミュニティ記事です。このドキュメントの残りの部分のコンテキストに適した背景を提供するため、最初にこれを読んでください。 Now Platform のアプリケーションスコープについて Human Resources Service Management アプリケーションの最新のプラグインは、すべて個別のスコープ対象のアプリケーションとして実装されています。各スコープ対象のアプリケーションには「スコープ対象のアドミン」ロールがあり、このロールを持つすべてのユーザーにコンポーネントのアドミン権限を許可します。これはプラグインとロールのリストです。 HR プラグインとスコープ対象ロールの概要 プラグイン名admin ロール ヒューマンリソース (HR) スコープ対象のアプリ:Core sn_hr_core.admin ヒューマンリソース (HR) スコープ対象のアプリ:サービスポータル sn_hr_sp.admin ヒューマンリソース (HR) スコープ対象のアプリ:統合 sn_hr_integration.admin ヒューマンリソース (HR) スコープ対象のアプリ:データ移行 sn_hr_migration.admin ヒューマンリソース (HR) スコープ対象のアプリ:ライフサイクルイベント sn_hr_le.admin ヒューマンリソース (HR) スコープ対象のアプリ:従業員ドキュメントファイル sn_hr_ef.admin ヒューマンリソース (HR) スコープ対象のアプリ:仮想エージェントの会話 sn_hr_va.admin 上記の各スコープ対象のアプリケーション/プラグインには、「スコープ対象のアドミン」または「指定された開発者」のみが付与できる独自のスコープ対象ロールのセットがあります。これは、スコープ対象ロールをユーザーに直接アサインすることによって付与されるか、スコープ対象ロールを含むグループにユーザーを追加することで付与されるかには関係ありません。HR プラグインの 1 つが最初にインストールされると、このスコープ対象の admin ロールが標準の「admin」ロールの子として追加されます。これにより、admin ロールを持つすべてのユーザーが、HRSM アプリケーションを管理するユーザーにこれらのスコープ対象ロールを付与できます。ユーザーに admin ロールと指定された開発者 (下記) が付与されると、スコープ対象のアプリケーションを完全に管理できるようになります IT 部門が人事データにアクセスできることを心配しないユーザーの場合、プラグインのインストール後は、標準システムアドミニストレーターがデフォルトでアプリケーションを完全に管理できます。HR スコープのセキュリティを強化するために、ほとんどのお客様は、指定された開発者を設定した後に「admin」ロールからスコープ対象ロールを削除することを望むでしょう。これにより、HR スコープ指定の管理者はアプリケーションを完全に制御できます。 委任開発者 ユーザーが上記のスコープ対象の admin ロールのいずれかを取得した後、スコープ内のコンポーネント (テーブル、ビジネスルール、スクリプトインクルードなど) を変更できるようにするには、そのユーザーに委任開発者のロールを付与する必要があります。これは非常に簡単で、このドキュメントで詳細を説明しています。 委任開発者を HR アドミニストレーターに追加 現在、委任開発者ロールを付与できるのはシステムアドミンのみであるため、アドミンロールからスコープ対象ロールを削除する前に行う必要があります。上記の手順は、スコープ対象の admin ロールに委任開発者を追加する場合に適用されます。 制限付き発信者アクセス もう 1 つよくある質問は、HR アプリケーションの使用時にエラーメッセージが表示されるユーザーからのものです。これらのエラーメッセージは、次のようなものです。 スコープ「ヒューマンリソース (HR):サービスポータル」からのテーブル「tablex」の読み取り操作が拒否されました。アプリケーションはクロススコープアクセス権限を宣言する必要があります」 これらは、特定のスコープ対象リソース (テーブル、スクリプトインクルードなど) が他のスコープへのアクセスを拒否するように設定されている場合に発生する可能性があります。これに対処するには、スコープ指定されたアドミニストレーターが制限付き発信者アクセスレコードを更新して、他のスコープがアクセスできるようにする必要がありますsys_restricted_caller_access。これを行う方法に関するより具体的な情報は、公式ドキュメントに記載されています。 アプリケーション制限付きの申請者アクセス設定アプリケーションリソースへのクロススコープアクセスの定義アプリケーションスコープに対するアクセスまたはアプリケーションスコープからのアクセスの定義 制限付き発信者アクセスエラーを修正する方法について説明する優れたコミュニティブログ: 赤いポップアップを修正する方法「...Must declare a cross scope access privilege」エラー HR ロール HR ロールの主な目的は、HR 組織外のユーザーが HR データにアクセスできないようにすることです。 いくつかの重要なポイントは次のとおりです。 スコープ対象の HR ロールを持たないユーザーは、HR ケースまたは HR プロファイルの情報を表示できません。スコープ対象の HR ロールは、sn_hr_core.admin ロールを持つユーザー、またはスコープ対象の HR ロールのアサイン可能者ロールを持つユーザーがアサインできます。これは、スコープ対象ロールがユーザーに直接アサインされているか、スコープ対象ロールを含むグループにユーザーが追加されているかに関係なく適用されます。デフォルトでは、システムアドミンロール (admin) には HR アドミンロール (sn_hr_core.admin) が含まれています。HR アドミンロールのみが機密情報にアクセスできるようにシステムを構成してください。HR admin ロールを必要なユーザーにアサインした後、システムアドミンが機密性の高い HR 情報を表示できないように、システムアドミンロールから HR admin ロールを削除します。 注意:HR アドミニストレーターロールを持つユーザーが少なくとも 2 人いることを確認してください。このロールを 1 人のユーザーにのみアサインすると、そのユーザーが非アクティブ化された場合に、人事管理者の職務を遂行できるユーザーがいなくなります。 IT IT システム管理者から人事管理者ロールを削除するを参照してください。同様に、上記は sn_hr_le.admin ロールにも適用されます。少なくとも 2 人のユーザーにこのロールを追加したら、このロールをシステムアドミニストレーターロールから削除する必要があります。システムアドミニストレーターは HR アドミンの代理操作はできますが、HR 関連の操作はできません。 このドキュメントでは、人事ロールの管理方法について説明されており、多くの有用な情報があります。 HR ロールの管理 以下のドキュメントには、ケースとナレッジ管理とともにインストールされるロールがリストされています。 ケースとナレッジ管理とともにインストールされるロール FAQ Q: スコープ対象のロールをユーザーに付与できないのはなぜですか? A: すべてのスコープ対象のアプリケーションロールを割り当てることができるのは、スコープ対象の admin ロールを持つユーザーか、スコープ対象ロールのアサイン可能者ロールを持つユーザーのみです。また、スコープ対象ロールに別のスコープ対象ロールが含まれている場合、ユーザーはこの含まれているスコープ対象ロールのアサイン可能者ロールも持つ必要があります。 Q: グローバル ACL はスコープ対象のアプリケーションで適用されますか。ユーザーテーブルにクエリーを実行するスコープ対象のアプリケーションがある場合、そのテーブルのグローバル ACL は機能しますか? A:現時点ではありません。グローバル ACL は、スコープ対象のアプリケーションの別の ACL にコピーする必要があります。 Q: グローバルスペースで呼び出すことができるすべての API とプラットフォームスクリプトインクルードを引き続き呼び出すことはできますか? A: いいえ、プラットフォームがスコープ対象のアプリケーションの呼び出しを許可する API の「包含リスト」があります。この包含リストは、次にあります。 API リファレンス サーバー側のスコープ対象 Q: スコープ対象のロールまたはスコープ対象のロールがユーザーに付与された後に有効にならないのはなぜですか。 A: ユーザーは、ロールを付与された後にログアウトし、再度ログインする必要があります。 Q: ネイティブのケース作成 UI ページ (sn_hr_core_case_creation.do) に一部の人事サービスまたは COE テーブルが表示されないのはなぜですか? A:ケーステーブルの ACL がカスタマイズされているかどうかを確認してください Q: 従業員が編集できない人事プロファイルフィールドがあるのはなぜですか? A: HR システムプロパティ (sn_hr_core.hr_profile_editable_fields) を使用して、一部の HR プロファイルフィールドを従業員に非表示/表示するように設定できます。「 を参照してください。 HR プロファイルの追加または変更 Q: スコープ対象のアプリケーションロール (sn_hr_core.basic など) を含むグループにユーザーを追加できないのはなぜですか? A: スコープ対象のアプリケーションロールをアサインできるのは、スコープ対象のアプリケーションロールの アサイン可能者 フィールドで指定されたロールを持つユーザーのみです。上記の例では、ユーザーは sn_hr_core.basic ロールの [アサイン可能者] フィールドである sn_hr_core.admin ロールを持っている必要があります。詳細については KB0722958 を参照してください。これは、スコープ対象ロールがユーザーに直接アサインされているか、スコープ対象ロールを含むグループにユーザーが追加されているかに関係なく適用されます。注意:上記が満たされ、ユーザーがuser_adminした場合でも、ロールまたは含まれているロールのいずれかのロールに [アサイン可能者] フィールドがない場合には、ユーザーがロールを含むグループにユーザーを追加できない状況が発生します。KB1113558を参照してください Q: sn_hr_core.basic ロールを持っているにもかかわらず、ケースの作成時に [ヒューマンリソース (HR):サービスポータル] スコープで作成された特定の HR サービスが表示されないのはなぜですか? A: スコープ付き ACL は、ACL レコードと同じスコープ内に作成されたレコードに対してのみ評価されます。上記の例では、「ヒューマンリソース (HR):サービスポータル」スコープで作成された HR サービスの読み取りアクセスを許可する ACL はありません。HR サービスへの読み取りアクセスを許可する ACL は、「ヒューマンリソース (HR):Core」スコープ内です。解決策は、「ヒューマンリソース (HR):サービスポータル」スコープで同じ読み取り ACL を作成することです。KB KB0780734を参照してください。 Q:sn_hr_core_caseのsys_auditレコードが表示されないのはなぜですか? A:監査レコードを読み取るには、sn_hr_core.admin ロールが必要です