Permissões por pasta de telas

Quem é limitado

• Um membro. O proprietário do projeto limita um membro a pastas de telas e telas escolhidas. O membro entra como antes e vê e altera apenas as suas próprias telas.
• Um agente. O proprietário limita um agente da mesma forma. Um agente também nunca alcança mais do que a pessoa responsável por ele: o seu alcance é o seu próprio escopo restringido pelo escopo dessa pessoa, portanto uma pessoa limitada nunca age por meio de um agente mais amplo.
• Nunca limitados. O proprietário do projeto e os clientes de serviço do projeto inteiro.

Um limite é um escopo. Ele é lido a cada requisição, nunca armazenado em um token ou em uma sessão, então uma alteração vale já na próxima requisição da pessoa, sem entrar de novo. Um chamador sem escopo trabalha com o projeto inteiro e não paga nada pela verificação.

Pastas e herança

Pastas de telas são a hierarquia. Um escopo que nomeia uma pasta contém todas as telas dessa pasta e de todas as pastas dentro dela, e acompanha a pasta quando ela é movida.

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

• Um escopo contém até 1.000 pastas e 200 telas avulsas, e pelo menos um dos dois.
• Uma única tela pode estar em qualquer número de escopos, e uma pasta também.
• Os ids devem nomear pastas e telas existentes do projeto quando o escopo é gravado. Uma pasta ou tela excluída depois deixa um id que não concede nada.
• Um membro que aprova revisões é limitado a pastas. Telas avulsas são para membros que não aprovam.
• Uma pessoa é limitada a telas ou é um uploader, nunca os dois: um uploader é limitado a conteúdo, um membro limitado a telas.

Definir um escopo

Somente o proprietário do projeto define, altera ou encerra um escopo, no dashboard.

1. Abra a página Acesso do dashboard.
2. Em Pessoas, abra o membro e use Telas. Marque as pastas, que incluem tudo o que está dentro delas, e adicione telas avulsas se o membro não aprova. Salve.
3. Para um agente, abra-o em Agentes e use o mesmo controle Telas.
4. Para limitar uma pessoa antes de ela entrar, adicione o escopo ao convite.

Remova o escopo no mesmo lugar para dar ao membro o projeto inteiro de novo.

Definir o escopo de um membro encerra os agentes que essa pessoa trouxe ao projeto, para que nada mantenha o alcance mais amplo que ele tinha antes. Um escopo é recusado enquanto a pessoa, ou um agente que ela trouxe, tem um cliente de serviço ativo do projeto: revogue cada cliente que a recusa nomeia e defina o escopo de novo. Transferir o projeto para um membro remove o escopo desse membro.

Um membro convidado com um escopo entra como um membro que não pode aprovar. O proprietário ativa Pode aprovar para ele na mesma página quando ele deve decidir revisões das suas pastas.

O que uma pessoa limitada faz e vê

Dentro do escopo, uma pessoa limitada trabalha como um membro do projeto, no dashboard, com o CLI e pela API:

• Telas. Leitura, saúde, reproduções, uptime, capturas de tela e visualização ao vivo, comentários, comandos como reiniciar, limpar cache, identificar e atualizar, tags, campos, localização, nome, playlist, agendamento de playlist, takeover, arquivar e excluir.
• Pastas. Criar, renomear, mover e excluir pastas dentro do escopo e definir a playlist padrão de uma pasta. A pasta que um escopo nomeia permanece: somente uma pessoa com um escopo mais amplo a exclui.
• Movimentações. Uma tela ou pasta é movida de um lugar dentro do escopo para outro. A origem e o destino ficam ambos dentro dele.
• Campanhas. Criar, alterar e excluir uma campanha cujo público inteiro está dentro do escopo.
• Ações em frota. Selecione telas por id ou por pasta dentro do escopo.
• Novas telas. Uma pessoa limitada que pode aprovar emparelha ou provisiona uma tela em uma pasta do escopo. A nova tela informa a sua pasta, então ela fica dentro do escopo.
• Notas. Ler e escrever as notas sobre as suas próprias telas, sobre playlists e sobre nada.

