Aller au contenu principal

Modèle actor_users

Objectif du modèle

Porter la relation critique entre utilisateurs et acteurs, avec les rôles et périmètres de gestion associés.

Responsabilités

  • Définir qui peut gérer un acteur.
  • Porter les rôles métier liés à l’acteur.
  • Encadrer les contributions, validations et permissions.
  • Servir de pivot RBAC pour éviter de mélanger compte utilisateur et acteur.

Relations principales

  • Un utilisateur peut avoir plusieurs relations actor_users.
  • Un acteur peut avoir plusieurs gestionnaires ou contributeurs.
  • Les publications et actions sensibles peuvent être autorisées via ce pivot.

Cycle de vie

  1. Création après revendication, invitation ou attribution admin.
  2. Activation du rôle.
  3. Modification éventuelle des permissions.
  4. Révocation, expiration ou transfert.
  5. Audit des changements sensibles.

Permissions/RBAC liées

  • Pivot RBAC critique.
  • Les rôles doivent être interprétés côté Laravel.
  • Les scopes doivent limiter l’action à l’acteur concerné.
  • Un rôle acteur ne donne pas de droit global plateforme.

Contraintes métier

  • Un acteur ne doit pas être contrôlé implicitement par tout utilisateur lié.
  • Les droits élevés doivent être attribués explicitement.
  • Les invitations et révocations doivent être auditables.
  • Les communes ne doivent pas utiliser ce pivot pour censurer globalement la plateforme.

Données sensibles éventuelles

  • Rôles, permissions, invitations, décisions de validation.
  • Historique de révocation ou conflit.

Cache/offline éventuel

  • Ne pas se fier durablement à un cache frontend pour les droits.
  • Les droits sensibles doivent être revalidés côté API.

Stratégie d’indexation

  • Index conceptuels sur utilisateur, acteur, rôle, statut.
  • Contrainte d’unicité probable utilisateur + acteur à confirmer.

Partitionnement si concerné

Non prioritaire. Modèle relationnel critique mais peu volumineux comparé aux publications.

État actuel vs cible

NiveauDescription
Structure visible/confirméeDistinction utilisateurs / acteurs / rôles documentée ; revendication d’acteur prévue.
Structure probableTable pivot utilisateur-acteur avec rôle, statut et périmètre.
Cible futurePivot RBAC central pour gestion acteur, contributions, claims et audit.

Points à confirmer

  • Noms et niveaux de rôles acteur.
  • Règles d’invitation et d’acceptation.
  • Expiration éventuelle des rôles.
  • Historisation des changements.

Diagramme Mermaid ER simplifié