API Dashboard

Ispeziona un invito senza consumarlo. Non riporta mai lo stato di iscrizione o di verifica, tranne per il fatto che un reset dell’accesso riporta replaces_unverified_account. Un invito organization_admin o organization_member riporta il nome dell’organizzazione e nessun progetto.

Avvia una cerimonia di registrazione di cinque minuti legata al digest e alla modalità dell’invito. Link create_login richiede un cookie __Host-screenrig-signup verificato e usa il suo nome.

Email create_login lega il nome visualizzato fornito; reset lega la persona target, tranne che un reset di un indirizzo non verificato registra la passkey per la nuova persona che crea, con il nome visualizzato fornito o, se assente, ricavato dall’indirizzo.

Quel reset richiede replace_unverified_account true (l’ispezione riporta replaces_unverified_account) e altrimenti risponde 409 unverified_account_replacement.

Avvia una registrazione con link browser e revoca le registrazioni precedenti per questo invito. La sfida di verifica è legata a questa registrazione. L'autenticazione di sviluppo verifica subito la registrazione senza mail.

Restituisce la registrazione live appartenente a questo browser. Un cookie di registrazione mancante, revocato, consumato o scaduto restituisce invitation_invalid.

Accetta un invito in modo transazionale e crea una nuova sessione persona, eliminando la vecchia sessione se presente.

Il link create_login richiede il cookie __Host-screenrig-signup verificato per questo invito. signed_in richiede una sessione dashboard e un accesso recente o una prova recente; la consegna via email richiede un’email verificata corrispondente, oppure l’indirizzo non verificato della persona che ha effettuato l’accesso, che l’accettazione verifica.

Un indirizzo già posseduto da una persona attiva, verificato o meno, restituisce resource_conflict per create_login. Un reset fa accedere la persona che possiede un indirizzo verificato.

Un reset di un indirizzo non verificato richiede replace_unverified_account true (l’ispezione riporta replaces_unverified_account) e altrimenti risponde 409 unverified_account_replacement e non consuma nulla; con esso, il reset crea una nuova persona verificata con la credenziale che registra, con il nome indicato da display_name o, se assente, ricavato dall’indirizzo, con una nuova organizzazione e un nuovo progetto, e fa accedere quella persona; la persona non verificata viene eliminata (le sue sessioni, passkey e agenti terminano) e i progetti e le organizzazioni che ha creato restano, senza di lei e senza più corrispondere all’indirizzo come suo contatto, così nessun reset successivo reinvia loro un invito di enrollment.

La risposta indica il nuovo progetto. Una sessione per cui è richiesta la verifica dell’email (email_verification_required su GET /api/session) accetta solo un invito inviato via email che indica il proprio indirizzo e riceve 403 email_verification_required per qualsiasi altro.

Un invito organization_admin aggiunge la persona agli amministratori dell’organizzazione e non apre alcun progetto; restituisce organization_admin_limit quando l’organizzazione ha già 20 amministratori e rimane in sospeso, e resource_conflict quando l’organizzazione è stata eliminata.

Un invito organization_member imposta l’organizzazione di appartenenza della persona su quella che invita, al posto di qualsiasi precedente, e non concede alcuna appartenenza al progetto; restituisce managed_elsewhere (409) quando un’altra organizzazione gestisce la persona, e resource_conflict quando l’organizzazione è stata eliminata.

Un invito organization_admin imposta l’organizzazione di appartenenza solo per una persona che non ne ha una. Un invito project_member ricontrolla la policy per gli ospiti dell’organizzazione e restituisce guest_not_allowed (403) quando la persona sarebbe un ospite esterno che la policy rifiuta; un invito a un progetto non cambia mai l’organizzazione di appartenenza di nessuno. Un invito rifiutato resta in sospeso.

Avvia una cerimonia di registrazione di cinque minuti per una registrazione in autonomia, vincolata all’indirizzo email normalizzato e al nome visualizzato. Non crea nulla e non invia email.

Un indirizzo posseduto da una persona attiva, verificato o meno, restituisce 409 account_exists; un indirizzo di un dominio la cui organizzazione accede tramite un provider di identità restituisce 403 sso_required; un indirizzo o un nome non valido restituisce 400 invalid_request con errori di campo. Un server che esegue l’autenticazione per lo sviluppo del dashboard restituisce passkeys_disabled.

Limitato per indirizzo client.

Crea un account in autonomia e fa accedere questo browser.

Una sola transazione crea la persona con un indirizzo email non verificato e una scadenza di verifica a 72 ore, registra la passkey dalla cerimonia avviata da POST /api/signups/passkey-options, crea l’organizzazione e il progetto della persona come li crea l’enrollment dell’agente, rende la persona il proprietario del progetto, memorizza la scelta sulle email di marketing e mette in coda l’email di verifica (scopo account_email).

Il visitatore del sito web che ha aperto la pagina viene collegato all’account e la registrazione viene conteggiata come signed_up. La risposta imposta il cookie di sessione del dashboard. I rifiuti sono quelli di POST /api/signups/passkey-options; una cerimonia usata, scaduta o non corrispondente restituisce 400 invalid_request. Limitato per indirizzo client e per indirizzo email.

Passa a uno dei progetti della persona e aggiorna il tempo dell’ultimo utilizzo. Un membro dello staff può anche passare a un progetto che segue; quella sessione riporta shadow true, è sola lettura e non aggiorna il tempo dell’ultimo utilizzo. Qualsiasi altro progetto restituisce not_found.

Elenca i membri del progetto corrente senza i loro indirizzi email privati

Ogni membro ha la stessa autorità, tranne la gestione dei membri (rimozione, approvatore, ambiti, proprietà), che spetta al proprietario e a un amministratore dell’organizzazione del progetto che è membro. owner indica il proprietario del progetto, external indica un ospite (l’organizzazione di appartenenza del membro non è quella del progetto), e viewer_user_id e viewer_is_owner descrivono la persona che ha effettuato l’accesso.

Rimuove un membro dal progetto corrente. Il proprietario del progetto rimuove ogni altro membro, e così fa un amministratore dell’organizzazione del progetto che è membro; ogni membro può rimuovere se stesso per uscire. Il proprietario non viene mai rimosso né esce (owner_cannot_leave; trasferire prima la proprietà). Un membro che ne rimuove un altro è rifiutato con owner_required.

Una persona che non è membro, anche se già rimossa, è not_found. In una transazione l’appartenenza termina, gli inviti email in sospeso di quella persona al progetto vengono revocati e viene aggiunto l’evento di progetto member.removed (dettagli user_id, removed_by_user_id, left).

Le sessioni della persona smettono di risolvere il progetto alla sua richiesta successiva e tornano come dopo l’eliminazione di un progetto. Le appartenenze degli agenti sono separate e restano. Solo persone; nessuna rotta bearer.

L’attività di una persona nel progetto corrente, dal più recente: i suoi accessi (e accessi rifiutati che indicano il loro indirizzo o passkey), uscite, passaggi nel progetto, modifiche credenziali, prove di riautenticazione e ogni modifica fatta tramite il dashboard, inclusi rifiuti e fallimenti. Le letture non sono mai registrate.

