API Tableau de bord

Inspecte une invitation sans la consommer. Ne rapporte jamais l’état d’inscription ou de vérification, sauf qu’une réinitialisation de connexion rapporte replaces_unverified_account. Une invitation organization_admin ou organization_member rapporte le nom de l’organisation et aucun projet.

Démarre une cérémonie d’enregistrement de cinq minutes liée au condensé et au mode de l’invitation. Link create_login nécessite un cookie __Host-screenrig-signup vérifié et utilise son nom.

Email create_login lie le nom d’affichage fourni ; reset lie la personne cible, sauf qu’une réinitialisation d’une adresse non vérifiée enregistre la clé d’accès pour la nouvelle personne qu’elle crée, nommée d’après le nom d’affichage fourni ou, en son absence, d’après l’adresse.

Cette réinitialisation exige que replace_unverified_account soit true (l’inspection rapporte replaces_unverified_account) et répond sinon 409 unverified_account_replacement.

Démarre une inscription par lien navigateur et révoque les inscriptions antérieures pour cette invitation. Le défi de vérification est lié à cette inscription. L’authentification de développement vérifie l’inscription immédiatement sans courriel.

Retourne l’inscription en direct appartenant à ce navigateur. Un cookie d’inscription manquant, révoqué, consommé ou expiré retourne invitation_invalid.

Accepte une invitation de manière transactionnelle et crée une nouvelle session personne, supprimant l’ancienne session si présente.

Link create_login nécessite le cookie __Host-screenrig-signup vérifié pour cette invitation. signed_in nécessite une session de tableau de bord et une connexion récente ou une preuve fraîche ; la livraison par courriel nécessite un courriel vérifié correspondant, ou l’adresse non vérifiée de la personne connectée, que l’acceptation vérifie.

Une adresse qu’une personne active détient déjà, vérifiée ou non, donne resource_conflict pour create_login. Une réinitialisation connecte la personne qui détient une adresse vérifiée.

Une réinitialisation d’une adresse non vérifiée exige que replace_unverified_account soit true (l’inspection rapporte replaces_unverified_account) et répond sinon 409 unverified_account_replacement sans rien consommer ; avec cette valeur, la réinitialisation crée une nouvelle personne vérifiée avec le justificatif qu’elle enregistre, nommée d’après display_name ou, en son absence, d’après l’adresse, avec une nouvelle organisation et un nouveau projet, et connecte cette personne ; la personne non vérifiée est supprimée (ses sessions, clés d’accès et agents prennent fin) et les projets et organisations qu’elle a créés restent, sans elle et sans plus correspondre à l’adresse comme contact, de sorte qu’aucune réinitialisation ultérieure ne leur renvoie d’invitation d’inscription.

La réponse nomme le nouveau projet. Une session dont la vérification du courriel est requise (email_verification_required sur GET /api/session) accepte uniquement une invitation envoyée par courriel qui nomme sa propre adresse, et reçoit 403 email_verification_required pour toute autre.

Une invitation organization_admin ajoute la personne aux administrateurs de l’organisation et n’ouvre aucun projet ; elle renvoie organization_admin_limit lorsque l’organisation compte déjà 20 administrateurs et reste en attente, et resource_conflict lorsque l’organisation a été supprimée.

Une invitation organization_member fait de l’organisation qui invite l’organisation d’appartenance de la personne, à la place de toute organisation précédente, et n’accorde aucune adhésion à un projet ; elle renvoie managed_elsewhere (409) lorsqu’une autre organisation gère la personne, et resource_conflict lorsque l’organisation a été supprimée.

Une invitation organization_admin ne définit l’organisation d’appartenance que pour une personne qui n’en a pas. Une invitation project_member revérifie la politique relative aux invités de l’organisation et renvoie guest_not_allowed (403) lorsque la personne serait un invité externe que la politique refuse ; une invitation à un projet ne change jamais l’organisation d’appartenance de quiconque. Une invitation refusée reste en attente.

Démarre une cérémonie d’enregistrement de cinq minutes pour une inscription en libre-service, liée à l’adresse courriel normalisée et au nom d’affichage. Elle ne crée rien et n’envoie aucun courriel.

Une adresse qu’une personne active détient, vérifiée ou non, donne 409 account_exists ; une adresse d’un domaine dont l’organisation se connecte par un fournisseur d’identité donne 403 sso_required ; une adresse ou un nom invalide donne 400 invalid_request avec des erreurs de champ. Un serveur qui exécute l’authentification de développement du tableau de bord renvoie passkeys_disabled.

Limité par adresse cliente.

Crée un compte en libre-service et connecte ce navigateur.

Une seule transaction crée la personne avec une adresse courriel non vérifiée et un délai de vérification de 72 heures, enregistre la clé d’accès issue de la cérémonie que POST /api/signups/passkey-options a démarrée, crée l’organisation et le projet de la personne comme le fait l’inscription d’un agent, fait de la personne le propriétaire du projet, stocke le choix concernant les courriels de marketing, et met en file d’attente le courriel de vérification (purpose account_email).

Le visiteur du site web qui a ouvert la page est lié au compte et l’inscription est comptée comme signed_up. La réponse définit le cookie de session du tableau de bord. Les refus sont ceux de POST /api/signups/passkey-options ; une cérémonie utilisée, expirée ou non concordante donne 400 invalid_request. Limité par adresse cliente et par adresse courriel.

Bascule vers un des projets de la personne et met à jour son dernier temps d’utilisation. Un membre du personnel peut aussi basculer vers un projet qu’il suit en mode shadow ; cette session indique shadow true, est en lecture seule et ne met pas à jour le dernier temps d’utilisation. Tout autre projet renvoie not_found.

Liste les membres du projet actuel sans leurs adresses courriel privées.

Tous les membres ont la même autorité, sauf la gestion des membres (retrait, approbation, périmètres, propriété), qui revient au propriétaire et à un administrateur de l’organisation du projet qui en est membre. owner marque le propriétaire du projet, external marque un invité (l’organisation d’appartenance du membre n’est pas celle du projet), et viewer_user_id et viewer_is_owner décrivent la personne connectée.

Supprime un membre du projet actuel. Le propriétaire du projet supprime tout autre membre, tout comme un administrateur de l’organisation du projet qui en est membre ; tout membre peut se supprimer pour partir. Le propriétaire n’est jamais supprimé ni ne part (owner_cannot_leave ; transférez d’abord la propriété). Un membre qui supprime quelqu’un d’autre se voit refuser l’opération avec owner_required.

Une personne qui n’est pas membre, y compris une personne déjà retirée, donne not_found. Dans une transaction, l’adhésion prend fin, les invitations par courriel en attente de cette personne au projet sont révoquées, et l’événement de projet member.removed est ajouté (détails user_id, removed_by_user_id, left).

Les sessions de la personne cessent de résoudre le projet à leur prochaine requête et reviennent comme après une suppression de projet. Les adhésions des agents sont distinctes et restent. Personnes seulement ; pas de route pour les identifiants porteurs.

L’activité d’une personne dans le projet courant, la plus récente en premier : ses connexions (et connexions refusées nommant leur adresse ou passkey), déconnexions, passages dans le projet, changements de credential, preuves de réauthentification et chaque changement fait via le tableau de bord, refusés et échoués inclus. Les lectures ne sont jamais enregistrées.

