スクリーンフォルダー単位の権限

限定される対象

• メンバー。 プロジェクトオーナーは、メンバーを選択したスクリーンフォルダーとスクリーンに限定します。メンバーはこれまでどおりサインインし、自分のスクリーンのみを表示・変更できます。
• エージェント。 オーナーはエージェントも同じ方法で限定します。エージェントの到達範囲は、責任者のそれを超えることもありません。その範囲はエージェント自身のスコープを責任者のスコープで絞り込んだものであり、限定されたユーザーが、より広いエージェントを通じて操作することはありません。
• 限定されない対象。 プロジェクトオーナーと、プロジェクト全体のサービスクライアント。

制限はスコープです。リクエストごとに読み取られ、トークンやセッションに保存されることはないため、変更は、再度サインインしなくても、そのユーザーの次のリクエストから適用されます。スコープのない呼び出し元はプロジェクト全体で作業し、チェックの負担はありません。

フォルダーと継承

スクリーンフォルダーは階層です。フォルダーを指定するスコープには、そのフォルダーと、その内側のすべてのフォルダーにあるすべてのスクリーンが含まれ、フォルダーが移動するとスコープもそれに従います。

Hotel
  Lobby            <- the lobby manager's scope holds Lobby and Bar
    Bar
  Casino Floor     <- the floor manager's scope holds Casino Floor
  Rooms

• スコープには最大1,000個のフォルダーと200個の個別スクリーンを含めることができ、どちらか少なくとも1つが必要です。
• 1つのスクリーンは任意の数のスコープに属することができ、フォルダーも同様です。
• IDは、スコープの書き込み時にプロジェクトの有効なフォルダーとスクリーンを指している必要があります。後で削除されたフォルダーやスクリーンは、何も付与しないIDとして残ります。
• レビューを承認するメンバーは、フォルダーに限定されます。個別のスクリーンは、承認しないメンバー向けです。
• ユーザーは、スクリーンに限定されるかアップローダーになるかのどちらかで、両方にはなりません。アップローダーはコンテンツに限定され、限定されたメンバーはスクリーンに限定されます。

スコープを設定する

スコープを設定、変更、終了できるのは、ダッシュボードでのプロジェクトオーナーだけです。

1. ダッシュボードのアクセスページを開きます。
2. ユーザーページでメンバーを開き、スクリーンを使用します。フォルダー（その内側のすべてを含みます）を選択し、メンバーが承認しない場合は個別のスクリーンを追加します。保存します。
3. エージェントの場合は、エージェントで開き、同じスクリーンコントロールを使用します。
4. 参加前にユーザーを限定するには、招待にスコープを追加します。

同じ場所でスコープを削除すると、メンバーに再びプロジェクト全体を与えられます。

メンバーのスコープを設定すると、そのユーザーがプロジェクトに連れてきたエージェントが終了するため、以前に与えられたより広い到達範囲は何も残りません。そのユーザー、またはそのユーザーが連れてきたエージェントがプロジェクトの有効なサービスクライアントを持っている間は、スコープは拒否されます。拒否で示された各クライアントを取り消し、もう一度スコープを設定してください。プロジェクトをメンバーに譲渡すると、そのメンバーのスコープは削除されます。

スコープ付きで招待されたメンバーは、承認できないメンバーとして参加します。そのメンバーが担当フォルダーのレビューを決定する場合は、同じページでオーナーが承認可能をオンにします。

限定されたユーザーができることと見えるもの

スコープ内では、限定されたユーザーは、ダッシュボード、CLI、API のいずれでも、プロジェクトのメンバーと同じように作業します：

• スクリーン。 読み取り、ヘルス、再生、稼働時間、スクリーンショットとライブビュー、コメント、再起動・キャッシュのクリア・識別・更新などのコマンド、タグ、フィールド、場所、名前、プレイリスト、プレイリストスケジュール、テイクオーバー、アーカイブ、削除。
• フォルダー。 スコープ内のフォルダーを作成、名前変更、移動、削除し、フォルダーのデフォルトプレイリストを設定します。スコープが指定するフォルダー自体は残ります。削除できるのは、より広いスコープを持つユーザーだけです。
• 移動。 スクリーンまたはフォルダーを、スコープ内のある場所から別の場所へ移動します。移動元と移動先はどちらもスコープ内にある必要があります。
• キャンペーン。 対象全体がスコープ内にあるキャンペーンを作成、変更、削除します。
• フリート操作。 スコープ内のスクリーンを、IDまたはフォルダーで選択します。
• 新しいスクリーン。 承認できる、限定されたユーザーは、スコープ内のフォルダーにスクリーンをペアリングまたはプロビジョニングします。新しいスクリーンはフォルダーを指定するため、スコープ内に配置されます。
• ノート。 自分のスクリーン、プレイリスト、およびどれにも関連しないノートを読み書きします。

