Utilisateur (User)
En une phrase : la personne physique qui interagit avec la plateforme, quelle que soit sa raison d'y être — un même compte porte toutes ses « casquettes ».
Rôle métier
L'utilisateur n'est pas synonyme de « client » : c'est le compte unique d'une personne, qui cumule librement trois casquettes indépendantes :
- Voyageur (
is_traveller, vrai par défaut) — la personne consomme le produit : elle achète/reçoit des cartes-cadeaux et vivra les road-trips surprise sur l'application mobile. - Membre d'organisation — la personne travaille pour un ou plusieurs partenaires (revendeur, région) et agit sur le portail de chacun, avec un rôle propre à chaque organisation (voir Appartenance et Rôle).
- Super-admin (
is_super_admin) — la personne fait partie de l'équipe Travelise et administre toute la plateforme, au-dessus des organisations.
Chaque requête API déclare explicitement la casquette utilisée (en-tête X-Viewing-As) : le backend ne devine jamais « en tant que qui » on agit — voir Identité & accès.
Cycle de vie
pending → active → (disabled)
pending— compte provisionné mais pas encore réclamé : créé par une invitation, une candidature d'organisation, la création d'organisation par un super-admin, l'import de l'ancien système, ou l'auto-inscription voyageur. Il ne peut pas se connecter ; il n'a pas de mot de passe, sauf auto-inscription où il est posé d'emblée (seul le clic sur le lien d'activation manque alors).active— la personne a accepté son invitation (et posé son mot de passe) ou activé son compte auto-inscrit. Seul un compte actif peut se connecter ou recevoir un lien de réinitialisation.disabled— compte coupé par l'équipe ; la connexion est refusée même avec le bon mot de passe.
Le compte porte aussi la langue préférée (fr-ch | ge-ch | en-gb), utilisée pour tous les e-mails qui lui sont adressés et transmise au frontend dans les liens (invitation, reset).
Relations métier
| Relation | Sens métier |
|---|---|
| ↔ Organisations (via Membership) | Les employeurs / structures pour lesquels la personne agit ; le rôle (manager / employee) dépend de l'organisation |
← Codes d'activation (customer_id) | Les cartes-cadeaux assignées à cette personne en tant que cliente ; si le compte disparaît, le code survit (l'historique commercial prime) |
| ← Invitations | Les entrées successives de la personne dans la plateforme ; une seule invitation en attente à la fois |
← Images (uploaded_by et profile_picture_id) | Ce que la personne a téléversé, et sa photo de profil |
| ← Journal d'audit (causer) | Tout ce que la personne a fait sur la plateforme |
Règles métier
- Un e-mail = un compte : l'e-mail est l'identité pivot. Les flux d'import et de création de manager font du find-or-create par e-mail plutôt que de créer des doublons ; un e-mail déjà enregistré ne peut pas repasser par le signup public (il rejoint une organisation via invitation).
- Les casquettes sont un indice d'interface, pas une frontière de sécurité : le frontend route l'utilisateur selon ses casquettes, mais l'autorisation réelle est re-vérifiée serveur à chaque requête.
- Le profil (nom, adresse, langue, photo) est en libre-service ; l'e-mail et le mot de passe ne se changent pas par ce chemin (aucun flux de re-vérification n'existe encore).
- Le super-admin court-circuite toutes les autorisations — l'amorçage du tout premier compte passe par la commande
app:ensure-super-admin, pas par un flux applicatif.
Contributors
No contributors
Changelog
No recent changes