Le richieste agent e CLI sono sui loro agenti (listDashboardAgentEvents). L’ombra di un membro dello staff del progetto non registra nulla; una modifica effettuata sotto un lease di scrittura staff approvato è una riga di quel membro con staff sorgente.

La persona stessa, il proprietario del progetto, un amministratore dell’organizzazione del progetto e un membro staff che segue il progetto possono leggerlo. Chiunque altro riceve not_found, come una persona che non è membro né ha righe qui, quindi la risposta non rivela mai chi appartiene; le righe di un ex membro restano leggibili.

Il progetto è quello della sessione, mai quello della richiesta, e solo le righe di quel progetto vengono restituite.

Ogni valore è derivato dal server: l’azione dalla route abbinata dal server (o un’azione account nominata come session.sign_in o passkey.add), la risorsa dal primo valore path della route quando è un identificatore generato dal server, status, problem_code ed error dal registro problemi, il client dal User-Agent e hint piattaforma (il User-Agent grezzo non è conservato).

Nessun corpo della richiesta, password, token o cookie viene memorizzato. client_ip ed email sono mostrati come registrati.

Le chiavi di paginazione sono (at, id) discendenti. Passa next_cursor come after per continuare; è null alla fine. Una riga scritta nel frattempo si posiziona solo davanti alla prima pagina e la retention rimuove le righe più vecchie, quindi un cursore non si ripete né salta una riga sopravvissuta. Un cursore o filtro malformato è rifiutato con invalid_request; un limite fuori da 1-100 è il default.

Le righe scadono alla finestra di conservazione eventi del progetto al momento della scrittura. recorded_since è il tempo della riga più vecchia ancora esistente del progetto, o, prima di qualsiasi, quando questo server ha iniziato a registrare; nulla prima di essa è ricostruito.

Restituisce il profilo e i conteggi delle credenziali della persona connessa.

Contrassegna come eliminata la persona connessa. Protetto da prova: il corpo contiene una prova di accesso recente verificata contro una riautenticazione legata a questa sessione con tipo account_delete e subject_id uguale all’id utente della persona connessa (avviala con POST /api/me/reauthentications). Senza una riautenticazione corrente la risposta è reauthentication_required.

Se ha successo la risposta è 204, il cookie di sessione del dashboard viene cancellato e la cache HTTP del browser per l’origine del dashboard viene svuotata come all’uscita.

Avvia passaggio passkey legato a sessione, tipo e soggetto. Una persona senza passkey riceve resource_conflict e usa una prova password.

Imposta o sostituisce la password della persona dopo una prova recente. La prima password richiede prova passkey; la sostituzione accetta la password corrente o una passkey. Revoca altre sessioni e mette in coda una notifica di modifica accesso.

Una persona con un indirizzo email non verificato, ad esempio dopo una registrazione in autonomia e prima di verificarlo, non può impostare una password e riceve 403 email_verification_required.

Elenca le passkey della persona con ciò che serve a un client per mantenere allineato con esse il gestore di password del browser (la WebAuthn Signal API). L’elenco riporta l’ID della relying party e lo user handle con cui sono registrate le passkey, e ogni passkey riporta il proprio ID della credenziale e il provider segnalato dal suo autenticatore.

Verifica la prova fresca e avvia una registrazione vincolata alla sessione e alla persona. Le passkey sono disabilitate sotto autenticazione in sviluppo.

Memorizza la nuova passkey, revoca le altre sessioni della persona e mette in coda una notifica di modifica dell’accesso. Una passkey inviata senza nome prende il nome del suo provider, oppure Passkey quando il suo autenticatore non ne ha segnalato nessuno tra quelli noti all’elenco.

Rinomina una passkey di proprietà della persona connessa.

Elimina una passkey dopo una prova recente e invia una notifica di modifica accesso. Rimuovere l’ultimo metodo di accesso restituisce last_credential. Una persona il cui account richiede una passkey (ogni membro dello staff) non può rimuovere la sua ultima passkey; questo restituisce 409 resource_conflict.

Restituisce lo stato dell’email verificata e in sospeso della persona. Una persona che si è registrata da sola ha un indirizzo non verificato finché non apre il link inviato a quell’indirizzo; email_verified è false e verify_by è la scadenza, dopo la quale la sessione può usare solo le rotte che verificano o modificano l’indirizzo (email_verification_required su GET /api/session).

Richiede una modifica dell’email dopo una prova recente. L’indirizzo verificato resta valido mentre la verifica è in sospeso. Un indirizzo posseduto da qualsiasi altra persona attiva, verificato o meno, restituisce user_email_conflict. Il vecchio indirizzo riceve un avviso, non un link per annullare.

Una persona il cui indirizzo non è verificato lo modifica allo stesso modo; verificare il nuovo indirizzo lo rende l’indirizzo verificato della persona e azzera verify_by.

Mette in coda un nuovo link di verifica. Mentre una modifica email attende la verifica (pending_email su GET /api/me/email), è il link di quella modifica, inviato all’indirizzo in sospeso; altrimenti è un link account_email per l’indirizzo non verificato attuale della persona. Entro dieci minuti dall’ultimo link dello stesso tipo non mette in coda nulla e risponde comunque 202.

Una persona il cui indirizzo è verificato e che non ha alcuna modifica in sospeso restituisce 409 resource_conflict.

Sostituisce con il corpo le risposte date dalla persona dopo la registrazione; il corpo contiene tutte le risposte finora, e un membro omesso, o null, è senza risposta. Ogni membro ha un insieme di valori chiuso, e un valore al di fuori di esso restituisce 400 invalid_request con un errore di campo.

Il profilo è conservato insieme alla persona e mostrato allo staff di screenRIG con l’organizzazione in cui la persona si è registrata.

Dove è collocata un’applicazione (app web) del progetto della sessione; il risultato è calcolato in un’unica passata sulle playlist del progetto e con una sola lettura degli schermi che le contengono. placements sono le primitive applicazione la cui applicazione proprietaria memorizzata è questa applicazione, in ordine di playlist (l’ordine dell’elenco delle playlist), pagina e primitiva; una playlist che la colloca due volte ne ha due. release indica come ogni release fissata si confronta con latest_ready_release dell’applicazione: latest, older oppure unknown finché l’applicazione non ne ha una. screens sono gli schermi pairing_pending e attivi che hanno una playlist di un placement come predefinita, in programmazione, in takeover o attualmente in riproduzione, dal più recente; gli schermi archiviati non contano mai, e uno schermo il cui Player non può mostrare app web riporta applications_unsupported.

Un membro o un agente limitato agli schermi (screen_scope) vede solo i propri schermi, e screen_count conta solo quelli. Questo non è ciò che blocca l’eliminazione, cioè le concessioni di runtime (il manifest di uno schermo che contiene una release). Un ID che il progetto non possiede è not_found come per getApplication. La risposta è privata e no-store.

