Groupes et rôles pour votre SaaS, sans développer le multi-tenant
Dernière mise à jour :
Seed donne à chaque compte un groupe personnel à l’inscription, et les utilisateurs créent des groupes partagés, invitent d’autres personnes et leur attribuent un rôle, de lecteur à propriétaire. Le groupe est l’unique frontière entre locataires : une fonctionnalité que vous ajoutez passe la même vérification dès qu’elle copie l’agrégat des notes.
- Le groupe est l’unique frontière entre locataires : données personnelles et partagées passent la même vérification
- L’application, son code et ce site l’appellent tous « groupe »
- Pas de second modèle de permissions à garder synchronisé avec le premier
- Invitations, changements de rôle et transfert de propriété, chacun avec ses propres tests
Chaque ligne de données partagées appartient à un groupe, et l’API vérifie le rôle de la personne dans ce groupe avant toute lecture ou écriture. Un lecteur lit, un éditeur modifie aussi les données du groupe, et un administrateur et le propriétaire gèrent en plus les membres et lisent le journal d’activité.
Le propriétaire transfère la propriété en une étape, et un groupe supprimé peut être restauré pendant 30 jours. Seul un compte dont l’adresse e-mail est confirmée peut inviter.
Chaque compte a-t-il un groupe ?
Oui. Chaque compte reçoit un groupe personnel à l’inscription ; un groupe personnel et un groupe partagé passent la même vérification.
Un lecteur peut-il modifier les données d’un groupe ?
Non. Un lecteur lit les données du groupe ; un éditeur, un administrateur ou le propriétaire peut les modifier.
Un groupe supprimé peut-il être restauré ?
Oui. Son propriétaire peut le restaurer pendant 30 jours ; ensuite, le worker le supprime définitivement.
Me faut-il un second système de permissions pour mes propres fonctionnalités ?
Non. Un nouvel agrégat copie l’agrégat des notes et sa vérification de groupe : il n’y a qu’un seul modèle de permissions à maintenir.