O conteúdo (mídia, playlists, aplicativos, cartões, dados de cartão) continua regido pelo papel do membro, exatamente como para qualquer membro.

Uma pessoa limitada não alcança nenhuma administração do projeto: membros, convites, clientes de serviço, logins de agentes, links de frota, cobrança, configurações, webhooks, notificações, alertas, gatilhos, importações de agendamento e relatórios de todo o projeto são recusados. Cada um responde outside_screen_scope.

Uma campanha só é editável dentro do escopo

Uma campanha é listada para todos, e uma pessoa limitada só a edita quando todo o público dela está dentro do seu escopo. Caso contrário, editable é false e a campanha é somente leitura para ela.

• Uma pasta ou tela do escopo está dentro dele.
• Uma regra any está dentro quando todos os filhos estão.
• Uma regra all está dentro quando pelo menos um filho está, porque é uma interseção.
• Uma regra de tag e a regra de todas as telas nunca estão dentro.

Uma pessoa limitada que não pode aprovar

Um membro limitado que não pode aprovar revisões lê tudo no escopo e executa comandos, capturas de tela e comentários, e só altera o que é reproduzido por meio de um aprovador. Atribuir uma playlist, agendamentos, takeovers, campanhas, pastas e movimentações respondem approver_required para ele. Um membro sem escopo continua como está.

O que está fora do escopo

As telas fora do escopo ficam ocultas de toda lista: a lista de telas, as telas de uma pasta, as telas de campanhas, o calendário, os eventos e o stream ao vivo. A árvore de pastas mostra as pastas do escopo e as pastas acima delas, somente leitura e sem contagem de telas, para que a árvore tenha uma raiz. As pastas irmãs delas ficam ocultas.

Uma requisição que nomeia uma tela, pasta, seletor ou público fora do escopo é recusada por inteiro e nunca restringida: nada é gravado. Um id fora do escopo e um id que não existe recebem a mesma resposta.

