Permessi per cartella di schermi

Chi è limitato

• Un membro. Il proprietario del progetto limita un membro a cartelle di schermi e schermi scelti. Il membro accede come prima e vede e modifica solo i propri schermi.
• Un agente. Il proprietario limita un agente allo stesso modo. Un agente inoltre non arriva mai oltre la persona che ne è responsabile: la sua portata è il proprio ambito ristretto da quello di quella persona, quindi una persona limitata non agisce mai tramite un agente più ampio.
• Mai limitati. Il proprietario del progetto e i client di servizio dell’intero progetto.

Un limite è un ambito. Viene letto a ogni richiesta, mai memorizzato in un token o in una sessione, quindi una modifica si applica alla richiesta successiva della persona senza dover accedere di nuovo. Un chiamante senza ambito lavora sull’intero progetto e non paga nulla per il controllo.

Cartelle ed ereditarietà

Le cartelle di schermi sono la gerarchia. Un ambito che nomina una cartella contiene ogni schermo di quella cartella e di ogni cartella al suo interno, e segue la cartella quando questa viene spostata.

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

• Un ambito contiene fino a 1000 cartelle e 200 schermi singoli, e almeno uno dei due.
• Uno schermo singolo può stare in un numero qualsiasi di ambiti, e così una cartella.
• Gli id devono indicare cartelle e schermi live del progetto quando l’ambito viene scritto. Una cartella o uno schermo eliminato in seguito lascia un id che non concede nulla.
• Un membro che approva le revisioni è limitato alle cartelle. Gli schermi singoli sono per i membri che non approvano.
• Una persona è limitata agli schermi oppure è un uploader, mai entrambe le cose: un uploader è limitato ai contenuti, un membro limitato agli schermi.

Imposta un ambito

Solo il proprietario del progetto imposta, modifica o termina un ambito, nel dashboard.

1. Apri la pagina Accesso del dashboard.
2. In Persone, apri il membro e usa Schermi. Seleziona le cartelle, che includono tutto ciò che hanno dentro, e aggiungi schermi singoli se il membro non approva. Salva.
3. Per un agente, aprilo in Agenti e usa lo stesso controllo Schermi.
4. Per limitare una persona prima che entri, aggiungi l’ambito all’invito.

Rimuovi l’ambito nello stesso posto per restituire al membro l’intero progetto.

Impostare l’ambito di un membro termina gli agenti che quella persona ha portato nel progetto, così nulla conserva la portata più ampia che era stata data prima. Un ambito viene rifiutato mentre la persona, o un agente che ha portato, ha un client di servizio live del progetto: revoca ogni client indicato dal rifiuto e imposta di nuovo l’ambito. Trasferire il progetto a un membro rimuove l’ambito di quel membro.

Un membro invitato con un ambito entra come membro che non può approvare. Il proprietario attiva Può approvare per lui nella stessa pagina quando deve decidere le revisioni per le sue cartelle.

Che cosa fa e vede una persona limitata

Dentro l’ambito una persona limitata lavora come un membro del progetto, nel dashboard, con la CLI e tramite l’API:

• Schermi. Lettura, stato di salute, riproduzioni, uptime, screenshot e vista live, commenti, comandi come riavvio, svuotamento della cache, identificazione e aggiornamento, tag, campi, posizione, nome, playlist, programmazione playlist, takeover, archiviazione ed eliminazione.
• Cartelle. Crea, rinomina, sposta ed elimina cartelle dentro l’ambito e imposta la playlist predefinita di una cartella. La cartella che un ambito nomina resta: la elimina solo una persona con un ambito più ampio.
• Spostamenti. Uno schermo o una cartella si sposta da un punto dell’ambito a un altro. L’origine e la destinazione sono entrambe al suo interno.
• Campagne. Crea, modifica ed elimina una campagna il cui pubblico intero è dentro l’ambito.
• Azioni sulla flotta. Seleziona gli schermi per id o per cartella dentro l’ambito.
• Nuovi schermi. Una persona limitata che può approvare associa o esegue il provisioning di uno schermo in una cartella dell’ambito. Il nuovo schermo indica la propria cartella, quindi finisce dentro l’ambito.
• Note. Si leggono e si scrivono le note sui propri schermi, sulle playlist e quelle che non riguardano nulla.

I contenuti (contenuti multimediali, playlist, applicazioni, schede, dati delle schede) restano regolati dal ruolo del membro, esattamente come per qualsiasi membro.