Les requêtes d’agent et CLI sont sur leurs agents (listDashboardAgentEvents). L’ombre d’un membre du personnel du projet n’enregistre rien ; un changement effectué sous un bail d’écriture approuvé par le personnel est une ligne de ce membre avec source personnel.

La personne elle-même, le propriétaire du projet, un administrateur de l’organisation du projet et un membre du personnel suivant le projet peuvent le lire. Toute autre personne reçoit not_found, tout comme une personne qui n’est ni membre ni n’a de lignes ici, donc la réponse ne révèle jamais qui appartient ; les lignes d’un ancien membre restent lisibles.

Le projet appartient à la session, jamais à la requête, et seules les lignes de ce projet sont jamais retournées.

Chaque valeur est dérivée du serveur : l’action de la route que le serveur a appariée (ou une action de compte nommée telle que session.sign_in ou passkey.add), la ressource de la première valeur de chemin de la route quand c’est un identifiant émis par le serveur, status, problem_code et error du registre de problèmes, le client analysé depuis l’User-Agent et l’indice de plateforme (l’User-Agent brut n’est pas conservé).

Aucun corps de requête, mot de passe, jeton ou cookie n’est stocké. client_ip et courriel sont affichés tels qu’enregistrés.

Les clés de pagination sont (at, id) en ordre décroissant. Passez next_cursor comme after pour continuer ; il est nul à la fin. Une ligne écrite entre-temps ne se place qu’avant la première page et la rétention supprime les lignes les plus anciennes, donc un curseur ne se répète ni ne saute une ligne survivante. Un curseur ou filtre mal formé est refusé avec invalid_request ; une limite hors plage 1-100 est la valeur par défaut.

Les lignes expirent selon la fenêtre de conservation des événements du projet au moment où elles ont été écrites. recorded_since est l’heure de la plus ancienne ligne survivante du projet, ou, avant toute ligne, quand ce serveur a commencé à enregistrer ; rien avant cela n’est reconstruit.

Retourne le profil et le nombre d’accréditations de la personne connectée.

Marque la personne connectée comme supprimée. Protégé par preuve : le corps porte une preuve de connexion fraîche vérifiée contre une réauthentification liée à cette session avec type account_delete et subject_id égal à l’identifiant utilisateur de la personne connectée (commencez par POST /api/me/reauthentications). Sans réauthentification actuelle, la réponse est reauthentication_required.

En cas de succès, la réponse est 204, le cookie de session du tableau de bord est effacé, et le cache HTTP du navigateur pour l’origine du tableau de bord est effacé comme lors de la déconnexion.

Démarre une montée en puissance clé d’accès liée à la session, au type et au sujet. Une personne sans clé d’accès reçoit resource_conflict et utilise une preuve de mot de passe.

Définit ou remplace le mot de passe de la personne après une preuve récente. Le premier mot de passe nécessite une preuve passkey ; le remplacement accepte le mot de passe actuel ou une passkey. Révoque les autres sessions et met en file un avis de changement de connexion.

Une personne dont l’adresse courriel n’est pas vérifiée, comme une personne inscrite en libre-service avant qu’elle la vérifie, ne peut pas définir de mot de passe et reçoit 403 email_verification_required.

Liste les clés d’accès de la personne avec ce dont un client a besoin pour garder le gestionnaire de mots de passe du navigateur synchronisé avec elles (l’API Signal de WebAuthn). La liste porte l’ID de la partie dépendante et le user handle sous lesquels les clés d’accès sont enregistrées, et chaque clé d’accès porte son ID de justificatif et le fournisseur que son authentificateur a signalé.

Vérifie une preuve récente et démarre une inscription liée à la session et à la personne. Les passkeys sont désactivées sous l’authentification en développement.

Stocke la nouvelle clé d’accès, révoque les autres sessions de la personne et met en file un avis de changement de connexion. Une clé d’accès envoyée sans nom porte le nom de son fournisseur, ou Passkey lorsque son authentificateur n’en a signalé aucun que la liste connaisse.

Renomme une clé d’accès appartenant à la personne connectée.

Supprime une passkey après preuve récente et envoie un avis de changement de connexion. Supprimer la dernière méthode de connexion retourne last_credential. Une personne dont le compte requiert une passkey (tout membre du personnel) ne peut pas supprimer sa dernière passkey ; cela retourne 409 resource_conflict.

Retourne l’état du courriel vérifié et en attente de la personne. Une personne qui s’est inscrite elle-même détient une adresse non vérifiée jusqu’à ce qu’elle ouvre le lien envoyé à cette adresse ; email_verified est false et verify_by est la date limite, après laquelle la session peut utiliser uniquement les routes qui vérifient ou changent l’adresse (email_verification_required sur GET /api/session).

Demande un changement de courriel après une preuve fraîche. L’adresse vérifiée reste en vigueur tant que la vérification est en attente. Une adresse qu’une autre personne active détient, vérifiée ou non, donne user_email_conflict. L’ancienne adresse reçoit un avertissement, pas un lien d’annulation.

Une personne dont l’adresse n’est pas vérifiée la change de la même façon ; la vérification de la nouvelle adresse en fait l’adresse vérifiée de la personne et efface verify_by.

Met en file d’attente un nouveau lien de vérification. Tant qu’un changement de courriel attend sa vérification (pending_email sur GET /api/me/email), c’est le lien de ce changement, envoyé à l’adresse en attente ; sinon c’est un lien account_email pour l’adresse non vérifiée actuelle de la personne. Dans les dix minutes suivant le dernier lien du même genre, il ne met rien en file d’attente et répond quand même 202.

Une personne dont l’adresse est vérifiée et qui n’a aucun changement en attente donne 409 resource_conflict.

Remplace par le corps les réponses que la personne a données après son inscription ; le corps contient toutes les réponses jusqu’ici, et un membre omis, ou null, est sans réponse. Chaque membre a un ensemble de valeurs fermé, et une valeur hors de cet ensemble donne 400 invalid_request avec une erreur de champ.

Le profil est conservé avec la personne et montré au personnel de screenRIG avec l’organisation dans laquelle la personne s’est inscrite.

Où une application web du projet de la session est placée, calculé en un seul passage sur les listes de lecture du projet et une lecture des écrans qui les détiennent. placements sont les primitives d’application dont le propriétaire d’application stocké est cette application, dans l’ordre des listes de lecture (celui de la liste des listes de lecture), puis des pages et des primitives ; une liste de lecture qui la place deux fois en a deux. release indique comment chaque version épinglée se situe par rapport à latest_ready_release de l’application : latest, older ou unknown tant qu’elle n’en a pas. screens sont les écrans pairing_pending et actifs qui ont une liste de lecture d’un placement comme liste par défaut, dans leur horaire ou en prise de contrôle, ou qui en affichent actuellement une, les plus récents d’abord ; les écrans archivés ne comptent jamais, et un écran dont le Player ne peut pas afficher d’applications web porte applications_unsupported.

Un membre ou un agent limité à des écrans (screen_scope) ne voit que ses écrans, et screen_count ne compte que ceux-là. Ce n’est pas ce qui bloque la suppression : ce sont les autorisations d’exécution (le manifeste d’un écran qui détient une version). Un ID que le projet ne détient pas est not_found comme pour getApplication. La réponse est privée et no-store.

