Skip to main content

Utilisateurs & rôles

backend/src/controllers/users.controller.js + role.controller.js + frontend/src/views/backoffice/UsersView.vue + RolesView.vue.

Dernière vérification contre le code

Vérifié le 2026-08-13. Voir aussi Authentification & 2FA pour le flux de création/invitation.

1. Modèle de rôles — entièrement personnalisable​

roles { name String @id, permissions Json } — un rôle est juste un nom (clé primaire texte libre) + un tableau JSON de chaînes de permission. Pas d'enum figé en base : n'importe quel nom de rôle et n'importe quelle permission peuvent exister. Seul SUPER_ADMIN est protégé en dur dans le code (impossible à supprimer, role.controller.js).

RolesView.vue (frontend) utilise une liste de permissions codée en dur côté client (availablePermissions, 17 entrées) — le backend, lui, accepte n'importe quel tableau JSON. Cette liste frontend est la seule source de vérité pour "quelles permissions existent" ; l'ajouter/l'oublier dans ce tableau est le seul moyen de la rendre visible dans l'éditeur.

updateRole calcule un diff added/removed entre permissions pour l'historique. deleteRole refuse la suppression de SUPER_ADMIN et de tout rôle encore assigné à des utilisateurs.

Corrigé le 2026-08-13

Un commentaire dans le code évoquait une protection prévue contre le fait de vider les permissions de SUPER_ADMIN, jamais implémentée. updateRole refuse désormais explicitement (400) toute sauvegarde du rôle SUPER_ADMIN avec un tableau de permissions vide. Ne bloque qu'un vidage complet — retirer certaines permissions en en gardant au moins une reste possible, aucune permission spécifique n'est protégée individuellement.

2. Deux chemins de création de compte​

Voir Authentification & 2FA pour le détail complet : POST /api/users (invitation par email, utilisé par UsersView.vue) vs POST /api/auth/register (mot de passe direct, réservé SUPER_ADMIN, non utilisé par le frontend actuel).

Corrigé le 2026-08-13

users.routes.js ne protégeait POST/PUT/DELETE /api/users que par verifyToken — sans restriction de rôle, contrairement à /api/roles (isSuperAdmin global). N'importe quel compte backoffice authentifié pouvait créer, modifier ou désactiver un autre utilisateur, y compris changer son rôle vers SUPER_ADMIN. isSuperAdmin a été ajouté sur ces trois routes (même middleware que role.routes.js).

3. Journalisation (activity-log)​

users.controller.js journalise user_created, user_updated (diff sur email, first_name, last_name, role, is_active, id_agence, id_zone — le mot de passe n'apparaît jamais en clair, seul un indicateur (mot de passe modifié)), user_deactivated (désactivation = soft-delete, pas de suppression réelle).

role.controller.js journalise role_created, role_updated (avec le diff added/removed de permissions calculé manuellement, pas via diffFields), role_deleted. Voir Journal d'activité pour le mécanisme générique sous-jacent.

4. Après une modification de son propre rôle​

RolesView.vue appelle auth.refreshUser() après chaque sauvegarde de rôle — pour le cas où l'utilisateur connecté vient de modifier ses propres permissions, afin que la session reflète immédiatement le nouvel état sans nécessiter une reconnexion.

5. Pièges connus pour un futur développeur​

  1. La restriction de rôle manquante sur POST /api/users — corrigé le 2026-08-13 (section 2).
  2. Aucun garde-fou contre le vidage des permissions de SUPER_ADMIN — corrigé le 2026-08-13 (section 1).
  3. Aucune limite n'empêche de créer un rôle avec des permissions arbitraires non reconnues par le frontend — elles seraient simplement invisibles/inutilisées côté UI sans erreur.