Dove viene usato un media pronto del progetto della sessione; il risultato è calcolato in un’unica passata sulle playlist del progetto e con una sola lettura degli schermi che le contengono. playlists sono quelle che indicano il file (gli id statici di una primitiva immagine o video e un selettore id o ids, il fallback di uno stream, una stringa media:<id> nei params di una scheda, il logo di uno stinger, una traccia della colonna sonora), poi quelle i cui selettori tag, cartella o all lo raggiungono, ogni gruppo nell’ordine dell’elenco delle playlist; una playlist è una singola voce i cui uses elencano ogni modo, con i tipi esatti per primi.

I selettori sono valutati come li risolve il runtime: un filtro tag corrisponde a tag e tags del file, un selettore cartella ai file direttamente dentro la cartella, un selettore all a ogni file di quel tipo, e un file in attesa in base ai suoi ultimi tag e cartella approvati (un file mai approvato non è raggiunto da nessuno).

La rotazione (batch_size, one_at_a_time), le finestre di disponibilità, l’adattamento alle proporzioni e la visibilità di una pagina non vengono valutati. screens sono gli schermi pairing_pending e attivi che hanno una di quelle playlist come predefinita, in programmazione, in takeover o attualmente in riproduzione, dal più recente; gli schermi archiviati non contano mai.

Un membro o un agente limitato agli schermi (screen_scope) vede solo i propri schermi, e screen_count conta solo quelli. Un ID che il progetto non possiede, o un elemento multimediale non pronto, è not_found come per getMedia. La risposta è privata e no-store.

Restituisce una piccola WebP lossy di un’immagine pronta di proprietà del progetto della sessione, così le griglie del dashboard non decodificano mai gli originali. C’è una sola dimensione: si adatta a 512 x 512 mantenendo l’aspetto e non viene mai ingrandita; un’immagine animata mostra il primo frame.

La prima richiesta la genera e la memorizza accanto all’originale; le richieste successive trasmettono la copia memorizzata, e l’eliminazione del contenuto multimediale la rimuove insieme all’originale. L’identificatore di un altro progetto, video, audio e contenuti multimediali non pronti restituiscono not_found. Range non è accettato.

L’ETag è forte e nomina l’originale e il generatore di miniature, quindi è lo stesso a ogni richiesta e host. La risposta è privata, no-cache, e un If-None-Match corrispondente, controllato dopo che il contenuto multimediale si risolve nel progetto della sessione, restituisce 304 senza leggere la miniatura. I byte completati sono registrati come uscita dashboard_media.

Applica le stesse regole di proprietà, condizionali e di generazione di getDashboardMediaThumbnail e restituisce le sue intestazioni senza il corpo. Nessuna uscita è registrata.

Verifica sicura scanner. Non verifica mai un indirizzo, non modifica un utente e non autentica il visitatore. Riporta lo scopo e lo stato del link; un link account_email in sospeso verifica solo per una richiesta che porta la sessione dashboard della persona, quindi una pagina chiede l’accesso prima di chiedere la conferma.

La conferma esplicita umana consuma una sfida di verifica vincolata allo scopo. Le sfide link-signup richiedono il cookie __Host-screenrig-signup corrispondente; le sfide di cambio email sono vincolate al token, quindi il link funziona in qualsiasi browser.

Una sfida account_email (inviata via email alla registrazione in autonomia e da POST /api/me/email/verification, valida per 30 giorni) si apre in qualsiasi browser ma verifica solo per una richiesta che porta una sessione dashboard attiva della persona a cui è destinato il link, compresa una sessione che email_verification_required limita a questa rotta.

Senza una sessione, o con quella di un’altra persona, risponde 200 sign_in_required, non verifica nulla e lascia il link utilizzabile. Un link account_email verificato segna come verificato l’indirizzo della persona e pone fine alla scadenza di verifica; risponde superseded quando un’altra persona ha verificato prima lo stesso indirizzo. La verifica non accede mai al visitatore.

Avvia una cerimonia di affermazione WebAuthn senza nome utente e restituisce le opzioni di richiesta testuali per navigator.credentials.get. Non è richiesto alcun cookie, e non viene pubblicata alcuna lista allowCredentials, quindi il percorso non rivela nulla su quali utenti o credenziali esistano. La cerimonia scade con DashboardCeremonyTTL di cinque minuti.

Quando il server esegue l’autenticazione per lo sviluppo del dashboard, questa rotta restituisce passkeys_disabled.

Verifica un’asserzione senza nome utente e crea il cookie di sessione dashboard per l’utente identificato dalla credenziale rilevabile. Nessun cookie autentica la richiesta. Una cerimonia sconosciuta, scaduta o già usata restituisce passkey_invalid, così come un’asserzione che la relying party non può verificare o un contatore di firma che torna indietro.

Una cerimonia valida il cui identificatore della credenziale non è registrato a nessuno (nessuna credenziale memorizzata lo ha, per nessuna persona) restituisce invece 401 passkey_unknown; questa risposta vale solo per quel caso, quindi un client può dire al browser di dimenticare la credenziale (PublicKeyCredential.signalUnknownCredential) in base a questa risposta e a nessun’altra.

L’identificatore della credenziale non è di per sé un’autorizzazione: lo è l’assertion firmata. Una persona il cui indirizzo verificato appartiene a un dominio la cui organizzazione richiede il single sign-on è rifiutata con 403 sso_required, a meno che sia un amministratore break-glass di quell’organizzazione; un accesso di questo tipo è registrato nell’audit.

Quando il server esegue l’autenticazione per lo sviluppo del dashboard, questa rotta restituisce passkeys_disabled.

Fa accedere la persona identificata da email verificata e password. Email sconosciuta, assenza di password e password errata restituiscono la stessa risposta unauthorized. Apre l’ultimo progetto usato se è ancora un’appartenenza, altrimenti l’appartenenza più recente, oppure nessun progetto.

Un indirizzo di un dominio la cui organizzazione richiede il single sign-on viene rifiutato con 403 sso_required prima di cercare qualsiasi account, quindi la risposta non dipende dal fatto che una persona possieda l’indirizzo; POST /api/sso/starts fa accedere quella persona tramite il suo provider di identità.

L’accesso con password richiede un’email verificata, quindi una persona che si è registrata da sola (POST /api/signups) accede con la propria passkey, e una che ha impostato una password su un indirizzo non verificato riceve comunque la risposta unauthorized. L’autenticazione di sviluppo usa questo stesso flusso con password.

Restituisce la sessione corrente del dashboard. Il cookie di sessione e la sessione lato server stabiliscono l’autorità; user_id è descrittivo. Una risposta 401 significa che è necessario accedere.

Il campo dev_auth è riservato allo sviluppo locale ed è false sul servizio ospitato. organization è l’organizzazione di appartenenza della persona, assente finché non ne ha una; project.organization_admin indica che la persona amministra l’organizzazione del progetto corrente.

Elimina la riga della sessione lato server e scade il cookie della sessione. Non elimina l’utente né rimuove alcuna credenziale. È intrinsecamente idempotente e non richiede Idempotency-Key.

Un logout riuscito cancella anche la cache HTTP del browser per l’origine della dashboard, eliminando i byte privati, no-cache di media, screenshot e revisione annunci visti dalla sessione; una sessione che scade solo li lascia finché il browser non li elimina.