Où un média prêt du projet de la session est utilisé, calculé en un seul passage sur les listes de lecture du projet et une lecture des écrans qui les détiennent. playlists sont celles qui nomment le fichier (les ID statiques d’une primitive image ou vidéo et un sélecteur par id ou ids, le repli d’un flux, une chaîne media:<id> dans les paramètres d’une carte, le logo d’un stinger, une piste de la bande sonore), puis celles dont les sélecteurs d’étiquette, de dossier ou all l’atteignent, chaque groupe dans l’ordre de la liste des listes de lecture ; une liste de lecture est une entrée dont uses énumère chaque façon, les types exacts d’abord.

Les sélecteurs sont évalués comme le runtime les résout : un filtre d’étiquette correspond à tag et tags du fichier, un sélecteur de dossier aux fichiers directement dans le dossier, un sélecteur all à tous les fichiers de ce type, et un fichier en attente selon les étiquettes et le dossier de sa dernière approbation (un fichier jamais approuvé n’est atteint par aucun).

La rotation (batch_size, one_at_a_time), les fenêtres de disponibilité, l’ajustement au format et la visibilité d’une page ne sont pas évalués. screens sont les écrans pairing_pending et actifs qui ont l’une de ces listes de lecture comme liste par défaut, dans leur horaire ou en prise de contrôle, ou qui l’affichent actuellement, les plus récents d’abord ; les écrans archivés ne comptent jamais.

Un membre ou un agent limité à des écrans (screen_scope) ne voit que ses écrans, et screen_count ne compte que ceux-là. Un ID que le projet ne détient pas, ou un média qui n’est pas prêt, est not_found comme pour getMedia. La réponse est privée et no-store.

Retourne un petit WebP avec perte d’une image prête appartenant au projet de la session, pour que les grilles du tableau de bord ne décodent jamais les originaux. Il y a une taille : elle tient dans 512 x 512 avec le ratio conservé et n’est jamais agrandie, et une image animée montre sa première image.

La première requête la génère et la stocke à côté de l’original ; les requêtes suivantes diffusent la copie stockée, et la suppression du média la retire avec l’original. L’identifiant d’un autre projet, vidéo, audio, et média non prêt renvoient not_found. La plage n’est pas acceptée.

L’ETag est fort et nomme l’original et le générateur de vignette, donc il est identique à chaque requête et hôte. La réponse est privée, sans cache, et un If-None-Match correspondant, vérifié après résolution du média dans le projet de la session, renvoie 304 sans lire la vignette. Les octets complétés sont enregistrés comme sortie dashboard_media.

Applique les mêmes règles de propriété, conditionnelles et de génération que getDashboardMediaThumbnail et renvoie ses en-têtes sans le corps. Aucune sortie n’est enregistrée.

Vérification sécuritaire pour scanner. Elle ne vérifie jamais une adresse, ne modifie pas un utilisateur et ne connecte pas le visiteur. Elle rapporte le but et l’état du lien ; un lien account_email en attente ne vérifie que pour une requête qui porte la session de tableau de bord de la personne, de sorte qu’une page demande la connexion avant de demander la confirmation.

La confirmation humaine explicite consomme un défi de vérification lié à un but. Les défis d’inscription par lien nécessitent le cookie __Host-screenrig-signup correspondant ; les défis de changement de courriel sont liés au jeton, de sorte que le lien fonctionne dans n’importe quel navigateur.

Un défi account_email (envoyé par courriel à l’inscription en libre-service et par POST /api/me/email/verification, valide 30 jours) s’ouvre dans n’importe quel navigateur, mais ne vérifie que pour une requête qui porte une session de tableau de bord active de la personne visée par le lien, y compris une session que email_verification_required limite à cette route.

Sans session, ou avec celle d’une autre personne, elle répond 200 sign_in_required, ne vérifie rien et laisse le lien utilisable. Un lien account_email vérifié marque l’adresse de la personne comme vérifiée et met fin au délai de vérification ; il répond superseded lorsqu’une autre personne a vérifié la même adresse en premier. La vérification ne connecte jamais le visiteur.

Démarre une cérémonie d’assertion WebAuthn sans nom d’utilisateur et retourne les options de requête telles quelles pour navigator.credentials.get. Aucun cookie requis, et aucune liste allowCredentials publiée, donc la route ne révèle rien sur les utilisateurs ou identifiants existants. La cérémonie expire avec DashboardCeremonyTTL de cinq minutes.

Lorsque le serveur exécute l'authentification de développement du tableau de bord, cette route renvoie passkeys_disabled.

Vérifie une assertion sans nom d’utilisateur et crée le cookie de session du tableau de bord pour l’utilisateur identifié par l’identifiant découvrable. Aucun cookie n’authentifie la requête. Une cérémonie inconnue, expirée ou déjà utilisée retourne passkey_invalid, tout comme une assertion que la partie dépendante ne peut vérifier ou un compteur de signature qui recule.

Une cérémonie valide dont l’identifiant du justificatif n’est enregistré pour personne (aucun justificatif stocké ne le possède, quelle que soit la personne) retourne plutôt 401 passkey_unknown ; cette réponse ne vaut que pour ce seul cas, de sorte qu’un client peut demander au navigateur d’oublier le justificatif (PublicKeyCredential.signalUnknownCredential) sur celle-ci et sur aucune autre.

L’identifiant du justificatif n’autorise rien à lui seul : c’est l’assertion signée qui autorise. Une personne dont l’adresse vérifiée appartient à un domaine dont l’organisation exige l’authentification unique est refusée avec 403 sso_required, sauf s’il s’agit d’un administrateur d’urgence de cette organisation; une telle ouverture de session est auditée.

Lorsque le serveur exécute l'authentification de développement du tableau de bord, cette route renvoie passkeys_disabled.

Connecte la personne identifiée par courriel et mot de passe vérifiés. Courriel inconnu, absence de mot de passe et mot de passe erroné renvoient la même réponse non autorisée. Ouvre le projet utilisé en dernier s’il y a toujours une adhésion, sinon l’adhésion la plus récente, ou aucun projet.

Une adresse d’un domaine dont l’organisation exige l’authentification unique est refusée avec 403 sso_required avant toute recherche de compte, de sorte que la réponse ne dépend pas de la détention de l’adresse par une personne ; POST /api/sso/starts connecte cette personne par son fournisseur d’identité.

La connexion par mot de passe exige un courriel vérifié, donc une personne qui s’est inscrite elle-même (POST /api/signups) se connecte avec sa clé d’accès, et celle qui a défini un mot de passe sur une adresse non vérifiée reçoit toujours la réponse unauthorized. L’authentification de développement utilise ce même flux de mot de passe.

Retourne la session actuelle du tableau de bord. Le cookie de session et la session côté serveur établissent l’autorité ; user_id est descriptif. Une réponse 401 signifie qu’une connexion est requise.

Le champ dev_auth est réservé au développement local et est faux sur le service hébergé. organization est l’organisation d’appartenance de la personne, absente tant qu’elle n’en a pas ; project.organization_admin indique que la personne administre l’organisation du projet actuel.

Supprime la ligne de session côté serveur et expire le cookie de session. Ne supprime pas l’utilisateur et ne retire aucune preuve. Est intrinsèquement idempotent et ne prend aucun Idempotency-Key.

Une déconnexion réussie efface aussi le cache HTTP du navigateur pour l’origine du tableau de bord, supprimant les octets privés, no-cache de médias, captures d’écran et revue de pub vus par la session ; une session qui expire seulement les laisse jusqu’à ce que le navigateur les évince.

