Base de connaissances
Rôles et niveaux d'autorisation
Un rôle dit ce qu'une personne a le droit de faire ; un accès à une adresse dit sur quoi elle a le droit de le faire.
Détails
- Deux attributions par personne, et les deux doivent concorder avant que quoi que ce soit se produise. Le RÔLE, défini dans Paramètres → Membres, dit ce que la personne a le droit de FAIRE dans l'espace de travail : lire le courrier, l'envoyer, modifier des modèles, ajouter un domaine, frapper une clé d'API. L'ACCÈS à une adresse, défini depuis le contrôle Partager sur la ligne de l'adresse, dit sur quelles ADRESSES elle a le droit de le faire, en lecture seule ou en lecture et envoi. Quelqu'un qui détient un rôle incluant l'envoi mais aucune adresse ne peut envoyer depuis rien ; quelqu'un qui détient toutes les adresses de l'espace de travail sous un accès en lecture seule ne peut envoyer depuis aucune non plus.
- Six rôles existent sans que personne les crée, et chaque espace de travail a les six mêmes : « Admin » veut donc dire ici la même chose que dans la documentation et sur l'API. Owner, Admin, Member et Viewer forment une échelle : chacun détient tout ce que détient le suivant, si bien que rétrograder quelqu'un réduit ce qu'il peut atteindre au lieu de l'échanger contre une autre tranche. Developer et Billing ne sont pas des barreaux de cette échelle. Developer construit des intégrations, détient les clés d'API, les webhooks, les modèles et l'envoi sans lire le moindre courrier de l'espace de travail, et Billing voit le forfait et les factures, peut changer le forfait et les moyens de paiement associés, et lit les réglages des boîtes aux lettres sans pouvoir en écrire un. Leurs autorisations sont modifiables : un espace de travail qui préfère que ses membres n'écrivent pas de modèles décoche la case, et le changement s'applique à la requête suivante de quiconque détient EXPLICITEMENT ce rôle. Quelqu'un dont le rôle n'est encore qu'impliqué par un accès à une adresse accordé avant l'existence des rôles conserve les valeurs par défaut livrées jusqu'à ce qu'on lui en attribue un franchement. Leurs noms le sont aussi : un espace de travail qui tourne avec Ops et On-call les renomme et se décrit lui-même, ce qui est bien le but.
- Owner fait exception dans toutes les directions : non modifiable, non supprimable, non attribuable. Il décrit le compte sur lequel l'espace de travail est indexé et détient toutes les autorisations, y compris celles ajoutées dans une version ultérieure, ce qui explique que sa liste soit calculée plutôt que stockée. Remettre l'espace de travail à quelqu'un d'autre est un transfert et non un changement de rôle, et rien ici n'en fait un.
- Au-delà, un espace de travail écrit les siens, jusqu'à 24 au total, en cochant des autorisations dans la même matrice groupée. Cocher implique : « modifier les modèles » stocke « lire les modèles » à côté, car un rôle qui peut modifier un modèle qu'il ne peut pas ouvrir est une case que quelqu'un a oubliée plutôt qu'une politique voulue. Supprimer un rôle détenu par des personnes ou des clés d'API demande où les déplacer et refuse plutôt que de deviner. Une clé dont le rôle aurait disparu retomberait sans aucun plafond, ce qui est plus large que le rôle qui vient de partir.
- Une clé d'API peut être émise contre un rôle, et le rôle est un plafond plutôt qu'une seconde attribution : ce que la clé a le droit de faire, ce sont ses propres scopes intersectés avec les autorisations du rôle, résolus à chaque requête. Une clé créée avec l'envoi et plafonnée par Viewer ne peut pas envoyer, et restreindre un rôle la révoque en direct sans avoir à faire tourner la clé. L'assistant est tenu à la même liste, et le serveur MCP construit les outils d'un client à partir des autorisations de l'appelant : le client d'un Viewer ne contient donc aucun outil d'envoi, et chaque outil protégé revérifie à l'entrée, car une session peut changer de boîte aux lettres après la construction de la liste.