Una persona limitata non accede all’amministrazione del progetto: membri, inviti, client di servizio, accessi degli agenti, link flotta, fatturazione, impostazioni, webhook, notifiche, avvisi, trigger, importazioni di programmazione e report a livello di progetto vengono rifiutati. Ognuno risponde con outside_screen_scope.

Una campagna è modificabile solo dentro l’ambito

Una campagna è elencata per tutti, e una persona limitata la modifica solo quando l’intero pubblico è dentro il suo ambito. Altrimenti editable è false e la campagna per lei è di sola lettura.

• Una cartella o uno schermo dell’ambito è dentro di esso.
• Una regola any è dentro quando lo è ogni figlio.
• Una regola all è dentro quando lo è almeno un figlio, perché è un’intersezione.
• Una regola tag, e la regola per ogni schermo, non sono mai dentro.

Una persona limitata che non può approvare

Un membro limitato che non può approvare le revisioni legge tutto nell’ambito ed esegue comandi, screenshot e commenti, e cambia ciò che viene riprodotto solo tramite un approvatore. L’assegnazione di una playlist, le programmazioni, i takeover, le campagne, le cartelle e gli spostamenti rispondono con approver_required per lui. Un membro senza ambito resta invariato.

Che cosa è fuori dall’ambito

Gli schermi fuori dall’ambito sono nascosti da ogni elenco: l’elenco degli schermi, gli schermi di una cartella, gli schermi delle campagne, il calendario, gli eventi e lo stream live. L’albero delle cartelle mostra le cartelle dell’ambito e quelle sopra di esse, di sola lettura e senza il numero di schermi, così l’albero ha una radice. Le loro cartelle sorelle sono nascoste.

Una richiesta che nomina uno schermo, una cartella, un selettore o un pubblico fuori dall’ambito viene rifiutata per intero e mai ridotta: non viene scritto nulla. Un id fuori dall’ambito e un id che non esiste ricevono la stessa risposta.