Signale une étape du passage d’un navigateur dans les flux d’entrée du tableau de bord (inscription, connexion, réinitialisation, invitation et ajout d’une clé d’accès) pour la lecture de l’intégration réservée au personnel. Public : il fonctionne avec ou sans session de tableau de bord.

Le parcours est l’ID aléatoire propre au navigateur ; le serveur conserve aussi le cookie de visiteur de la périphérie lorsque la requête en porte un, ainsi que la personne et l’organisation lorsqu’elle porte une session. Un parcours est réservé au personnel et conserve les valeurs réelles saisies par les personnes (adresses, noms, réponses) ; il ne reçoit jamais de mot de passe, de code ni de jeton.

La première valeur de mode, source, utm_source, utm_medium, utm_campaign, click_kind, site_trail et site_cta est conservée ; chaque étape conserve son premier horodatage, et value et detail d’une étape ainsi que le courriel du parcours (provenant de email_submitted) sont les plus récents. source n’est acceptée qu’avec entry_viewed. question est obligatoire avec les étapes question_* et refusée avec toute autre. detail est un code de problème pour une étape *_failed, la méthode de connexion pour signed_in, ou connected ou skipped pour signup_finished. email_verified, email_gate_reached, site_visited, site_cta_clicked et les jalons du compte sont écrits ou dérivés par le serveur et sont refusés ici.

Seules les longueurs sont limitées. Limité par adresse cliente.

Liste chaque agent en attente, actif, révoqué, annulé et expiré du projet de session avec métadonnées d’installation sécurisées, dernière utilisation, nombre de requêtes authentifiées et crédits mesurés directement attribuables. Aucun octet de porteur, clé destinataire, enveloppe ou identifiant de projet n’est retourné.

L’historique de cet agent, du plus récent au plus ancien, comme UN enregistrement par déclencheur. Il contient ce que l’agent a demandé et ce qui a changé en conséquence. Une requête qui a modifié quelque chose est son événement de domaine, estampillé avec la commande qui l’a causé. Une requête qui n’a rien changé — refusée, échouée ou un succès sans événement — est un événement agent.command.

Il n’y a pas de point de terminaison commandes séparé ; afficher le même déclencheur sur deux panneaux était le défaut que ceci remplace. Les événements du cycle de vie pour cet agent sont inclus. L’activité des workers, players et dashboard uniquement n’est jamais inférée comme activité d’agent. Deux requêtes sont deux déclencheurs. Une nouvelle tentative après un refus est un second enregistrement, jamais une réécriture du premier.

Les lectures ne sont pas enregistrées, car elles ne changent rien et un agent de sondage enterrerait chaque action réelle. L’inscription anonyme est exclue. Chaque partie du tampon de commande est dérivée de la route que ce serveur a appariée ou du registre de problèmes.

Il n’y a pas de vecteur d’argument, pas de corps de requête, pas d’en-tête, et pas de texte libre nulle part dans un enregistrement, donc rien à expurger et aucun appelant ne peut écrire un texte choisi dans une surface visible par l’opérateur. Les identifiants de ressource apparaissent parce qu’un identifiant n’est jamais une autorisation et est déjà publié sur les événements. Clés de pagination sur séquence, décroissant.

Passez le next_cursor retourné en tant que after pour continuer. next_cursor est vide quand la page est courte, ce qui est la fin de l’historique : un ajout concurrent prend seulement une séquence plus élevée, et la rétention supprime d’abord les séquences les plus basses, donc un curseur ne duplique ni ne saute jamais un enregistrement survivant. Le pagination par offset n’est pas supportée.

Chaque paramètre de recherche est un prédicat d’égalité ou de plage sur un jeton écrit par le serveur. Un curseur ou une valeur de filtre malformé est refusé avec invalid_request. Une limite hors de 1-200 est ramenée à la valeur par défaut plutôt que refusée. Les enregistrements expirent selon la fenêtre de rétention d’événements propre au projet.

Déconnecte l’agent du projet sélectionné après une nouvelle preuve. Le projet doit être l’une des adhésions de la personne. Les connexions et les émissions d’identifiants en attente sont annulées ; aucun jeton de remplacement n’est émis. Un membre limité aux écrans ne connecte pas d’agents, n’émet pas d’identifiants et ne gère pas les personnes du projet : outside_screen_scope (demandez au propriétaire du projet).

Les notes que cet agent a écrites dans le projet de session, les plus récentes d’abord, ouvertes et résolues. state est all (par défaut), open ou resolved. Passez next_cursor en tant que after ; il est vide à la dernière page. Les corps des notes sont du texte brut écrit par un agent ; affichez-les comme du texte, jamais en HTML ou Markdown.

Résout une des notes ouvertes de l’agent en tant que personne connectée, avec une raison obligatoire ; resolution.by nomme la personne. Ajoute note.resolved avec la personne comme acteur. Une note résolue est note_not_open.

Supprime une des notes de l’agent, ouverte ou résolue, en tant que personne connectée. Ajoute note.deleted avec la personne comme acteur.

Les demandes de connexion en attente adressées au projet de session, qu’un membre peut examiner et approuver : demandes nommant le projet, et connexions ou connexions d’appareil par une identité agent déjà membre.

La connexion d’une nouvelle installation n’est pas listée (son indice de projet est fourni par le client) ; une personne y accède par son code utilisateur (POST /api/agent-connections/lookup).

Résout le code utilisateur d’une connexion d’appareil en attente (`screenrig login`), tel que saisi ou prérempli sur la page de connexion, vers sa connexion, dont la vue d’approbation l’affiche ensuite. N’approuve rien. Les séparateurs, espaces et casse sont ignorés. Un code inconnu, utilisé ou invalide est agent_connection_invalid ; un code expiré est agent_connection_expired.

Limité à 5 consultations par session du tableau de bord par 10 minutes, 20 par adresse client par heure et 1200 par heure pour toute la flotte (rate_limited). Un membre limité aux écrans ne connecte pas d’agents, n’émet pas d’identifiants et ne gère pas les personnes du projet : outside_screen_scope (demandez au propriétaire du projet).

Retourne les métadonnées de révision de connexion sécurisée. La révision ne sélectionne pas de projet ; l’approbation sélectionne un des adhésions de la personne.

Approuve la connexion pour le projet sélectionné après une nouvelle preuve et crée un agent en attente. Le projet doit être l’une des adhésions de la personne. Renvoie des métadonnées sûres, jamais le jeton porteur. Un membre limité aux écrans ne connecte pas d’agents, n’émet pas d’identifiants et ne gère pas les personnes du projet : outside_screen_scope (demandez au propriétaire du projet).

Refuse la connexion pour le projet sélectionné après une nouvelle preuve sans créer d’agent. Le projet doit être l’une des adhésions de la personne. Un membre limité aux écrans ne connecte pas d’agents, n’émet pas d’identifiants et ne gère pas les personnes du projet : outside_screen_scope (demandez au propriétaire du projet).

Une requête pour la coquille du tableau de bord.

Chaque membre est le corps que la route nommée renvoie pour cette même session (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 et /api/reviews?state=all&limit=1), produit par le gestionnaire propre à cette route, selon ses propres vérifications d’autorisation, de forfait et de portée.

Un membre est absent lorsque sa route ne répondrait pas 2xx pour cette session (un refus, un rôle ou un forfait qui ne peut pas la lire, aucun projet actuel, une défaillance), et le tableau de bord lit alors cette route lui-même. advertising_network est null lorsque sa route répondrait 404 not_found parce que le projet n’a pas de réseau.

