Membres

Procédures du routeur member. Créer une ligne membre et modifier son nom, sa photo ou ses données de travail passe par GraphQL sur l’entité member ; ces procédures gèrent le parcours d’invitation, le rôle d’accès et le nombre de sièges de l’abonnement, qui demandent tous une logique côté serveur.

Un rôle d’accès vaut Readonly, Member, Admin ou Owner ; voir Permissions pour ce que chacun accorde.

Mutation member.inviteMember

Envoie un email d’invitation à un membre existant, pour un Admin ou un Owner. Un nouvel appel sur un membre déjà invité renvoie l’email avec un token frais.

La ligne membre conserve l’email et la date d’invitation, dont le token d’invitation est dérivé. Un membre déjà rattaché à un utilisateur répond CONFLICT, et l’appel est refusé quand l’abonnement n’a plus de siège disponible pour un membre de plus. La procédure ne renvoie rien.

await trpc.member.inviteMember.mutate({
  memberId: 'VOTRE_MEMBER_ID',
  email: '[email protected]',
  role: 'Member',
})

Requête member.getMemberInvitationInfo

Lit ce qu’un lien d’invitation doit afficher avant que le destinataire se connecte : cette procédure ne demande donc aucune authentification.

Elle renvoie { orgName, email }. Un membre sans invitation en attente répond NOT_FOUND, et un token qui ne correspond pas répond UNAUTHORIZED.

Requête member.getPendingInvitations

Liste les invitations en attente pour l’utilisateur connecté, rapprochées de son adresse email. Elle ne prend aucun input et sert à proposer de rejoindre une organisation à un utilisateur qui n’en a aucune.

Elle renvoie un tableau de { memberId, token, orgId, orgName }, prêt à passer à member.acceptMemberInvitation. Une adresse email non vérifiée renvoie un tableau vide, l’inscription seule ne prouvant rien sur le propriétaire de l’adresse.

Mutation member.acceptMemberInvitation

Rattache le membre invité à l’utilisateur connecté et applique le rôle d’accès prévu.

L’invitation est consommée, et le nombre de sièges de l’abonnement Stripe est mis à jour quand l’organisation a un abonnement actif. Quand il s’agit de la première organisation de l’utilisateur, invitation est enregistré comme source d’onboarding. Un utilisateur déjà membre de l’organisation répond CONFLICT, et un abonnement sans siège libre bloque l’appel. La procédure ne renvoie rien.

Mutation member.updateMemberRole

Change ou retire le rôle d’accès d’un membre. Un Admin agit sur n’importe quel membre, changer le rôle d’un Owner demande le rôle Owner, et le dernier Owner actif ne peut pas être rétrogradé.

Un membre jamais invité répond NOT_FOUND. La procédure ne renvoie rien.

Mutation member.archiveMember

Archive un membre, le détache de son compte utilisateur et efface son rôle d’accès et son invitation. Un Admin archive n’importe quel membre, archiver un Owner demande le rôle Owner, et le dernier Owner actif est protégé. Un membre ne peut pas s’archiver lui-même, ce qui répond FORBIDDEN.

La procédure prend { memberId }, met à jour le nombre de sièges de l’abonnement quand le membre était rattaché à un utilisateur, et ne renvoie rien.

Mutation member.restoreMember

Restaure un membre archivé, pour un Admin ou un Owner. La procédure prend { memberId } et ne renvoie rien. Le membre revient sans rôle d’accès : invitez-le de nouveau pour lui redonner l’accès.