Segnala un passaggio del percorso di un browser nei flussi di ingresso del dashboard (iscrizione, accesso, reset, invito e aggiunta di una passkey) per la lettura dell’onboarding da parte dello staff. Pubblico: funziona con e senza una sessione dashboard.

Il percorso è l’ID casuale del browser; il server conserva anche il cookie visitatore dell’edge quando la richiesta ne ha uno e, quando la richiesta ha una sessione, la persona e l’organizzazione. Un percorso è riservato allo staff e conserva i valori reali inseriti dalle persone (indirizzi, nomi, risposte); non riceve mai una password, un codice o un token.

Di mode, source, utm_source, utm_medium, utm_campaign, click_kind, site_trail e site_cta viene conservato il primo valore; ogni passaggio conserva il proprio primo istante, mentre value e detail di un passaggio e l’email del percorso (da email_submitted) sono gli ultimi. source è accettato solo con entry_viewed. question è obbligatorio con i passaggi question_* e rifiutato con ogni altro. detail è un codice problema per un passaggio *_failed, il metodo di accesso per signed_in, oppure connected o skipped per signup_finished. email_verified, email_gate_reached, site_visited, site_cta_clicked e i traguardi dell’account sono scritti o derivati dal server e qui vengono rifiutati.

Sono limitate solo le lunghezze. Limitato per indirizzo client.

Elenca ogni agente in sospeso, attivo, revocato, annullato e scaduto del progetto della sessione con metadati di installazione sicuri, ultimo uso, conteggio richieste autenticate e crediti misurati direttamente attribuibili. Non vengono restituiti bearer, byte chiave destinatario, busta o identificatore progetto

La cronologia di questo agente, dal più recente, come UN record per trigger. Riporta sia ciò che l’agente ha richiesto sia cosa è cambiato di conseguenza. Una richiesta che ha modificato qualcosa è il suo evento di dominio, marcato con il comando che l’ha causata. Una richiesta che non ha modificato nulla — rifiutata, fallita o un successo senza evento — è un evento agent.command.

Non esiste un endpoint comandi separato; mostrare lo stesso trigger su due pannelli era il difetto che questo ha sostituito. Gli eventi di ciclo vita per questo agente sono inclusi. Attività worker, player e solo dashboard non sono mai interpretate come attività agent. Due richieste sono due trigger. Un ritento dopo un rifiuto è un secondo record, mai una riscrittura del primo.

Le letture non sono registrate, perché non cambiano nulla e un agente di polling seppellirebbe ogni azione reale. L’iscrizione anonima è esclusa. Ogni parte del timbro comando deriva dal percorso abbinato a questo server o dal registro problemi.

Non ci sono vettori argomento, corpo richiesta, header o testo libero in nessun record, quindi nulla va oscurato e nessun chiamante può scrivere testo scelto in una superficie visibile all’operatore. Gli identificatori risorsa appaiono perché un identificatore non è mai autorizzazione ed è già pubblicato sugli eventi. Chiavi di paginazione su sequenza, discendente.

Passa il next_cursor restituito come after per continuare. next_cursor è vuoto quando la pagina è breve, che è la fine della cronologia: un’append concorrente prende solo una sequenza più alta, e la conservazione rimuove prima le sequenze più basse, quindi un cursore non duplica né salta mai un record sopravvissuto. L’impaginazione offset non è supportata.

Ogni parametro di ricerca è un predicato di corrispondenza esatta o intervallo su un token scritto dal server. Un cursore o filtro malformato è rifiutato con invalid_request. Un limite fuori da 1-200 è limitato al valore predefinito invece che rifiutato. I record scadono alla finestra di conservazione eventi del progetto.

Scollega l’agente dal progetto selezionato dopo una prova recente. Il progetto deve essere una delle appartenenze della persona. Le connessioni in sospeso e le emissioni di credenziali vengono annullate; non viene emesso alcun token sostitutivo. Un membro limitato agli schermi non collega agenti, non emette credenziali e non gestisce le persone del progetto: outside_screen_scope (chiedi al proprietario del progetto).

Le note che questo agente ha scritto nel progetto della sessione, le più recenti per prime, aperte e risolte. state è all (predefinito), open o resolved. Passa next_cursor come after; è vuoto nell’ultima pagina. I corpi delle note sono testo semplice scritto da un agente; renderizzali come testo, mai come HTML o Markdown.

Risolvi una delle note aperte dell’agente come persona connessa, con una motivazione obbligatoria; resolution.by indica la persona. Aggiunge note.resolved con la persona come attore. Una nota risolta è note_not_open.

Elimina una delle note dell’agente, aperta o risolta, come persona connessa. Aggiunge note.deleted con la persona come attore.

Le richieste di connessione in sospeso indirizzate al progetto della sessione, che un membro può rivedere e approvare: richieste che nominano il progetto, e accessi o connessioni dispositivo da un’identità agente già membro di esso.

L’accesso di una nuova installazione non è elencato (il suo suggerimento progetto è fornito dal client); una persona vi accede tramite il suo codice utente (POST /api/agent-connections/lookup).

Risolvi il codice utente di un accesso dispositivo in sospeso (`screenrig login`), come digitato o precompilato nella pagina di connessione, alla sua connessione, la cui vista di approvazione lo mostra. Non approva nulla. Separatori, spazi e maiuscole/minuscole sono ignorati. Un codice sconosciuto, usato o non valido è agent_connection_invalid; uno scaduto è agent_connection_expired.

Limitato a 5 ricerche per sessione dashboard ogni 10 minuti, 20 per indirizzo client ogni ora e 1200 per ora sull’intera flotta (rate_limited). Un membro limitato agli schermi non collega agenti, non emette credenziali e non gestisce le persone del progetto: outside_screen_scope (chiedi al proprietario del progetto).

Restituisce i metadati della revisione della connessione sicura. La revisione non seleziona un progetto; l’approvazione seleziona uno degli iscritti della persona.

Approva la connessione per il progetto selezionato dopo una prova recente e crea un agente in sospeso. Il progetto deve essere una delle appartenenze della persona. Restituisce metadati sicuri, mai il bearer. Un membro limitato agli schermi non collega agenti, non emette credenziali e non gestisce le persone del progetto: outside_screen_scope (chiedi al proprietario del progetto).

Nega la connessione per il progetto selezionato dopo una prova recente senza creare un agente. Il progetto deve essere una delle appartenenze della persona. Un membro limitato agli schermi non collega agenti, non emette credenziali e non gestisce le persone del progetto: outside_screen_scope (chiedi al proprietario del progetto).

Una richiesta per la shell del dashboard.

Ogni membro è il corpo con cui la rotta indicata risponde per questa stessa sessione (GET /api/me/email, /api/support/status, /api/projects, /api/organizations, /api/project, /api/project/capabilities, /api/advertising/network, /api/alerts?state=open&limit=1 e /api/reviews?state=all&limit=1), prodotto dal gestore di quella rotta con i suoi controlli di autorizzazione, piano e ambito.

Un membro è assente quando la sua rotta non risponderebbe 2xx per questa sessione (un rifiuto, un ruolo o un piano che non può leggerla, nessun progetto corrente, un errore), e il dashboard legge allora direttamente quella rotta. advertising_network è null quando la sua rotta risponderebbe 404 not_found perché il progetto non ha una rete.