Une session sans projet actuel reçoit les membres qui n’exigent aucun projet.

Compteurs d’état réseau du projet pour le projet de la session. Les comptes d’écrans en ligne sont dérivés des flux d’événements d’exécution jumelés en direct, la même dérivation que Screen.online publie ; ce ne sont pas des booléens stockés ni un battement de cœur du lecteur. Les octets médias sont les octets durables des médias prêts uniquement.

État véridique de la capacité de paiement. rails_available est faux et unavailable_reason est financial_rails_unavailable tandis que les rails carte, fiscal et retrait sont indisponibles. Aucune information bancaire brute n’est retournée.

Un reçu/document fiscal finalisé appartenant à l’appelant. Aucun reçu n’existe tant que la collecte d’argent n’est pas expédiée, donc c’est not_found plutôt qu’un document fabriqué.

Retourne le solde public de crédits entiers du projet de session. Cette lecture authentifiée par cookie ne débite jamais, donc elle reste disponible à zéro. Le tableau de bord uniquement cookie ne présente jamais un porteur de projet à GET /api/project.

Génère un ticket de lancement unique de trente secondes pour la dernière version prête d’une application appartenant au projet de la session, sur l’hôte d’aperçu exact de cette version, jamais sur l’hôte de version que les Players affichent, ainsi un Player et le tableau de bord dans un même navigateur ne partagent jamais les documents mis en cache ni ne transmettent de cookie de cet hôte.

Le ticket se convertit en cookie release-grant uniquement sur cet hôte, donc l’aperçu est cross-origin par construction et le code de l’application Web ne peut jamais lire un cookie dashboard. La réponse release_id identifie la version exacte retenue pour ce lancement, même si une autre publication se termine plus tard. Assignez launch_url à iframe.src et à rien d’autre.

L’autorité ici est l’autorité du propriétaire : le projet de la session possède l’application. C’est une source d’autorité secondaire délibérée aux côtés de l’autorité exacte du manifeste actuel pour screenrig.webapp-package/v1, et elle est limitée à cette opération. Ne la généralisez pas aux médias ou au contenu protégé du runtime.

Il n’y a pas de lecteur parent, donc le SDK navigateur et le pont clé-valeur échouent en mode fermé et l’aperçu est uniquement une présentation. Une application sans version prête est resource_conflict.

Une organisation telle que la présente à l’appelant un élément de GET /api/organizations, avec admin, home et reseller. Une personne connectée la lit si elle l’administre, si elle administre le revendeur auquel elle est déléguée, si elle fait partie du personnel, ou si elle la verrait dans cette liste (membre de l’un de ses projets actifs, ou organisation qui est son organisation d’appartenance).

Toute autre personne reçoit un 404 not_found, de même que pour une organisation qui n’existe pas. N’accorde aucune adhésion à un projet. Sessions par cookie seulement; un identifiant d’agent est refusé.

Les administrateurs d’organisation lisent uniquement les noms de projets, propriétaires, statuts et nombres d’écrans ; cela ne donne aucun accès aux projets. Un administrateur ne lit le contenu d’un projet qu’après l’avoir rejoint (POST .../projects/{project_id}/access), et gère ses personnes avec les routes de propriétaire et de membres ci-dessous.

Les revendeurs actifs dont la personne connectée administre l’organisation (admin_user_ids), ordonnés par nom; vide pour toute autre personne. Sessions par cookie seulement. Un revendeur est une organisation que le personnel a désignée comme revendeur ou que l’un de ses administrateurs a inscrite (POST /api/resellers); ses administrateurs gèrent les organisations de ses clients (docs/resellers.md).

Un administrateur d’une organisation en fait un revendeur sur-le-champ. L’appelant doit être une personne connectée dont l’adresse courriel est vérifiée (sessions par cookie seulement; les agents et les clients de service ne détiennent jamais l’autorité de revendeur) et un administrateur de l’organisation désignée par organization_id; toute autre personne reçoit un 404 not_found.

Le revendeur démarre à 2000 points de base du prix de liste (20%), en vigueur dès maintenant, et est en attente d’examen; il peut intégrer jusqu’à 10 clients actuels (customer_limit) jusqu’à ce que screenRIG l’examine. L’organisation doit être active, ne pas être déjà un revendeur, ne pas être cliente d’un revendeur et ne pas relever du forfait du personnel ou promo (409 reseller_conflict, le détail en nomme la raison).

Ajoute reseller.enrolled au journal d’audit de l’organisation.

Un revendeur que l’appelant administre, avec sa marge. Toute autre personne reçoit un 404 not_found.

Les clients actuels du revendeur (les organisations qui lui sont déléguées), ordonnés par nom, avec forfait, nombres et octets stockés. Réservé aux administrateurs du revendeur; toute autre personne reçoit un 404 not_found.

Crée une organisation cliente déléguée au revendeur dès sa création, au forfait Standard, avec l’administrateur du revendeur appelant comme seul administrateur. L’organisation d’appartenance de l’appelant ne change pas. Les administrateurs de l’organisation peuvent ensuite mettre fin à la délégation (DELETE /api/organizations/{org_id}/reseller).

Ajoute organization.created et reseller.customer_started au journal d’audit de l’organisation. Un revendeur en attente d’examen (review_state pending) intègre jusqu’à customer_limit clients actuels; au-delà, la réponse est 409 reseller_conflict.

Un client actuel du revendeur. Réservé aux administrateurs du revendeur; une organisation qui n’est pas un client actuel répond 404 not_found.

Définit le forfait d’un client actuel, que le revendeur paie. standard retire le forfait; plus et premium sont toujours permis, education seulement pour une organisation admissible au forfait Education. Enterprise, staff et promo sont attribués par le personnel.

Une mise à niveau s’applique immédiatement, une rétrogradation ou une suppression au prochain début de mois UTC, comme les changements de forfait d’une organisation (docs/billing-rollup.md). Ajoute reseller.customer_plan au journal d’audit de l’organisation.

Les projets actifs d’un client actuel, avec leur nom, leur statut, leur nombre d’écrans et l’indication que l’appelant en est déjà membre ou non. La liste n’accorde aucun accès aux projets; POST .../access permet d’en rejoindre un.

Fait de l’administrateur du revendeur appelant un membre à part entière du projet d’un client actuel (can_approve, sans périmètre, source reseller_admin), comme le fait l’adhésion d’un administrateur d’organisation, afin qu’il puisse l’ouvrir avec PUT /api/session/project. Une personne déjà membre reçoit le projet inchangé.

Ajoute member.added_by_reseller au projet et reseller.project_joined au journal d’audit de l’organisation, et envoie un courriel au propriétaire du projet. L’adhésion demeure jusqu’à son retrait; mettre fin à la délégation ne la retire pas.

Ce que le revendeur doit pour un mois UTC. Une ligne par client délégué à un moment quelconque du mois, avec la part de ses frais d’usage, dans la portion déléguée du mois, que son propre crédit n’a pas couverte (au prix de liste et au prix du revendeur), et le prix annuel de son forfait.

Le prix du revendeur est le prix de liste moins la marge en vigueur à la plus tardive de ces deux dates : le début du mois et la (re)création du revendeur. Réservé aux administrateurs du revendeur.