コンテンツ（メディア、プレイリスト、アプリケーション、カード、カードデータ）は、ほかのメンバーと同様に、メンバーのロールによって引き続き管理されます。

限定されたユーザーは、プロジェクトの管理機能にアクセスできません。メンバー、招待、サービスクライアント、エージェントのサインイン、フリートリンク、請求、設定、Webhook、通知、アラート、トリガー、スケジュールインポート、プロジェクト全体のレポートは拒否されます。いずれも outside_screen_scope が返されます。

キャンペーンはスコープ内でのみ編集できます

キャンペーンはすべてのユーザーに一覧表示されますが、限定されたユーザーが編集できるのは、対象全体が自身のスコープ内にある場合のみです。それ以外の場合、editable は false となり、キャンペーンは読み取り専用です。

• スコープ内のフォルダーまたはスクリーンは、スコープの内側にあります。
• any ルールは、すべての子が内側にある場合に内側にあります。
• all ルールは、積集合であるため、少なくとも1つの子が内側にあれば内側にあります。
• タグルールと全スクリーンのルールが、スコープ内に含まれることはありません。

承認できない、限定されたユーザー

レビューを承認できない、限定されたメンバーは、スコープ内のすべてを読み取り、コマンド、スクリーンショット、コメントを実行できますが、再生内容を変更できるのは承認者を通じてのみです。プレイリストの割り当て、スケジュール、テイクオーバー、キャンペーン、フォルダー、移動には、approver_required が返されます。スコープのないメンバーは変わりません。

スコープ外のもの

スコープ外のスクリーンは、スクリーン一覧、フォルダーのスクリーン、キャンペーンのスクリーン、カレンダー、イベント、ライブストリームなど、すべての一覧から非表示になります。フォルダーツリーには、スコープのフォルダーとその上位のフォルダーが、読み取り専用でスクリーン数なしで表示され、ツリーにはルートがあります。それらの兄弟は非表示です。

スコープ外のスクリーン、フォルダー、セレクター、対象を指定するリクエストは、絞り込まれることなく全体が拒否されます。何も書き込まれません。スコープ外のIDと存在しないIDには同じ応答が返されます。

{
  "status": 403,
  "errors": [
    {
      "code": "outside_screen_scope",
      "screen_scope": { "folder_ids": ["sfd_01LOBBY"], "screen_ids": [] },
      "hint": "Ask the project owner to widen the scope, or leave this to a member of the whole project."
    }
  ]
}

screen_scope は呼び出し元自身のスコープを示すため、呼び出し元は何を使用できるかを把握できます。再生記録、カレンダー、Playerログは、スコープ内のスクリーンを受け取ります（カレンダーはフォルダーも可）。プロジェクト全体のヘルス推移と日次の稼働時間は拒否され、スクリーンごとのヘルス履歴と稼働時間は開放されています。

委任された管理

会場のマネージャーに担当フォルダーを割り当て、運用を任せます：

1. オーナーは、マネージャーを会場のフォルダーに限定します。
2. オーナーは、マネージャーの承認可能をオンにします。
3. マネージャーは、担当フォルダー内でプレイリスト、スケジュール、キャンペーンを直接割り当て、それらのフォルダーに対してエージェントが提案するレビューを決定します。

限定された承認者は、対象範囲全体が自身のスコープ内にあるレビューのみを決定でき、レビューページにはそれらのみが一覧表示されます。限定された承認者は、広告クリエイティブのレビューを決定できません。スコープ外のスクリーンに及ぶレビューには outside_screen_scope が返されます。

組織のメンバー、ゲスト、管理者

ユーザーのホーム組織は最大 1 つです。その組織をホームとするユーザーが、その組織のメンバーです。他の組織のプロジェクトでは、ユーザーは外部、つまりゲストであり、プロジェクトのユーザー一覧で印が付きます。プロジェクトのコンテンツにアクセスできるのは、引き続きプロジェクトのメンバーだけです。GET /api/session はユーザーの organization を報告し、GET /api/members は各ゲストを external で示します。

• メンバーになる。 組織の管理者がメールでユーザーを招待し、承諾すると、その組織が他の組織に代わってそのユーザーのホーム組織になります。組織の検証済みドメインのユーザーはメンバーであり、シングルサインオンまたはユーザープロビジョニングで管理されるユーザーも同様です。ホーム組織を持たないユーザーがプロジェクトを作成すると、そのプロジェクトの組織がホーム組織になります。プロジェクトに参加しても、ホーム組織は変わりません。
• メンバーを削除する。 管理者は組織からメンバーを削除します。そのユーザーのホーム組織の設定は解除され、管理者または招待によって付与されたプロジェクトへのアクセスは終了します。ユーザープロビジョニングによって付与されたアクセスは、プロビジョニング側の管理のままです。削除されたユーザーは、検証済みドメインのユーザーであっても、新たに招待されるまでメンバーに戻りません。そのユーザーが組織のプロジェクトを所有している間は、削除は拒否されます（member_owns_projects）。先にプロジェクトの所有権を移譲してください。組織の IDプロバイダーが管理するユーザーはそちらで削除され（managed_member）、管理者は管理者シートの終了後に削除されます（organization_admin_member）。