{
  "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 indica l’ambito del chiamante, così il chiamante sa che cosa può usare. I record di riproduzione, il calendario e il log del Player accettano uno schermo dell’ambito (il calendario anche una cartella). L’andamento dello stato di salute a livello di progetto e l’uptime giornaliero vengono rifiutati; lo storico dello stato di salute e l’uptime per singolo schermo restano aperti.

Amministrazione delegata

Dai al responsabile di una sede le sue cartelle e lascia che le gestisca:

1. Il proprietario limita il responsabile alle cartelle della sede.
2. Il proprietario attiva Può approvare per il responsabile.
3. Il responsabile assegna direttamente playlist, programmazioni e campagne nelle proprie cartelle, e decide le revisioni che gli agenti propongono per quelle cartelle.

Un approvatore limitato decide solo una revisione la cui intera portata è dentro il suo ambito, e la pagina Revisioni elenca solo quelle. Un approvatore limitato non decide alcuna revisione di creatività pubblicitaria. Una revisione che raggiunge uno schermo fuori dall’ambito risponde con outside_screen_scope.

Membri, ospiti e amministratori dell’organizzazione

Una persona ha al massimo una organizzazione di appartenenza. Le persone che vi appartengono sono i suoi membri. In un progetto di qualsiasi altra organizzazione una persona è esterna, cioè un ospite, e l’elenco delle persone del progetto la contrassegna. L’appartenenza a un progetto resta l’unico modo per accedere ai suoi contenuti. Per ogni persona, GET /api/session riporta organization e GET /api/members contrassegna ogni ospite con external.

• Diventa membro. Un amministratore dell’organizzazione invita una persona via email e, accettando, quell’organizzazione diventa la sua organizzazione di appartenenza al posto di ogni altra. Le persone di un dominio verificato dell’organizzazione sono membri, così come chiunque sia gestito tramite single sign-on o provisioning degli utenti. Una persona senza organizzazione di appartenenza che crea un progetto assume come tale l’organizzazione del progetto. Entrare in un progetto non cambia mai l’organizzazione di appartenenza.
• Rimuovi un membro. Un amministratore rimuove un membro dall’organizzazione. La sua organizzazione di appartenenza viene azzerata e termina l’accesso ai progetti che un amministratore o un invito le avevano dato; l’accesso dato dal provisioning degli utenti resta gestito dal provisioning. Una persona rimossa resta fuori, anche se appartiene a un dominio verificato, finché non riceve un nuovo invito. La rimozione viene rifiutata finché la persona è proprietaria di un progetto dell’organizzazione (member_owns_projects): trasferiscilo prima. Una persona gestita dal provider di identità dell’organizzazione viene rimossa lì (managed_member), e un amministratore viene rimosso dopo la fine del suo incarico di amministratore (organization_admin_member).

Policy per gli ospiti

Un’organizzazione sceglie, nelle Impostazioni dell’organizzazione, chi ammette come ospite nei suoi progetti.

La policy si applica alle persone quando vengono aggiunte a un progetto: all’invito, di nuovo alla sua accettazione, tramite l’associazione di un gruppo e quando un amministratore aggiunge qualcuno. I membri e gli amministratori dell’organizzazione stessa non vengono mai rifiutati. Un rifiuto è guest_not_allowed. Restringere la policy non rimuove nessuno: la pagina Persone segnala ogni ospite che non ammetterebbe.

Libreria

Un amministratore dell’organizzazione sceglie un progetto come Libreria dell’organizzazione nelle Impostazioni dell’organizzazione (Premium, Education ed Enterprise). Tutti gli altri progetti dell’organizzazione usano allora i contenuti multimediali, le cartelle e le playlist della Libreria, in sola lettura:

• Inserisci i suoi contenuti multimediali nelle pagine.
• Riproduci una cartella della Libreria con un selettore di cartella. I selettori per tag e per tutti usano solo i contenuti multimediali del progetto stesso.
• Pianifica le sue playlist e crea playlist dai suoi modelli.

Solo i membri della Libreria stessa li modificano. Un progetto con schermi non può essere la Libreria e, una volta che lo è, non è possibile aggiungervi schermi (library_no_screens). Gli agenti elencano la Libreria con screenrig media list --library, screenrig media folder list --library e screenrig playlist list --library.

Cosa fa un amministratore dell’organizzazione

Un amministratore ha autorità su ogni progetto dell’organizzazione e legge i contenuti di un progetto solo dopo esservi entrato.

• Entra in un progetto. L’amministratore entra come approvatore senza ambito in qualsiasi progetto dell’organizzazione, anche quando ne era già un membro limitato. L’operazione viene registrata nel registro di audit e invia un’email al proprietario del progetto. Entrarvi di nuovo non cambia nulla.
• Cambia il proprietario. L’amministratore nomina proprietario del progetto un membro verificato del progetto, o un altro membro dell’organizzazione, anche quando il proprietario se n’è andato o è stato disattivato. Un amministratore che è entrato nel progetto può nominare se stesso proprietario. L’operazione viene registrata e il proprietario precedente e quello nuovo ricevono un’email.
• Rimuovi un membro del progetto. L’amministratore rimuove qualsiasi membro che non sia il proprietario o l’amministratore stesso. L’operazione viene registrata.
• All’interno di un progetto di cui è membro, l’amministratore dispone dei controlli del proprietario sui membri nei confronti delle altre persone: rimuovere membri, stabilire chi può approvare, impostare gli ambiti di schermi e caricamenti, trasferire la proprietà e associare i gruppi SCIM.

Cartelle protette

Una cartella protetta serve per gli schermi in cui nessuna persona da sola cambia ciò che viene riprodotto. Una persona che può approvare attiva Protetta per una cartella nella dashboard, e la protezione copre ogni cartella al suo interno. Agenti e client di servizio non proteggono mai una cartella, e un agente rimuove la protezione solo come proposta: screenrig screen folder update ID --unprotect diventa una revisione che decide un secondo approvatore. Un approvatore limitato protegge le cartelle dentro il proprio ambito, non una cartella che il suo ambito nomina. Una modifica che raggiunge uno schermo in una cartella protetta diventa una revisione che decide un secondo approvatore, a ogni livello di accesso, Gestire incluso.

Un agente che assegna una playlist a uno schermo in una cartella protetta riceve pending_review e la revisione. Lo schermo continua a riprodurre ciò che riproduceva finché un secondo approvatore non decide.

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

Che cosa succede a una modifica dipende dalla modifica:

• Una revisione. Assegnare una playlist, impostare o rimuovere una programmazione playlist o un takeover, su uno schermo o su una flotta, è una revisione screen_change. Creare, modificare o eliminare una campagna il cui pubblico raggiunge uno schermo protetto, creare una cartella dentro una cartella protetta, spostare, eliminare o impostare la playlist predefinita di una cartella contenuta in una cartella protetta o che ne contiene una, spostare schermi o cartelle dentro o fuori da una cartella protetta e rimuovere la protezione sono una revisione protected_change. La modifica viene applicata nella decisione di approvazione. Rinominare ha effetto subito.
• Un rifiuto. Le modifiche a tag, campi, posizione, fuso orario e wall, la sostituzione di uno schermo, l’eliminazione, l’archiviazione, la sospensione, l’alimentazione del display e la sua programmazione, una pagina di riproduzione, un toast, l’inventario pubblicitario, le destinazioni dei trigger e le importazioni di programmazione che raggiungono uno schermo protetto rispondono con protected_target. Per fare la modifica, chi può approvare rimuove la protezione tramite una revisione, la modifica viene eseguita e la cartella viene protetta di nuovo. Un trigger che si distribuisce su più schermi lascia invariati gli schermi protetti e li conta.
• Aperto. Riprendere, ripristinare dall’archivio, riavviare, ricaricare, identificare, la manutenzione e gli screenshot restano aperti.

Una revisione attende una persona diversa dal proponente e diversa dalla persona responsabile dell’agente o del client di servizio proponente. La decisione viene rifiutata con second_approver_required quando chi decide è la stessa persona. Quando il progetto ha un solo approvatore, il rifiuto dice di rendere approvatore un altro membro. Una modifica proposta prima che la sua cartella fosse protetta è soggetta alla regola quando viene approvata. Una revisione diventata obsoleta mentre attendeva risponde con review_stale; proponi di nuovo la modifica.

Un progetto senza cartelle protette non paga nulla per la regola.

Campagne riservate

Una campagna contrassegnata come Riservata viene modificata, messa in pausa, eliminata o resa non riservata solo da una persona che può approvare le revisioni: il proprietario, o un approvatore il cui ambito contiene l’intero pubblico della campagna. Una persona attiva Riservata nel modulo della campagna nel dashboard. Agenti e client di servizio non modificano mai una campagna riservata, a qualsiasi livello di accesso, e i loro tentativi ricevono come risposta reserved_item. Riserva la campagna che porta la programmazione fissa di un marchio, e un responsabile o un agente non potrà modificarla per errore.

I tag non sono ambito

Un ambito è fatto di cartelle e schermi singoli. Chiunque possa modificare uno schermo può scriverne i tag, quindi un ambito basato sui tag permetterebbe a un responsabile di estendere la propria portata o quella di un altro responsabile. Usa le cartelle per la proprietà e i tag per la selezione al loro interno.

Un’azione sulla flotta o una campagna che seleziona per tag viene rifiutata per intero a una persona limitata, con outside_screen_scope, e il suggerimento dice di selezionare per id o per cartella.

Agenti

Un agente limitato lavora con la CLI come un membro limitato nel 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 screen_scope dell’agente e person_screen_scope della persona che ne è responsabile.
• screen list e screen folder list contengono solo i suoi schermi e le sue cartelle.
• screen pair accetta --folder e richiede una cartella dell’ambito.
• screen folder update ID --unprotect propone di rimuovere la protezione di una cartella, inviato da solo. Diventa una revisione che decide un secondo approvatore.
• campaign show stampa editable e reserved.
• Senza un progetto selezionato, screen list esclude un progetto in cui l’agente è limitato. Seleziona il progetto.

Rifiuti e come risolverli

Ogni rifiuto indica il modo per rimediare nel suo hint.

Una modifica protetta accettata risponde con 202, con status: pending_review e la revisione, la stessa risposta che riceve un agente Proponi. Seguila con screenrig reviews show ID.

Audit

Ogni modifica è un evento nel registro del progetto, scritto nella transazione che esegue la modifica:

Le revisioni scrivono i consueti eventi review.*, e la persona che approva è l’attore di ciò che una revisione applica.

API

Le rotte del proprietario accettano la sessione dashboard.

Le route dell’organizzazione accettano la sessione dashboard di un amministratore. Agenti e credenziali bearer non ne hanno.

Il riferimento API elenca ogni richiesta, risposta e problema. I problemi sono nei tipi di problema.

Correlato

• Autenticazione: livelli di accesso, impostazioni delle revisioni e uploader.
• Agenti: come funzionano le revisioni per le modifiche di un agente.
• CLI di signage: cartelle di schermi e comandi per la flotta.
• Client di servizio: credenziali per server e job CI.