Un administrateur de l’organisation met fin immédiatement à sa délégation à son revendeur. Dès lors, l’organisation paie pour elle-même; son forfait, ses projets et ses membres restent tels quels, y compris les adhésions que détiennent les administrateurs du revendeur. Le dépassement que son portefeuille a accumulé pendant la délégation, et dont le revendeur est facturé, est radié dans la même opération.

Ajoute reseller.customer_ended au journal d’audit de l’organisation. Une organisation sans revendeur répond 404 not_found.

Projets ailleurs dont les propriétaires ont un courriel vérifié sur le même domaine vérifié exact. Les adresses de contact et sous-domaines ne correspondent pas, et les administrateurs ne peuvent pas rapatrier les projets.

Ouvrez un défi DNS TXT de 7 jours pour un domaine, remplaçant le défi en attente de ce domaine ; les autres domaines de l’organisation restent inchangés. Mettez sa valeur exacte à son nom DNS retourné et gardez-la là. Une organisation détient au maximum 20 domaines, vérifiés et en attente ensemble (resource_conflict). Un domaine détenu par une autre organisation est resource_conflict.

Un domaine que cette organisation détient déjà peut être prouvé à nouveau, ce qui enregistre la nouvelle valeur pour la vérification DNS quotidienne.

Vérifiez un défi non expiré contre DNS et ajoutez son domaine à l’organisation, en plus des domaines déjà détenus. Chaque domaine exact appartient à une organisation. Une preuve tournée pendant la recherche est refusée. Gardez l’enregistrement TXT en place ; une vérification quotidienne supprime un domaine dont l’enregistrement reste absent pendant sept jours.

Une fois la réclamation engagée, et en arrière-plan après cette réponse, chaque projet dont le propriétaire est une personne vérifiée exactement au domaine et qui est seul dans l’organisation personnelle de ce propriétaire est déplacé dans cette organisation (renommée « <name> (<owner>) » en cas de conflit de nom).

Les projets dans toute autre organisation, les projets disposant d’un forfait payé par le client, et les projets dont le propriétaire ou le personnel a été déplacé hors d’une organisation de domaine restent où ils sont ; un projet refusé par les limites de l’organisation est réessayé un jour plus tard. Le placement ne donne aucun accès.

Un administrateur désigné lit les administrateurs de l’organisation, les candidats pouvant le devenir (propriétaires vérifiés et actifs de ses projets en direct qui ne sont pas encore administrateurs) et la révision de l’organisation. Toute autre personne est refusée comme sur les autres routes admin de l’organisation. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné remplace les administrateurs de l’organisation. If-Match porte la révision de l’organisation ; une révision obsolète est revision_conflict avec current_revision. L’ensemble nomme de 1 à 20 personnes, chacune administrateur actuel ou candidate, sinon invalid_request ; un administrateur ne peut se retirer que si un autre administrateur reste.

Le changement incrémente la révision, est enregistré dans l’audit de l’organisation, n’accorde aucune adhésion au projet et renvoie la même forme que GET. Personnes seulement ; les agents et les identifiants porteurs n’ont pas de route admin.

Un administrateur désigné lit les personnes de l’organisation. Lecture seule. projects liste les projets actifs de l’organisation, ordonnés par nom, au maximum 500. people est l’union des membres de l’organisation (member true), des adhésions actives à ces projets (les adhésions suspendues sont exclues) et des administrateurs désignés.

Le tri place d’abord les administrateurs, puis les membres de l’organisation, puis les personnes externes (celles qui ne sont pas membres de l’organisation), chaque groupe par nom d’affichage puis courriel.

Chaque personne porte son rôle dans chaque projet (owner ou member), si elle peut y approuver les révisions (can_approve) et si elle est limitée aux écrans ou aux téléversements (limited), si elle est administrateur, si elle est membre de l’organisation (member), si l’organisation la gère (managed) et, pour une personne externe, si la politique actuelle relative aux invités ne l’admettrait pas (outside_guest_policy).

Un administrateur ou un membre de l’organisation sans projet apparaît avec une liste projects vide. email est vide pour une personne dont l’adresse n’est pas vérifiée. Les personnes et agents désactivés n’apparaissent jamais. Au maximum 500 personnes sont retournées, les administrateurs toujours parmi elles ; truncated est vrai lorsque des personnes, projets ou adhésions ont été omis.

Toute autre personne est refusée comme sur les autres routes administrateur d’organisation. Uniquement des personnes ; les agents et les identifiants porteurs n’ont pas de route.

Un administrateur désigné liste les invitations d’administrateur de l’organisation par id, 50 à la fois, après expiration de celles dont le temps est écoulé. Les adresses des destinataires sont visibles par les administrateurs de l’organisation, qui les ont fournies. Les jetons et URL d’identification ne sont jamais listés. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné invite des personnes par courriel à devenir administrateurs. L’acceptation ajoute la personne aux administrateurs de l’organisation et crée leur connexion si elle n’en a pas ; cela n’accorde aucune adhésion au projet. Au maximum 20 administrateurs en comptant les invitations d’administrateur en attente (organization_admin_limit) ; une adresse dont la personne administre déjà l’organisation est invalid_request.

Les invitations par courriel expirent après sept jours ; une invitation en attente à la même adresse est réutilisée. Les noms de l’organisation et de l’invitant doivent convenir à un courriel. Personnes seulement ; les agents et les justificatifs porteurs n’ont pas de route d’administration.

Un administrateur désigné révoque une invitation d’administrateur en cours et libère sa place d’administrateur. Une invitation déjà révoquée renvoie 204 ; une invitation acceptée renvoie invitation_consumed ; un id que l’organisation ne détient pas est not_found. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné liste les invitations de membre de l’organisation par id, 50 à la fois, après expiration de celles dont le temps est écoulé. Les adresses des destinataires sont visibles par les administrateurs de l’organisation, qui les ont fournies. Les jetons et URL d’identification ne sont jamais listés. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné invite des personnes par courriel à se joindre à l’organisation comme membres. L’acceptation fait de cette organisation l’organisation d’appartenance de la personne, à la place de toute organisation précédente, et crée sa connexion si elle n’en a pas ; elle n’accorde aucune adhésion à un projet.

Une adresse dont la personne est déjà membre de l’organisation donne invalid_request ; une adresse dont la personne est gérée par une autre organisation donne managed_elsewhere. Les invitations par courriel expirent après sept jours ; une invitation en attente à la même adresse est réutilisée. Les noms de l’organisation et de l’invitant doivent convenir à un courriel.

Accepter une invitation à l’organisation du personnel (plan_id staff) fait aussi de la personne un membre du personnel. Seul le personnel peut donc envoyer ces invitations, à une adresse par requête avec une preuve staff_grant qui lui est liée (reauthentication_required sans preuve). Personnes seulement; les agents et les identifiants bearer n’ont pas de route d’administration.

Un administrateur désigné révoque une invitation de membre en cours. Une invitation déjà révoquée renvoie 204 ; une invitation acceptée renvoie invitation_consumed ; un id que l’organisation ne détient pas est not_found. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné retire un membre de l’organisation.

Dans une transaction, l’organisation d’appartenance de la personne est effacée et ses adhésions à tous les projets actifs de l’organisation prennent fin, chacune comme le ferait son retrait de ce projet (les invitations par courriel en attente à ce projet sont révoquées et ses sessions cessent de le résoudre) ; les adhésions aux projets d’autres organisations restent inchangées, et aucune autre organisation n’est modifiée.