ゲストポリシー

組織は、組織設定で、プロジェクトにゲストとして受け入れる対象を選びます。

ポリシーは、ユーザーがプロジェクトに追加されるときに適用されます。招待時、その承諾時に再度、グループの紐付け時、そして管理者がユーザーを追加するときです。メンバーと組織自身の管理者が拒否されることはありません。拒否は guest_not_allowed です。ポリシーを厳しくしても、誰も削除されません。ユーザーページでは、受け入れられないゲストにフラグが付きます。

ライブラリ

組織の管理者は、組織設定で組織のライブラリとするプロジェクトを1つ選びます（Premium、Education、Enterprise）。組織の他のすべてのプロジェクトは、ライブラリのメディア、フォルダー、プレイリストを読み取り専用で使います。

• そのメディアをページに配置できます。
• フォルダーセレクターを使うと、ライブラリのフォルダーを再生できます。タグセレクターと all セレクターは、プロジェクト自身のメディアだけを使います。
• そのプレイリストをスケジュールに組み込み、そのテンプレートからプレイリストを作成できます。

変更できるのはライブラリ自身のメンバーだけです。スクリーンがあるプロジェクトはライブラリにできず、ライブラリになった後はスクリーンを追加できません（library_no_screens）。エージェントは screenrig media list --library、screenrig media folder list --library、screenrig playlist list --library でライブラリを一覧します。

組織の管理者にできること

管理者は組織のすべてのプロジェクトに対する権限を持ち、プロジェクトのコンテンツを閲覧できるのは、そのプロジェクトに参加した後だけです。

• プロジェクトに参加する。 管理者は、組織の任意のプロジェクトに、スコープなしの承認者として参加できます。すでに限定されたメンバーだった場合も同様です。参加は監査ログに記録され、プロジェクトのオーナーにメールが送信されます。再度参加しても何も変わりません。
• オーナーを変更する。 管理者は、検証済みのプロジェクトメンバーまたは組織の他のメンバーをプロジェクトのオーナーにできます。オーナーが退出または無効化されている場合も同様です。参加済みの管理者は、自分自身をオーナーにすることもできます。変更は記録され、前のオーナーと新しいオーナーにメールが送信されます。
• プロジェクトメンバーを削除する。 管理者は、オーナーと自分自身以外のすべてのメンバーを削除できます。削除は記録されます。
• 管理者がメンバーになっているプロジェクトでは、管理者は他のユーザーに対して、オーナーと同じメンバー管理の操作ができます：メンバーの削除、承認できるメンバーの設定、スクリーンとアップロードのスコープの設定、所有権の移譲、SCIM グループの紐付け。

保護されたフォルダー

保護されたフォルダーは、再生内容を1人だけでは変更できないスクリーン向けです。承認できる人がダッシュボードでフォルダーの保護をオンにすると、その保護はフォルダー内のすべてのフォルダーに及びます。エージェントとサービスクライアントはフォルダーを保護できず、エージェントが保護を解除できるのは提案としてのみです。screenrig screen folder update ID --unprotect は、2人目の承認者が決定するレビューになります。限定された承認者は、自身のスコープ内のフォルダーを保護できますが、スコープが指定するフォルダー自体は保護できません。保護されたフォルダー内のスクリーンに及ぶ変更は、管理を含むすべてのアクセスレベルで、2人目の承認者が決定するレビューになります。

保護されたフォルダー内のスクリーンにプレイリストを割り当てたエージェントには、pending_review とレビューが返されます。2人目の承認者が決定するまで、スクリーンはそれまで再生していた内容を再生し続けます。

screenrig screen assign scr_01EXAMPLESCREEN000000000 --playlist-id pl_01WELCOME
screenrig reviews list --kind protected_change
screenrig reviews show rvw_01EXAMPLEREVIEW0000000000

変更がどうなるかは、変更の内容によります：