{
  "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 informa o escopo do próprio chamador, para que ele saiba o que pode usar. Os registros de reprodução, o calendário e o log do Player recebem uma tela do escopo (o calendário também uma pasta). A tendência de saúde de todo o projeto e o uptime diário são recusados; o histórico de saúde por tela e o uptime ficam liberados.

Administração delegada

Dê a um gerente de local as suas pastas e deixe que ele as gerencie:

1. O proprietário limita o gerente às pastas do local.
2. O proprietário ativa Pode aprovar para o gerente.
3. O gerente atribui diretamente playlists, agendamentos e campanhas nas suas pastas e decide as revisões que os agentes propõem para essas pastas.

Um aprovador limitado decide apenas uma revisão cujo alcance inteiro está dentro do seu escopo, e a página Revisões lista apenas essas. Um aprovador limitado não decide nenhuma revisão de criativo de anúncio. Uma revisão que alcança uma tela fora do escopo responde outside_screen_scope.

Membros, convidados e administradores da organização

Uma pessoa tem no máximo uma organização principal. As pessoas para quem ela é a organização principal são seus membros. Em um projeto de qualquer outra organização, a pessoa é externa, isto é, um convidado, e a lista de pessoas do projeto a marca. Ser membro de um projeto continua sendo a única forma de acessar o conteúdo dele. GET /api/session relata organization de uma pessoa, e GET /api/members marca cada convidado com external.

• Tornar-se membro. Um administrador da organização convida uma pessoa por e-mail e, ao aceitar, essa organização passa a ser a organização principal dela, no lugar de qualquer outra. As pessoas em um domínio verificado da organização são membros, assim como qualquer pessoa gerenciada por login único ou provisionamento de usuários. Uma pessoa sem organização principal que cria um projeto adota a organização desse projeto como principal. Entrar em um projeto nunca altera a organização principal.
• Remover um membro. Um administrador remove um membro da organização. Ele fica sem organização principal, e o acesso a projetos que um administrador ou um convite lhe deu termina; o acesso que o provisionamento de usuários concede permanece com o provisionamento. Uma pessoa removida continua de fora, mesmo em um domínio verificado, até receber um novo convite. A remoção é recusada enquanto a pessoa for proprietária de um projeto da organização (member_owns_projects): transfira-o antes. Uma pessoa gerenciada pelo provedor de identidade da organização é removida lá (managed_member), e um administrador é removido depois que sua vaga de administrador termina (organization_admin_member).

Política de convidados

Uma organização escolhe, em Configurações da organização, quem admite em seus projetos como convidados.

A política vale para as pessoas quando são adicionadas a um projeto: no convite, de novo na aceitação dele, por um vínculo de grupo e quando um administrador adiciona alguém. Membros e os próprios administradores da organização nunca são recusados. Uma recusa é guest_not_allowed. Restringir a política não remove ninguém: a página Pessoas sinaliza cada convidado que ela não admitiria.

Biblioteca

Um administrador da organização escolhe um projeto como Biblioteca da organização em Configurações da organização (Premium, Education e Enterprise). Todos os outros projetos da organização passam a usar as mídias, pastas e playlists da Biblioteca, somente para leitura:

• Coloque as mídias dela em páginas.
• Reproduza uma pasta da Biblioteca com um seletor de pasta. Os seletores de tag e de todos usam apenas as mídias do próprio projeto.
• Programe as playlists dela e inicie playlists a partir dos modelos dela.

Somente os membros da própria Biblioteca os alteram. Um projeto com telas não pode ser a Biblioteca, e depois que ele é a Biblioteca não é possível adicionar telas a ele (library_no_screens). Os agentes listam a Biblioteca com screenrig media list --library, screenrig media folder list --library e screenrig playlist list --library.

O que um administrador da organização faz

Um administrador tem autoridade sobre todos os projetos da organização e só lê o conteúdo de um projeto depois de entrar nele.

• Entrar em um projeto. O administrador entra em qualquer projeto da organização como aprovador sem escopo, inclusive quando já era um membro limitado. Isso é registrado no registro de auditoria e envia um e-mail ao proprietário do projeto. Entrar novamente não altera nada.
• Alterar o proprietário. O administrador torna um membro verificado do projeto, ou outro membro da organização, o proprietário do projeto, inclusive quando o proprietário saiu ou foi desativado. Um administrador que entrou no projeto pode se tornar o proprietário. Isso é registrado, e o proprietário anterior e o novo recebem um e-mail.
• Remover um membro do projeto. O administrador remove qualquer membro que não seja o proprietário nem ele mesmo. Isso é registrado.
• Dentro de um projeto do qual é membro, o administrador tem os controles de membros do proprietário sobre as outras pessoas: remover membros, definir quem pode aprovar, definir escopos de telas e de uploads, transferir a propriedade e vincular grupos SCIM.

Pastas protegidas

Uma pasta protegida é para telas em que nenhuma pessoa sozinha altera o que é reproduzido. Uma pessoa que pode aprovar ativa Protegida em uma pasta no dashboard, e a proteção cobre todas as pastas dentro dela. Agentes e clientes de serviço nunca protegem uma pasta, e um agente remove a proteção apenas como proposta: screenrig screen folder update ID --unprotect se torna uma revisão que um segundo aprovador decide. Um aprovador limitado protege pastas dentro do seu escopo, não uma pasta que o seu escopo nomeia. Uma alteração que alcança uma tela em uma pasta protegida se torna uma revisão que um segundo aprovador decide, em todos os níveis de acesso, inclusive Gerenciar.

Um agente que atribui uma playlist a uma tela em uma pasta protegida recebe pending_review e a revisão. A tela continua reproduzindo o que reproduzia até que um segundo aprovador decida.

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

O que acontece com uma alteração depende da alteração:

• Uma revisão. Atribuir uma playlist, definir ou limpar o agendamento de uma playlist ou um takeover, em uma tela ou em uma frota, é uma revisão screen_change. Criar, alterar ou excluir uma campanha cujo público alcança uma tela protegida, criar uma pasta dentro de uma pasta protegida, mover, excluir ou definir a playlist padrão de uma pasta dentro de uma pasta protegida ou que contenha uma, mover telas ou pastas para dentro ou para fora de uma delas e remover a proteção são uma revisão protected_change. A alteração é aplicada na decisão de aprovação. Renomear vale na hora.
• Uma recusa. Edições de tag, campo, localização, fuso horário e wall, a substituição de uma tela, exclusão, arquivamento, suspensão, energia do display e o seu agendamento, uma página de reprodução, um toast, inventário de anúncios, alvos de gatilhos e importações de agendamento que alcançam uma tela protegida respondem protected_target. Para fazer a alteração, um aprovador remove a proteção por meio de uma revisão, a alteração é feita e a pasta volta a ser protegida. Um gatilho que se espalha por várias telas deixa as telas protegidas como estão e as conta.
• Liberados. Retomar, desarquivar, reiniciar, recarregar, identificar, manutenção e capturas de tela continuam liberados.

Uma revisão espera por uma pessoa diferente do proponente e diferente da pessoa responsável pelo agente ou cliente de serviço proponente. A decisão é recusada com second_approver_required quando quem decide é a mesma pessoa. Quando o projeto tem apenas um aprovador, a recusa diz para tornar outro membro um aprovador. Uma alteração proposta antes de a pasta ser protegida se sujeita à regra quando é aprovada. Uma revisão que ficou desatualizada enquanto esperava responde review_stale; proponha a alteração novamente.

Um projeto sem pasta protegida não paga nada pela regra.

Campanhas reservadas

Uma campanha marcada como Reservada só pode ser alterada, pausada, excluída ou ter a reserva removida por uma pessoa que pode aprovar revisões: o proprietário, ou um aprovador cujo escopo contém todo o público da campanha. Uma pessoa ativa Reservada no formulário da campanha no dashboard. Agentes e clientes de serviço nunca alteram uma campanha reservada, em nenhum nível de acesso, e as tentativas deles respondem reserved_item. Reserve a campanha que carrega o agendamento fixo de uma marca, e um gerente ou um agente não poderá alterá-la por acidente.

Tags não são escopo

Um escopo é feito de pastas e telas avulsas. Qualquer pessoa que pode alterar uma tela pode gravar as suas tags, então um escopo por tag permitiria que um gerente ampliasse o próprio alcance ou o de outro gerente. Use pastas para a propriedade e tags para a seleção dentro delas.

Uma ação em frota ou campanha que seleciona por tag é recusada por inteiro para uma pessoa limitada, com outside_screen_scope, e a dica diz para selecionar por ids ou por pasta.

Agentes

Um agente limitado trabalha com o CLI da mesma forma que um membro limitado no dashboard.

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 mostra o screen_scope do agente e o person_screen_scope da pessoa responsável por ele.
• screen list e screen folder list contêm apenas as suas telas e pastas.
• screen pair aceita --folder e exige uma pasta do escopo.
• screen folder update ID --unprotect propõe remover a proteção de uma pasta, enviado sozinho. Isso se torna uma revisão que um segundo aprovador decide.
• campaign show imprime editable e reserved.
• Sem projeto selecionado, screen list deixa de fora um projeto em que o agente é limitado. Selecione o projeto.

Recusas e como corrigi-las

Toda recusa indica o caminho de volta em hint.

Uma alteração protegida que é aceita responde 202 com status: pending_review e a revisão, a mesma resposta que um agente Propor recebe. Acompanhe-a com screenrig reviews show ID.

Auditoria

Toda alteração é um evento no log do projeto, gravado na transação que faz a alteração:

As revisões gravam os eventos review.* habituais, e a pessoa que aprova é o autor do que a revisão aplica.

API

As rotas do proprietário usam a sessão de dashboard.

As rotas da organização aceitam a sessão de dashboard de um administrador. Agentes e credenciais bearer não a têm.

A referência da API lista cada requisição, resposta e problema. Os problemas estão nos tipos de problema.

Relacionado

• Autenticação: níveis de acesso, configurações de revisão e uploaders.
• Agentes: como as revisões funcionam para as alterações de um agente.
• CLI de sinalização: pastas de telas e comandos de frota.
• Clientes de serviço: credenciais para servidores e jobs de CI.