Le changement est enregistré dans l’audit de l’organisation.

Une personne que gère un fournisseur d’identité (authentification unique ou SCIM) donne managed_member ; un administrateur désigné donne organization_admin_member (retirez d’abord son poste d’administrateur avec PUT /api/organizations/{org_id}/admins) ; une personne propriétaire d’un projet actif de l’organisation donne member_owns_projects et le détail liste les noms des projets (transférez d’abord ces projets, rien n’est retiré) ; une personne qui n’est pas membre de l’organisation, y compris une personne déjà retirée, donne not_found.

Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné définit qui l’organisation admet dans ses projets à titre d’invités, c’est-à-dire les personnes dont l’organisation d’appartenance est une autre ou qui n’en ont aucune. mode allow (par défaut) admet tous les invités, domains admet un invité dont l’adresse courriel vérifiée se trouve dans l’un des domaines de domains, et none n’admet aucun invité. domains liste de 1 à 20 noms DNS distincts en minuscules, obligatoire pour mode domains et omis autrement ; tout autre cas est invalid_request.

La politique remplace la précédente, incrémente la révision de l’organisation, est enregistrée dans l’audit de l’organisation et répond par la politique en vigueur. Elle est vérifiée lorsque l’organisation accorde à un invité une adhésion à un projet, par invitation de membre du projet (création et acceptation) et par liaison de groupe SCIM, et refuse avec guest_not_allowed.

Le personnel et les administrateurs de l’organisation sont exemptés, les agents ne sont pas vérifiés, et les membres de l’organisation ne sont jamais des invités. Resserrer la politique ne retire personne ; outside_policy compte les personnes externes déjà présentes dans les projets actifs de l’organisation que la nouvelle politique n’admettrait pas, et GET /api/organizations/{org_id}/people signale chacune d’elles (outside_guest_policy).

Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné définit ou retire le projet Bibliothèque de l’organisation. project_id désigne l’un des projets actifs de l’organisation, ou null pour retirer la Bibliothèque.

Tous les autres projets de l’organisation lisent alors les médias, les dossiers de médias et les listes de lecture de la Bibliothèque (library=true sur GET /api/media, /api/media-folders et /api/playlists, et par identifiant) et les utilisent en lecture seule : références de médias des pages, sélecteurs by:folder qui nomment un dossier de la Bibliothèque (les sélecteurs par balise et « tous » n’atteignent jamais la Bibliothèque), horaires et piles des écrans, et from_template. Seuls les membres de la Bibliothèque les modifient.

Le projet Bibliothèque ne contient aucun écran : un projet qui a des écrans donne library_no_screens, et la Bibliothèque n’en admet plus ensuite. Définir une Bibliothèque exige la fonctionnalité de forfait library (Premium, Education, Enterprise ; sinon feature_not_in_plan) ; la retirer ne l’exige jamais, et une Bibliothèque conservée après un passage à un forfait inférieur continue d’être servie.

Si la Bibliothèque est retirée ou remplacée, les listes de lecture des projets membres qui nomment ses éléments ne peuvent plus les résoudre à leur prochaine écriture, et les écrans cessent de recevoir ses médias. Un projet qui est la Bibliothèque et qui est supprimé ou déplacé hors de l’organisation la retire.

Répond avec la vue de l’organisation, est consigné dans l’audit de l’organisation (organization.library_changed) et incrémente la révision. Réservé aux personnes.

Un administrateur désigné définit l’accès de plusieurs personnes à plusieurs projets actifs de l’organisation en une seule requête, sans en rejoindre aucun.

Chacune des modifications (de 1 à 500) nomme un projet, une personne et un accès, sans aucune paire (project_id, user_id) en double. member fait de la personne un membre du projet qui ne peut pas approuver les révisions (ajoutée si elle n’en est pas membre; une personne qui approuvait perd cette capacité), approver un membre qui peut approuver (ajoutée si elle n’en est pas membre), et none aucun membre (retirée si elle en est membre).

Tout est appliqué dans l’ordre en une seule transaction, et un seul refus annule tout le lot; chaque refus désigne changes[i] (le projet ou la personne) ou changes[i].access dans errors[].field.

Un projet qui n’est pas un projet actif de cette organisation donne not_found; une personne qui n’est pas une personne active (un agent, une personne désactivée, un id inconnu) ou qui est membre du personnel, une adhésion suspendue, et une personne ajoutée qui ne fait pas partie des personnes de l’organisation (ses administrateurs, ses membres et les membres actifs de ses autres projets actifs; toute autre personne se joint par une invitation) donnent invalid_request; le propriétaire n’est jamais défini sur member ou none (owner_cannot_leave); un téléverseur n’approuve jamais (resource_conflict, comme répond PUT /api/members/{user_id}/approver); il est interdit à un administrateur de se retirer lui-même (un administrateur part par DELETE /api/members/{user_id}); et une personne ajoutée est admise comme une invitation l’admet, donc les membres de l’organisation et ses administrateurs toujours, et une personne externe seulement lorsque la politique relative aux invités l’admet actuellement (guest_not_allowed).

La limite de 200 membres du projet et le plafond de membres de son forfait s’appliquent à ce qui est ajouté (member_limit_reached). La réponse répète chaque modification dans l’ordre de la requête; changed est false pour une modification dont l’accès était déjà en vigueur, qui n’écrit ni ne consigne rien.

Chaque modification est consignée dans l’audit de l’organisation (organization.project_member_added, organization.project_member_approver_changed ou organization.project_member_removed) et dans les événements du projet (member.added_by_organization_admin, project.member_approver_changed ou member.removed, marqués comme ceux de l’administrateur de l’organisation), et le propriétaire de chaque projet reçoit un courriel une seule fois pour le lot, sauf s’il a lui-même effectué la modification.

Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné rejoint l’un des projets actifs de l’organisation en tant que membre sans périmètre d’écrans ni de téléversement, qui peut approuver les révisions. C’est l’adhésion qui donne à l’administrateur le contenu du projet, que les routes de l’organisation ne montrent jamais.

Un administrateur déjà membre sans périmètre et qui peut approuver reçoit 200 avec joined false et rien ne change ; un membre avec un périmètre d’écrans ou de téléversement, ou qui ne peut pas approuver, devient un membre sans périmètre qui peut approuver, consigné comme une adhésion au projet.

La limite de 200 membres du projet s’applique (member_limit_reached) ; la politique relative aux invités de l’organisation ne s’applique jamais à ses propres administrateurs. L’adhésion est enregistrée dans l’audit de l’organisation sous organization.project_joined et dans les événements du projet sous member.added_by_organization_admin, et le propriétaire du projet reçoit un courriel.

Un projet que l’organisation ne détient pas, ou qui a été supprimé, donne not_found. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné nomme une personne propriétaire de l’un des projets actifs de l’organisation sans le rejoindre, à partir de son propriétaire actuel, y compris un propriétaire dont le compte est désactivé.

Le nouveau propriétaire est une personne vérifiée et active, membre du projet ou membre de l’organisation (un membre de l’organisation qui n’est pas membre du projet est d’abord ajouté comme membre sans périmètre d’écrans ni de téléversement qui peut approuver les révisions ; la politique relative aux invités ne s’applique pas à un membre de l’organisation) ; toute autre personne donne invalid_request à user_id.