Una sessione senza progetto corrente riceve i membri che non ne richiedono uno.

Contatori stato rete del progetto per il progetto della sessione. Il conteggio schermi online deriva da flussi eventi runtime live associati, la stessa derivazione pubblicata da Screen.online; non è un booleano memorizzato né un battito del lettore. I byte media sono i byte duraturi solo dei media pronti.

Stato veritiero della capacità di pagamento. rails_available è false e unavailable_reason è financial_rails_unavailable mentre carta, tasse e canale di prelievo sono indisponibili. Non vengono restituiti dati bancari grezzi.

Una ricevuta/documento fiscale finalizzato di proprietà del chiamante. Nessuna ricevuta esiste mentre la raccolta fondi è non spedita, quindi questo è not_found e non un documento fabbricato.

Restituisce il saldo pubblico in crediti interi del progetto di sessione. Questa lettura autenticata da cookie non addebita mai, quindi rimane disponibile a zero. Il dashboard solo cookie non presenta mai un bearer progetto a GET /api/project.

Genera un singolo ticket di lancio di trenta secondi per l’ultima release pronta di un’applicazione di proprietà del progetto della sessione, sull’esatto host di anteprima di quella release, mai sull’host di release che i Player incorniciano, così un Player e il dashboard in un browser non condividono mai i documenti memorizzati in cache di quell’host né concedono cookie.

Il ticket si converte nel cookie release-grant solo su quell’host, quindi l’anteprima è cross-origin per costruzione e il codice dell’app web non può mai leggere un cookie dashboard. La risposta release_id identifica l’esatta release scelta per questo avvio, anche se un’altra pubblicazione termina più tardi. Assegna launch_url a iframe.src e a nient’altro.

L’autorità qui è l’autorità del proprietario: il progetto della sessione possiede l’applicazione. Quella è una seconda fonte di autorità deliberata accanto all’autorità esatta del manifest corrente per screenrig.webapp-package/v1, ed è limitata a questa operazione. Non generalizzarla a media o a contenuti runtime protetti.

Non esiste un player genitore, quindi l’SDK browser e il bridge key-value falliscono chiusi e l’anteprima è solo presentazione. Un’applicazione senza release pronta è resource_conflict.

Un’organizzazione così come la mostra al chiamante un elemento di GET /api/organizations, con admin, home e reseller. Una persona connessa la legge quando la amministra, amministra il reseller a cui è delegata, è staff, o la vedrebbe in quell’elenco (membro di uno dei suoi progetti attivi, oppure è la sua organizzazione di appartenenza).

Chiunque altro, e un’organizzazione che non esiste, riceve 404 not_found. Non concede alcuna appartenenza al progetto. Solo sessioni con cookie; una credenziale agente viene rifiutata.

Gli amministratori dell’organizzazione leggono solo nomi dei progetti, proprietari, stato e numero di schermi; questo non concede alcun accesso al progetto. Un amministratore legge i contenuti di un progetto solo dopo esservi entrato (POST .../projects/{project_id}/access), e ne gestisce le persone con le rotte proprietario e membri qui sotto.

I reseller attivi la cui organizzazione è amministrata dalla persona connessa (admin_user_ids), ordinati per nome; vuoto per tutti gli altri. Solo sessioni con cookie. Un reseller è un’organizzazione che lo staff ha reso reseller o che uno dei suoi amministratori ha iscritto (POST /api/resellers); i suoi amministratori gestiscono le organizzazioni dei suoi clienti (docs/resellers.md).

Un amministratore di un’organizzazione la rende subito un reseller. Il chiamante deve essere una persona connessa con un indirizzo email verificato (solo sessioni con cookie; agenti e client di servizio non hanno mai l’autorità di reseller) e un amministratore dell’organizzazione indicata da organization_id; chiunque altro riceve 404 not_found.

Il reseller parte da 2000 punti base del prezzo di listino (20%), in vigore da subito, ed è in attesa di revisione; può aggiungere fino a 10 clienti attuali (customer_limit) finché screenRIG non lo esamina. L’organizzazione deve essere attiva, non essere già un reseller, non essere cliente di un reseller e non avere il piano staff o promo (409 reseller_conflict, il dettaglio indica il motivo).

Aggiunge reseller.enrolled al registro di audit dell’organizzazione.

Un reseller amministrato dal chiamante, con il suo margine. Chiunque altro riceve 404 not_found.

I clienti attuali del reseller (le organizzazioni delegate a esso), ordinati per nome, con piano, conteggi e byte archiviati. Solo amministratori reseller; chiunque altro riceve 404 not_found.

Crea un’organizzazione cliente delegata al reseller fin dalla creazione, su Standard, con l’amministratore reseller chiamante come unico amministratore. L’organizzazione di appartenenza del chiamante non cambia. Gli amministratori dell’organizzazione stessa possono poi terminare la delega (DELETE /api/organizations/{org_id}/reseller).

Aggiunge organization.created e reseller.customer_started al registro di audit dell’organizzazione. Un reseller in attesa di revisione (review_state pending) può aggiungere fino a customer_limit clienti attuali; oltre, la risposta è 409 reseller_conflict.

Un cliente attuale del reseller. Solo amministratori reseller; un’organizzazione che non è un cliente attuale risponde con 404 not_found.

Imposta il piano di un cliente attuale, pagato dal reseller. standard rimuove il piano; plus e premium sono sempre consentiti, education solo per un’organizzazione idonea al piano Education. Enterprise, staff e promo sono assegnati dallo staff.

Un upgrade si applica subito, un downgrade o una rimozione al prossimo inizio mese UTC, come le modifiche del piano di un’organizzazione (docs/billing-rollup.md). Aggiunge reseller.customer_plan al registro di audit dell’organizzazione.

I progetti attivi di un cliente attuale con nomi, stato, numero di schermi e se il chiamante è già membro. L’elenco non concede alcun accesso ai progetti; POST .../access permette di unirsi a uno di essi.

Rende l’amministratore reseller chiamante membro a pieno titolo del progetto di un cliente attuale (can_approve, nessun ambito, source reseller_admin), come fa l’ingresso di un amministratore dell’organizzazione, così da poterlo aprire con PUT /api/session/project. Se è già membro, risponde con il progetto invariato.

Aggiunge member.added_by_reseller al progetto e reseller.project_joined al registro di audit dell’organizzazione, e invia un’email al proprietario del progetto. L’appartenenza resta finché non viene rimossa; terminare la delega non la rimuove.

Quanto il reseller deve per un mese UTC. Una riga per ogni cliente delegato in un qualsiasi momento del mese, con la parte degli addebiti d’uso nel periodo delegato del mese che il suo credito non ha coperto (al prezzo di listino e al prezzo del reseller), e il prezzo annuale del suo piano.

Il prezzo del reseller è il listino meno il margine in vigore alla più recente tra la data di inizio del mese e quella di (ri)creazione del reseller. Solo amministratori reseller.