• レビュー。 1台のスクリーンまたはフリートに対する、プレイリストの割り当て、プレイリストスケジュールまたはテイクオーバーの設定・解除は、screen_change レビューになります。対象が保護されたスクリーンに及ぶキャンペーンの作成・変更・削除、保護されたフォルダー内でのフォルダーの作成、保護されたフォルダーの中にある、または保護されたフォルダーを含むフォルダーの移動・削除・デフォルトプレイリストの設定、保護されたフォルダーへの、またはそこからのスクリーンやフォルダーの移動、保護の解除は、protected_change レビューになります。変更は承認の決定時に適用されます。名前の変更は即時に反映されます。
• 拒否。 保護されたスクリーンに及ぶ、タグ、フィールド、場所、タイムゾーン、ウォールの編集、スクリーンの置き換え、削除、アーカイブ、停止、ディスプレイ電源とそのスケジュール、再生ページ、トースト、広告インベントリ、トリガーの対象、スケジュールインポートには、protected_target が返されます。変更するには、承認者がレビューを通じて保護を解除し、変更を行い、フォルダーを再び保護します。ファンアウトするトリガーは保護されたスクリーンをそのままにし、その数を数えます。
• 開放されているもの。 再開、アーカイブ解除、再起動、リロード、識別、メンテナンス、スクリーンショットは引き続き利用できます。

レビューは、提案者、および提案したエージェントまたはサービスクライアントの責任者以外のユーザーを待ちます。決定者が同じユーザーの場合、決定は second_approver_required で拒否されます。プロジェクトに承認者が1人しかいない場合、拒否には、ほかのメンバーを承認者にするよう案内されます。フォルダーが保護される前に提案された変更は、承認される時点でこのルールの対象になります。待機中に古くなったレビューには review_stale が返されます。変更を再度提案してください。

保護されたフォルダーのないプロジェクトでは、このルールの負担はありません。

確保済みキャンペーン

確保済みとマークされたキャンペーンを変更、一時停止、削除、確保解除できるのは、レビューを承認できる人だけです。つまり、オーナー、またはスコープがキャンペーンの対象全体を含む承認者です。ダッシュボードのキャンペーンフォームで、確保済みをオンにします。エージェントとサービスクライアントは、どのアクセスレベルでも確保済みキャンペーンを変更できず、試行すると reserved_item が返されます。ブランドの固定スケジュールを担うキャンペーンを確保しておけば、マネージャーやエージェントが誤って変更することはありません。

タグはスコープではありません

スコープはフォルダーと個別のスクリーンです。スクリーンを変更できる人はそのタグを書き込めるため、タグのスコープでは、1人のマネージャーが自分の、または別のマネージャーの到達範囲を広げられてしまいます。所有にはフォルダーを、その内側での選択にはタグを使ってください。

タグで選択するフリート操作またはキャンペーンは、限定されたユーザーには outside_screen_scope で全体が拒否され、ヒントには、IDまたはフォルダーで選択するよう示されます。

エージェント

限定されたエージェントは、ダッシュボードで限定されたメンバーが操作するのと同じように、CLIで作業します。

screenrig agent status
screenrig screen list
screenrig screen folder list
screenrig screen pair "$PAIRING_CODE" --folder sfd_01LOBBY --name "Lobby entrance"
screenrig screen assign scr_01EXAMPLESCREEN000000000 --playlist-id pl_01WELCOME
screenrig screen folder update sfd_01LOBBY --unprotect
screenrig campaign show cmp_01EXAMPLECAMPAIGN0000000

• agent status は、エージェントの screen_scope と、その責任者の person_screen_scope を表示します。
• screen list と screen folder list には、そのスクリーンとフォルダーのみが含まれます。
• screen pair は --folder を受け付け、スコープ内のフォルダーが必要です。
• screen folder update ID --unprotect は、フォルダーの保護の解除を提案します。単独で送信します。2人目の承認者が決定するレビューになります。
• campaign show は editable と reserved を出力します。
• プロジェクトが選択されていない場合、screen list には、エージェントが限定されているプロジェクトは含まれません。プロジェクトを選択してください。

拒否とその対処方法

すべての拒否には、hint に復帰方法が示されます。

受け入れられた保護された変更には、202 が status: pending_review とレビューとともに返されます。これは提案エージェントが受け取る応答と同じです。続いて screenrig reviews show ID を実行してください。

監査

すべての変更は、その変更を行うトランザクション内で書き込まれる、プロジェクトのログのイベントです：

レビューは通常の review.* イベントを書き込み、レビューが適用する内容の実行者は、承認したユーザーです。

API

オーナーのルートは、ダッシュボードセッションを受け付けます。

組織ルートは管理者のダッシュボードセッションを受け付けます。エージェントとベアラー認証情報にはダッシュボードセッションがありません。

APIリファレンスには、すべてのリクエスト、レスポンス、問題が一覧されています。問題は問題タイプにあります。

関連

• 認証：アクセスレベル、レビュー設定、アップローダー。
• エージェント：エージェントの変更に対するレビューのしくみ。
• サイネージCLI：スクリーンフォルダーとフリートコマンド。
• サービスクライアント：サーバーとCIジョブの資格情報。