Un administrateur ne se désigne propriétaire qu’après avoir rejoint le projet (POST /api/organizations/{org_id}/projects/{project_id}/access), et celui qui n’est pas un membre sans périmètre d’écrans ni de téléversement qui peut approuver donne invalid_request à user_id.

L’effet est celui du transfert par le propriétaire lui-même : le périmètre d’écrans et le périmètre de téléversement du nouveau propriétaire sont effacés et les responsabilités héritées du projet lui sont liées. Nommer le propriétaire actuel ne change rien. Le changement est enregistré dans l’audit de l’organisation sous organization.project_owner_changed, et l’ancien et le nouveau propriétaire reçoivent un courriel.

La limite de 200 membres du projet s’applique à un membre de l’organisation ajouté (member_limit_reached). Un projet que l’organisation ne détient pas, ou qui a été supprimé, donne not_found. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Un administrateur désigné retire un membre de l’un des projets actifs de l’organisation sans rejoindre le projet. L’effet est celui du retrait par le propriétaire (DELETE /api/members/{user_id}). L’adhésion prend fin, les invitations par courriel en attente de la personne au projet sont révoquées, ses sessions cessent de résoudre le projet, et les adhésions des agents restent.

Le propriétaire n’est jamais retiré (owner_cannot_leave ; transférez d’abord la propriété avec PUT /api/organizations/{org_id}/projects/{project_id}/owner). Une personne qui n’est pas membre du projet, y compris une personne déjà retirée, et un projet que l’organisation ne détient pas ou qui a été supprimé donnent not_found.

Le retrait est enregistré dans l’audit de l’organisation sous organization.project_member_removed et dans les événements du projet sous member.removed avec removed_by_organization_admin à true. Personnes seulement ; agents et identifiants porteurs n’ont pas de route admin.

Supprimer un domaine, vérifié ou en attente, et conserver les autres domaines de l’organisation. Le placement futur et la découverte pour ce domaine s’arrêtent, et une autre organisation peut le vérifier. Les projets déjà dans l’organisation restent. Un domaine que l’organisation ne détient ni ne prouve renvoie not_found.

Tant que l’organisation exige l’authentification unique, un domaine vérifié donne resource_conflict; désactiver Exiger l’authentification unique prend effet après 72 heures, et le domaine peut alors être retiré.

Définit si un membre peut approuver : décider des révisions et accorder aux agents l’accès Gérer. Un membre qui ne peut pas approuver voit ses agents limités à Propose. Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet (sinon forbidden) ; la propre ligne du propriétaire est fixe (resource_conflict) ; un non-membre donne not_found.

Ajoute project.member_approver_changed (détails user_id, can_approve).

Limite un membre à des dossiers d’écrans (chacun avec tous les dossiers qu’il contient) et à des écrans, ou remplace son périmètre (docs/screen-scope.md).

Dans une même transaction, elle met aussi fin aux agents que la personne a amenés dans le projet (agent.disconnected, comme le ferait leur retrait) et ajoute project.member_screen_scope_changed (détails user_id, screen_scope, previous, changed_by_user_id). Le périmètre est lu à la prochaine requête du membre : la modification apparaît dans son prochain GET /api/session sans nouvelle connexion.

Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet (sinon forbidden) ; la propre ligne du propriétaire, un téléverseur (un membre à périmètre est limité aux écrans, un téléverseur au contenu) et un membre qui approuve les révisions avec des écrans individuels dans le périmètre donnent resource_conflict ; un non-membre donne not_found ; un ID qui n’est pas un dossier d’écrans ou un écran actif du projet donne invalid_request à screen_scope.folder_ids[i] ou screen_scope.screen_ids[i].

Un membre à périmètre qui approuve les révisions n’approuve qu’à l’intérieur du périmètre ; celui qui ne peut pas approuver lit et exécute des commandes, mais ne modifie ce qui est diffusé que par l’entremise d’approbateurs (approver_required).

Un périmètre est aussi refusé avec resource_conflict tant que la personne, ou un agent qu’elle a amené, a un client de service actif du projet : le détail nomme jusqu’à cinq clients sous la forme ID (nom) et compte les autres, et rien n’est écrit.

Limiter une personne à des écrans relève du périmètre d’écrans, que le forfait Enterprise inclut ; un projet dont le forfait n’inclut pas cette fonctionnalité est refusé avec feature_not_in_plan (402). Un périmètre défini continue de limiter la personne jusqu’à ce qu’il soit effacé (DELETE), ce que tous les forfaits permettent.

Redonne à un membre à périmètre les écrans de tout le projet. Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet ; un membre sans périmètre reste tel quel. Ajoute project.member_screen_scope_changed avec screen_scope à null.

Limite l’adhésion d’un agent au projet de la session à des dossiers d’écrans et à des écrans, ou remplace son périmètre (docs/screen-scope.md). La portée de l’agent est ce périmètre restreint par celui de la personne qui en est responsable, de sorte qu’une personne à périmètre n’agit jamais par l’entremise d’un agent plus étendu qu’elle.

Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet (sinon forbidden) ; un agent qui n’est pas membre du projet donne not_found. Ajoute agent.screen_scope_changed (détails agent_id, screen_scope, previous, changed_by_user_id).

Le périmètre d’un agent s’applique à sa prochaine requête sur l’instance qui l’a écrit et en deux secondes sur les autres. Un périmètre est refusé avec resource_conflict tant que l’agent a un client de service actif du projet : le détail nomme jusqu’à cinq clients sous la forme ID (nom) et compte les autres, et rien n’est écrit.

Limiter un agent à des écrans relève du périmètre d’écrans, que le forfait Enterprise inclut ; un projet dont le forfait n’inclut pas cette fonctionnalité est refusé avec feature_not_in_plan (402). Un périmètre défini continue de limiter l’agent jusqu’à ce qu’il soit effacé (DELETE), ce que tous les forfaits permettent.

Retire le périmètre de l’adhésion d’un agent au projet de la session. Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet. Ajoute agent.screen_scope_changed avec screen_scope à null.

Fait d’un membre un téléverseur, ou remplace le périmètre de l’un d’eux (docs/uploaders.md) : les listes de lecture dont il modifie les pages et les dossiers de médias dans lesquels il téléverse.

Dans une même transaction, elle les empêche aussi d’approuver des révisions, met fin aux agents qu’ils ont amenés dans le projet (agent.disconnected, comme le ferait leur retrait) et ajoute project.member_upload_scope_changed (détails user_id, upload_scope, changed_by_user_id).

Le périmètre est lu à la prochaine requête du membre : le changement apparaît à son prochain GET /api/session sans nouvelle connexion.

Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet (sinon forbidden) ; la ligne du propriétaire lui-même donne resource_conflict ; un non-membre donne not_found ; un id qui n’est pas une liste de lecture ou un dossier de médias actif du projet donne invalid_request à upload_scope.playlist_ids[i] ou upload_scope.folder_ids[i]. access propose (par défaut) envoie les modifications du téléverseur en révision ; manage les publie.

Un membre limité aux écrans donne resource_conflict : levez d’abord ce périmètre (DELETE /api/members/{user_id}/screen-scope).

Refait d’un téléverseur un membre à part entière, qui n’approuve pas les révisions (activez-le avec setDashboardMemberApprover). Réservé au propriétaire du projet ou à un membre qui administre l’organisation du projet ; un membre qui n’est pas téléverseur reste tel quel. Ajoute project.member_upload_scope_changed avec upload_scope à null.