Un amministratore dell’organizzazione termina subito la delega al proprio reseller. Da quel momento l’organizzazione paga per sé; il suo piano, i suoi progetti e i suoi membri restano invariati, comprese le appartenenze detenute dagli amministratori del reseller. L’eccedenza maturata dal suo portafoglio durante la delega, fatturata al reseller, viene annullata nella stessa modifica.

Aggiunge reseller.customer_ended al registro di audit dell’organizzazione. Un’organizzazione senza reseller risponde con 404 not_found.

Progetti altrove i cui proprietari hanno un’email verificata sul dominio esatto verificato. Indirizzi di contatto e sottodomini non corrispondono, e gli amministratori non possono importare progetti.

Apri una sfida DNS TXT di 7 giorni per un dominio, sostituendo la sfida in sospeso di quel dominio; gli altri domini dell’organizzazione restano invariati. Metti il suo valore esatto nel nome DNS restituito e mantienilo lì. Un’organizzazione può avere al massimo 20 domini, verificati e in sospeso insieme (resource_conflict). Un dominio di un’altra organizzazione è resource_conflict.

Un dominio che questa organizzazione già possiede può essere dimostrato di nuovo, il che registra il nuovo valore per il controllo DNS giornaliero.

Verifica una sfida non scaduta contro DNS e aggiungi il suo dominio all’organizzazione, oltre ai domini già posseduti. Ogni dominio esatto appartiene a un’organizzazione. Una prova ruotata durante la ricerca è rifiutata. Mantieni il record TXT in posizione; un controllo giornaliero rimuove un dominio il cui record manca da sette giorni.

Una volta che il reclamo è confermato, e in background dopo questa risposta, ogni progetto il cui proprietario è una persona verificata esattamente al dominio e che è solo nell’organizzazione personale di quel proprietario viene spostato in questa organizzazione (rinominata "<name> (<owner>)" in caso di conflitto nome).

I progetti in altre organizzazioni, i progetti con un piano a pagamento del cliente proprio, e i progetti che il loro proprietario o staff ha spostato fuori da un’organizzazione di dominio restano dove sono; un progetto rifiutato dai limiti dell’organizzazione viene riprovato un giorno dopo. Il posizionamento non concede accesso.

Un amministratore designato legge gli amministratori dell’organizzazione, i candidati che possono diventarlo (proprietari verificati e attivi dei suoi progetti live che non sono ancora amministratori) e la revisione dell’organizzazione. Chiunque altro è rifiutato come nelle altre rotte admin dell’organizzazione. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato sostituisce gli amministratori dell’organizzazione. If-Match contiene la revisione dell’organizzazione; una obsoleta è revision_conflict con current_revision. Il set nomina da 1 a 20 persone, ciascuna amministratore attuale o candidato, altrimenti invalid_request; un amministratore si rimuove solo se rimane un altro amministratore.

La modifica incrementa la revisione, viene registrata nell’audit dell’organizzazione, non concede appartenenza al progetto e restituisce la stessa struttura di GET. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato legge le persone dell’organizzazione. Sola lettura. projects elenca i progetti live dell’organizzazione, ordinati per nome, al massimo 500. people è l’unione dei membri dell’organizzazione (member true), delle appartenenze attive a quei progetti (le appartenenze sospese sono escluse) e degli amministratori designati.

L’ordine è: prima gli amministratori, poi i membri dell’organizzazione, poi le persone esterne (quelle che non sono membri dell’organizzazione), ciascun gruppo per nome visualizzato e poi per email.

Ogni persona riporta il proprio ruolo in ciascun progetto (owner o member), se può approvare le revisioni in quel progetto (can_approve) e se è limitata a schermi o upload (limited), se è un amministratore, se è un membro dell’organizzazione (member), se è gestita dall’organizzazione (managed) e, per una persona esterna, se la policy per gli ospiti attuale non la ammetterebbe (outside_guest_policy).

Un amministratore o un membro dell’organizzazione senza alcun progetto compare con un elenco projects vuoto. email è vuoto per una persona il cui indirizzo non è verificato. Le persone disattivate e gli agenti non compaiono mai. Vengono restituite al massimo 500 persone, sempre con gli amministratori inclusi; truncated è true quando persone, progetti o appartenenze sono stati esclusi.

Chiunque altro è rifiutato come nelle altre rotte admin dell’organizzazione. Solo persone; agenti e credenziali bearer non hanno alcuna rotta.

Un amministratore designato elenca gli inviti amministrativi dell’organizzazione per id, 50 alla volta, dopo aver scaduto quelli il cui tempo è passato. Gli indirizzi dei destinatari sono visibili agli amministratori dell’organizzazione, che li hanno forniti. Token e URL delle credenziali non sono mai elencati. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato invita persone via email a diventare amministratori. Accettare aggiunge la persona agli amministratori dell’organizzazione e crea il loro login se non ne hanno; non concede alcuna appartenenza al progetto. Al massimo 20 amministratori contando gli inviti amministrativi in sospeso (organization_admin_limit); un indirizzo la cui persona già amministra l’organizzazione è invalid_request.

Gli inviti tramite e-mail scadono dopo sette giorni; un invito in sospeso allo stesso indirizzo viene riutilizzato. I nomi dell’organizzazione e dell’invitante devono essere idonei per l’e-mail. Solo persone; agenti e credenziali bearer non hanno percorso amministratore.

Un amministratore designato revoca un invito amministrativo in sospeso e libera il suo slot amministrativo. Un invito già revocato restituisce 204; uno accettato restituisce invitation_consumed; un id che l’organizzazione non possiede è not_found. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato elenca gli inviti membro dell’organizzazione per id, 50 alla volta, dopo aver scaduto quelli il cui tempo è passato. Gli indirizzi dei destinatari sono visibili agli amministratori dell’organizzazione, che li hanno forniti. Token e URL delle credenziali non sono mai elencati. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato invita persone via email a unirsi all’organizzazione come membri. Accettare imposta l’organizzazione di appartenenza della persona su questa, al posto di qualsiasi precedente, e crea il suo login se non ne ha uno; non concede alcuna appartenenza al progetto.

Un indirizzo la cui persona è già membro dell’organizzazione è invalid_request; uno la cui persona è gestita da un’altra organizzazione è managed_elsewhere. Gli inviti email scadono dopo sette giorni; un invito in sospeso allo stesso indirizzo viene riutilizzato. I nomi dell’organizzazione e di chi invita devono essere adatti all’email.

Accettare un invito all’organizzazione del personale (plan_id staff) rende anche la persona membro del personale; solo il personale può quindi inviare questi inviti, a un indirizzo per richiesta con una prova staff_grant associata (reauthentication_required se manca). Solo persone; gli agenti e le credenziali bearer non hanno una route amministrativa.

Un amministratore designato revoca un invito membro in sospeso. Un invito già revocato restituisce 204; uno accettato restituisce invitation_consumed; un id che l’organizzazione non possiede è not_found. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato rimuove un membro dall’organizzazione.

In una transazione l’organizzazione di appartenenza della persona viene azzerata e le sue appartenenze a tutti i progetti live dell’organizzazione terminano, ciascuna come se la persona venisse rimossa da quel progetto (gli inviti email in sospeso a esso vengono revocati e le sue sessioni smettono di risolverlo); le appartenenze ai progetti di altre organizzazioni restano invariate, e nessun’altra organizzazione cambia.

