Équipe, rôles et permissions

Comment fonctionne l'accès

• Un compte est toute personne qui se connecte. Il appartient à un espace de travail par une appartenance avec un seul rôle : Owner (exactement un par espace), Admin, Member ou Billing. Un même compte peut avoir un rôle différent dans chaque espace de travail auquel il appartient.
• Chaque espace de travail garde sa propre matrice de rôles : quel rôle détient lesquelles des quatorze permissions. Le propriétaire les détient toutes et ne peut pas être modifié, et deux d'entre elles, workspace.delete et roles.manage, restent au propriétaire quoi que dise la matrice. Un nouvel espace de travail part des valeurs par défaut ci-dessous.
• L'API vérifie côté serveur chaque requête d'espace de travail : un compte qui n'en est pas membre reçoit 404, comme si l'espace n'existait pas, et une permission manquante reçoit 403. Un espace de travail suspendu garde toutes les lectures et refuse toutes les écritures.
• Le tableau de bord masque les lignes de la barre latérale et les boutons qu'un rôle n'inclut pas, et une page ouverte par son adresse affiche Access required.
• Un changement du rôle d'un membre ou de la matrice s'applique à la requête suivante de ce membre à l'API. Sa barre latérale et ses boutons suivent la prochaine fois que le tableau de bord lit l'espace de travail, au plus tard à un rechargement.
• Le personnel de la plateforme (Platform admin et Support) forme un ensemble de rôles distinct, valable pour tous les espaces de travail : voir Administration de la plateforme.

Les rôles et comptes du seed

Forma Studio, l'espace de travail du seed, utilise la matrice par défaut. Chaque rôle a un compte du seed qui se connecte au tableau de bord ; le guide d'installation liste leurs identifiants de connexion.

• workspace.read est ce qui ouvre les lignes Team, Roles et Settings : chaque rôle, Billing compris, voit donc la liste des membres, la matrice en lecture seule et les paramètres. Les projets de la vue d'ensemble, son graphique hebdomadaire et les projets demandant de l'attention demandent projects.read. Son activité récente et la cloche montrent chaque événement à un rôle qui détient projects.read ou audit.read ; un rôle avec billing.read et aucun des deux (Billing, dans le seed) ne voit que les événements de facturation, et tout autre rôle n'en voit aucun. Le journal d'activité complet et son export demandent audit.read.
• L'e-mail de facturation de l'espace de travail n'est renvoyé qu'à un rôle avec billing.read ou billing.manage.
• Forma Studio a 8 membres (un propriétaire, un admin, cinq membres et un contact de facturation) sur les 10 places de la formule Pro, avec deux invitations en attente et un projet archivé. Le propriétaire est aussi admin d'un second espace de travail, Monogram, qui a son propre propriétaire, sa propre équipe, son invitation et sa clé d'API.
• yarn seed n'écrit la matrice d'un espace de travail que s'il n'en a pas : le relancer garde donc les modifications faites sur la page Roles. Changez chaque mot de passe du seed, ou supprimez les comptes d'exemple, avant que le tableau de bord soit accessible depuis Internet.

• Installation

Chaque permission de l'espace de travail

La page Roles regroupe les permissions sous les libellés ci-dessous. La liste est définie une seule fois, dans back-end/src/modules/workspaces/constants/workspace-permissions.ts, avec les valeurs par défaut dont part chaque nouvel espace de travail.

La page Team

/en/dashboard/team a deux onglets, Members et Invitations, chacun avec une recherche et un filtre Role. Les membres sont listés propriétaire d'abord, puis par rôle et par date d'arrivée.

• La ligne du propriétaire n'a aucune action : la propriété ne change de main que par Make owner.
• Retirer quelqu'un le sort aussitôt de cet espace de travail ; ses projets et ses tâches restent. Personne ne se retire soi-même depuis ce menu, et un admin peut retirer des membres et des contacts de facturation mais pas un autre admin (l'API répond 403).
• Un membre retiré garde son compte et ses autres espaces de travail.

Invitations et places

• Invite a member demande une adresse e-mail et un rôle, et liste ce que ce rôle pourra faire. La personne reçoit par e-mail un lien vers /en/invitations/<token> valable sept jours ; sans SMTP_HOST, le message, lien compris, est écrit dans le journal de l'API.
• La page d'invitation affiche l'espace de travail, le rôle, l'e-mail invité (masqué) et l'expéditeur. Pour accepter, il faut être connecté avec l'e-mail invité : une personne nouvelle crée d'abord un compte avec cet e-mail. Une invitation destinée à un autre e-mail, une invitation expirée ou une invitation révoquée est refusée avec son propre message.
• Chaque formule a un nombre de places : 3 sur Starter, 10 sur Pro et 30 sur Scale. Une invitation en attente n'utilise aucune place ; l'accepter en utilise une. Sans place libre, une nouvelle invitation est refusée (« There is no free seat. Change the plan to invite more people. »), de même que l'acceptation d'une invitation, vérifiée dans la même transaction pour que deux personnes ne puissent pas prendre la dernière place en même temps.
• Resend invitation génère un nouveau lien et une nouvelle expiration de sept jours, une fois par minute au plus et cinq fois par invitation. Revoke invitation fait cesser le lien de fonctionner.
• Inviter quelqu'un qui est déjà membre, ou qui a déjà une invitation en attente, est refusé. Une fois épuisé le délai de grâce (BILLING_GRACE_DAYS) d'un espace de travail en retard de paiement, les nouvelles invitations sont refusées jusqu'au paiement.

• Facturation et formules
• Paramètres de l'e-mail

La page Roles

/en/dashboard/roles affiche la matrice de l'espace de travail : une ligne par permission, dans les six groupes ci-dessus, et une colonne par rôle, chaque cellule indiquant Allowed ou Not allowed. La colonne Owner est verrouillée, et les lignes Delete workspace et Manage roles indiquent Owner only.

• Seul le propriétaire la modifie. Tous les autres qui détiennent workspace.read la voient en lecture seule : « Only the workspace owner changes what each role can do. »
• Save changes montre d'abord ce que chaque rôle gagne et perd, puis enregistre toute la matrice et écrit un événement roles.updated dans le journal d'activité. Reset revient à la matrice enregistrée.
• Les quatre rôles sont fixes : un espace de travail ne peut pas en ajouter un cinquième. Pour donner moins qu'un rôle à quelqu'un, retirez la permission à ce rôle, ce qui la change pour tous ceux qui le détiennent.

Propriété

• Make owner demande le mot de passe du propriétaire, puis fait du membre choisi le propriétaire et de l'ancien propriétaire un admin, en une seule étape. L'opération est écrite dans le journal d'activité sous ownership.transferred.
• Seul le propriétaire supprime l'espace de travail, depuis Settings, avec son nom et son mot de passe.
• Sur la plateforme, un compte qui possède un espace de travail ne peut pas être supprimé tant qu'un autre membre n'en est pas devenu propriétaire.

Les routes derrière ces pages

:workspaceId est l'identifiant public de l'espace de travail, comme org_forma. Les erreurs reviennent sous forme de codes : seat_limit_reached, already_member, already_invited, resend_too_soon, resend_limit_reached, owner_protected, workspace_owner_only et invalid_password entre autres.

• Référence de l'API

Comment sont construites les vérifications de permissions