La modifica viene registrata nell’audit dell’organizzazione.

Una persona gestita da un provider di identità (single sign-on o SCIM) è managed_member; un amministratore designato è organization_admin_member (rimuovi prima il suo slot amministrativo con PUT /api/organizations/{org_id}/admins); una persona che possiede un qualsiasi progetto live dell’organizzazione è member_owns_projects e il dettaglio elenca i nomi dei progetti (trasferisci prima quei progetti, non viene rimosso nulla); una persona che non è membro dell’organizzazione, anche se già rimossa, è not_found.

Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato stabilisce chi l’organizzazione ammette come ospite nei suoi progetti, cioè le persone la cui organizzazione di appartenenza è un’altra o che non ne hanno. mode allow (il valore predefinito) ammette ogni ospite, domains ammette un ospite il cui indirizzo email verificato è su uno dei domains, e none non ammette alcun ospite. domains elenca da 1 a 20 nomi DNS distinti in minuscolo, obbligatorio per mode domains e omesso negli altri casi; qualsiasi altra cosa è invalid_request.

La policy sostituisce la precedente, incrementa la revisione dell’organizzazione, viene registrata nell’audit dell’organizzazione e risponde con la policy in vigore. Viene controllata quando l’organizzazione concede a un ospite un’appartenenza a un progetto, tramite invito di membro del progetto (creazione e accettazione) e tramite associazione di gruppo SCIM, e rifiuta con guest_not_allowed.

Lo staff e gli amministratori dell’organizzazione stessa sono esenti, gli agenti non vengono controllati e i membri dell’organizzazione non sono mai ospiti. Restringere la policy non rimuove nessuno; outside_policy conta le persone esterne già presenti nei progetti live dell’organizzazione che la nuova policy non ammetterebbe, e GET /api/organizations/{org_id}/people segnala ciascuna di esse (outside_guest_policy).

Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato imposta o rimuove il progetto Libreria dell’organizzazione. project_id indica uno dei progetti attivi dell’organizzazione, oppure null per rimuoverlo.

Tutti gli altri progetti dell’organizzazione leggono allora i contenuti multimediali, le cartelle multimediali e le playlist della Libreria (library=true su GET /api/media, /api/media-folders e /api/playlists, e per id) e li usano in sola lettura: riferimenti ai contenuti multimediali nelle pagine, selettori by:folder che indicano una cartella della Libreria (i selettori per tag e per tutti non raggiungono mai la Libreria), programmi e stack degli schermi, e from_template. Solo i membri della Libreria stessa li modificano.

Il progetto Libreria non ha schermi: un progetto con schermi dà library_no_screens, e la Libreria non ne ammette in seguito. Impostare una Libreria richiede la funzionalità di piano library (Premium, Education, Enterprise; altrimenti feature_not_in_plan); rimuoverla non la richiede mai, e una Libreria mantenuta dopo un downgrade continua a essere servita.

Se la Libreria viene rimossa o sostituita, le playlist dei progetti membri che indicano i suoi elementi non riescono più a risolverli alla scrittura successiva, e gli schermi smettono di ricevere i suoi contenuti multimediali. Un progetto che è la Libreria ed è eliminato o spostato fuori dall’organizzazione la rimuove.

Risponde con la vista dell’organizzazione, viene registrata nell’audit dell’organizzazione (organization.library_changed) e incrementa la revisione. Solo persone.

Un amministratore designato imposta l’accesso di molte persone a molti progetti live dell’organizzazione in un’unica richiesta, senza entrare in nessuno di essi.

Ciascuna delle modifiche, da 1 a 500, nomina un progetto, una persona e un accesso, senza che una coppia (project_id, user_id) compaia due volte. member rende la persona un membro del progetto che non può approvare le revisioni (aggiunta quando non lo è; un approver perde l’approvazione), approver un membro che può approvare (aggiunta quando non lo è) e none nessun membro (rimossa quando lo è).

Tutto viene applicato in ordine in una sola transazione, e un solo rifiuto annulla l’intero lotto; ogni rifiuto indica changes[i] (il progetto o la persona) o changes[i].access in errors[].field.

Un progetto che non è un progetto live di questa organizzazione è not_found; una persona che non è una persona attiva (un agente, una persona disattivata, un id sconosciuto) o che è staff, un’appartenenza sospesa e una persona aggiunta che non è tra le persone dell’organizzazione (i suoi amministratori, i suoi membri dell’organizzazione e i membri attivi dei suoi altri progetti live; chiunque altro entra tramite un invito) sono invalid_request; il proprietario non viene mai impostato su member o none (owner_cannot_leave); un uploader non approva mai (resource_conflict, come risponde PUT /api/members/{user_id}/approver); rimuovere l’amministratore stesso è rifiutato con forbidden (un amministratore esce tramite DELETE /api/members/{user_id}); e una persona aggiunta viene ammessa come la ammetterebbe un invito, quindi i membri dell’organizzazione e i suoi amministratori sempre, e una persona esterna solo dove la policy per gli ospiti la ammette ora (guest_not_allowed).

Si applicano a ciò che viene aggiunto il limite di 200 membri del progetto e il tetto di membri del suo piano (member_limit_reached). La risposta ripete ogni modifica nell’ordine della richiesta; changed è false per quella il cui accesso era già in vigore, che non scrive né registra nulla.

Ogni modifica viene registrata nell’audit dell’organizzazione (organization.project_member_added, organization.project_member_approver_changed o organization.project_member_removed) e negli eventi del progetto (member.added_by_organization_admin, project.member_approver_changed o member.removed, contrassegnati come eseguiti dall’amministratore dell’organizzazione), e il proprietario di ogni progetto riceve una sola e-mail per il lotto, salvo che la modifica sia sua.

Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato entra in uno dei progetti live dell’organizzazione come membro senza ambito di schermi o di upload che può approvare le revisioni. È l’ingresso nel progetto a dare all’amministratore i contenuti del progetto, che le rotte dell’organizzazione non mostrano mai.

Un amministratore che è già membro senza ambito e può approvare riceve 200 con joined false e non cambia nulla; un membro con un ambito di schermi o di upload, o che non può approvare, diventa un membro senza ambito che può approvare, registrato come ingresso.

Si applica il limite di 200 membri del progetto (member_limit_reached); la policy per gli ospiti dell’organizzazione non si applica mai ai suoi amministratori. L’ingresso viene registrato nell’audit dell’organizzazione come organization.project_joined e negli eventi del progetto come member.added_by_organization_admin, e il proprietario del progetto riceve un’email.

Un progetto che l’organizzazione non possiede, o che è stato eliminato, è not_found. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato rende una persona proprietaria di uno dei progetti live dell’organizzazione senza entrarvi, da chiunque lo possieda ora, compreso un proprietario il cui account è disattivato.

Il nuovo proprietario è una persona verificata e attiva che è membro del progetto o membro dell’organizzazione (un membro dell’organizzazione che non è membro del progetto viene prima aggiunto come membro senza ambito di schermi o di upload che può approvare le revisioni; la policy per gli ospiti non si applica a un membro dell’organizzazione); chiunque altro è invalid_request in user_id.

Un amministratore si nomina proprietario solo dopo essere entrato nel progetto (POST /api/organizations/{org_id}/projects/{project_id}/access), e chi non è un membro senza ambito di schermi o di upload che può approvare è invalid_request in user_id.

L’effetto è quello del trasferimento da parte del proprietario stesso, quindi l’ambito di schermi e l’ambito di upload del nuovo proprietario vengono azzerati e le responsabilità legacy del progetto vengono assegnate a questa persona. Indicare il proprietario attuale non cambia nulla. La modifica viene registrata nell’audit dell’organizzazione come organization.project_owner_changed, e il proprietario precedente e quello nuovo ricevono un’email.

Il limite di 200 membri del progetto si applica a un membro dell’organizzazione aggiunto (member_limit_reached). Un progetto che l’organizzazione non possiede, o che è stato eliminato, è not_found. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Un amministratore designato rimuove un membro da uno dei progetti live dell’organizzazione senza entrarvi. Ha l’effetto della rimozione da parte del proprietario (DELETE /api/members/{user_id}). L’appartenenza termina, gli inviti email in sospeso della persona al progetto vengono revocati, le sue sessioni smettono di risolvere il progetto e le appartenenze degli agenti restano.

Il proprietario non viene mai rimosso (owner_cannot_leave; trasferire prima la proprietà con PUT /api/organizations/{org_id}/projects/{project_id}/owner). Una persona che non è membro del progetto, anche se già rimossa, e un progetto che l’organizzazione non possiede o che è stato eliminato, sono not_found.

La rimozione viene registrata nell’audit dell’organizzazione come organization.project_member_removed e negli eventi del progetto come member.removed con removed_by_organization_admin true. Solo persone; agenti e credenziali bearer non hanno rotta admin.

Rimuovi un dominio, verificato o in attesa, e lascia gli altri domini dell’organizzazione. La sua collocazione e scoperta futura si fermano, e un’altra organizzazione può verificarlo. I progetti già nell’organizzazione restano. Un dominio che l’organizzazione non possiede né sta provando è not_found.

Finché l’organizzazione richiede il single sign-on, un dominio verificato è resource_conflict; disattivare Require single sign-on ha effetto dopo 72 ore, e il dominio può essere rimosso a quel punto.

Imposta se un membro può approvare: decidere le revisioni e concedere agli agenti l’accesso Gestisci. Un membro che non può approvare ha i suoi agenti limitati a Propose. Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto (altrimenti forbidden); la riga del proprietario è fissa (resource_conflict); un non membro è not_found.

Aggiunge project.member_approver_changed (dettagli user_id, can_approve).

Limita un membro a cartelle di schermi (ciascuna con ogni cartella al suo interno) e a schermi, oppure sostituisce l’ambito di un membro già limitato (docs/screen-scope.md).

In una sola transazione termina anche gli agenti che la persona ha portato nel progetto (agent.disconnected, come farebbe la loro rimozione) e aggiunge project.member_screen_scope_changed (details user_id, screen_scope, previous, changed_by_user_id). L’ambito viene letto alla richiesta successiva del membro: la modifica compare al suo prossimo GET /api/session senza dover accedere di nuovo.

Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto (altrimenti forbidden); la riga del proprietario, un uploader (un membro con ambito è limitato agli schermi, un uploader ai contenuti) e un membro che approva le revisioni con singoli schermi nell’ambito sono resource_conflict; un non membro è not_found; un id che non è una cartella di schermi o uno schermo live del progetto è invalid_request in screen_scope.folder_ids[i] o screen_scope.screen_ids[i].

Un membro con ambito che approva le revisioni approva solo dentro l’ambito; uno che non può approvare legge ed esegue comandi ma cambia ciò che viene riprodotto solo tramite approvatori (approver_required).

Un ambito viene rifiutato con resource_conflict anche mentre la persona, o un agente che la persona ha portato, ha un client di servizio live del progetto: il dettaglio nomina fino a cinque client come ID (nome) e conta gli altri, e non viene scritto nulla.

Limitare una persona agli schermi rientra nell’ambito degli schermi, che il piano Enterprise include; un progetto il cui piano ne è privo viene rifiutato con feature_not_in_plan (402). Un ambito impostato continua a limitare la persona finché non viene cancellato (DELETE), operazione consentita in ogni piano.

Restituisce a un membro con ambito tutti gli schermi del progetto. Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto; un membro senza ambito resta com’è. Aggiunge project.member_screen_scope_changed con screen_scope null.

Limita l’appartenenza di un agente al progetto della sessione a cartelle di schermi e schermi, oppure ne sostituisce l’ambito (docs/screen-scope.md). La portata dell’agente è questo ambito ristretto da quello della persona responsabile, quindi una persona con ambito non agisce mai tramite un agente più ampio di lei.

Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto (altrimenti forbidden); un agente che non è membro del progetto è not_found. Aggiunge agent.screen_scope_changed (dettagli agent_id, screen_scope, previous, changed_by_user_id).

L’ambito di un agente si applica alla sua richiesta successiva sull’istanza che lo ha scritto ed entro due secondi sulle altre. Un ambito viene rifiutato con resource_conflict mentre l’agente ha un client di servizio live del progetto: il dettaglio nomina fino a cinque client come ID (nome) e conta gli altri, e non viene scritto nulla.

Limitare un agente agli schermi rientra nell’ambito degli schermi, che il piano Enterprise include; un progetto il cui piano ne è privo viene rifiutato con feature_not_in_plan (402). Un ambito impostato continua a limitare l’agente finché non viene cancellato (DELETE), operazione consentita in ogni piano.

Rimuove l’ambito dell’appartenenza di un agente al progetto della sessione. Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto. Aggiunge agent.screen_scope_changed con screen_scope null.

Rende un membro un uploader, o sostituisce l’ambito di uno (docs/uploaders.md): le playlist di cui modifica le pagine e le cartelle media in cui carica.

In un’unica transazione impedisce loro anche di approvare revisioni, termina gli agenti che hanno portato nel progetto (agent.disconnected, come farebbe la loro rimozione) e aggiunge project.member_upload_scope_changed (dettagli user_id, upload_scope, changed_by_user_id).

L’ambito viene letto alla richiesta successiva del membro: la modifica compare al suo prossimo GET /api/session senza accedere di nuovo.

Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto (altrimenti forbidden); la riga del proprietario è resource_conflict; un non membro è not_found; un id che non è una playlist o una cartella media live del progetto è invalid_request in upload_scope.playlist_ids[i] o upload_scope.folder_ids[i]. access propose (il valore predefinito) invia le modifiche dell’uploader in revisione; manage le pubblica.

Un membro limitato agli schermi è resource_conflict: rimuovi prima quell’ambito (DELETE /api/members/{user_id}/screen-scope).

Rende di nuovo un uploader un membro completo, che non approva revisioni (attivalo con setDashboardMemberApprover). Solo il proprietario del progetto o un membro che amministra l’organizzazione del progetto; un membro che non è un uploader resta com’è. Aggiunge project.member_upload_scope_changed con upload_scope null.