Accès et autorisations

Les accès déterminent ce qu'un utilisateur peut voir ou faire. Dans TARS, une autorisation dépend de la personne, de son organisation active, de ses rôles, des contrats, du shop, du statut de l'objet et parfois de droits plus fins.

Notions

Règle générale

Un utilisateur ne doit jamais obtenir plus de droits que ce que permettent son organisation active, ses rôles, ses contrats et son profil.

Où les accès sont définis

Les accès sont portés par les contrats. C'est dans les contrats rattachés à une organisation qu'on coche les accès, qui se répercutent ensuite sur l'organisation et sur ses utilisateurs.

Certains thèmes d'accès, notamment « Interne » et « Super », ne servent qu'aux utilisateurs internes. La majorité des accès d'une organisation cliente sont posés par les contrats automatiques créés à son onboarding.

Modes d'attribution des droits d'une personne

Trois modes s'excluent, selon un ordre de priorité fixe.

flowchart TD
  start["Calcul des droits d'une personne"] --> perso{"Accès personnalisés définis ?"}
  perso -->|Oui| modePerso["Mode personnalisé: ces accès uniquement, rôles ignorés"]
  perso -->|Non| roles{"Rôles métier attribués ?"}
  roles -->|Oui| modeRoles["Mode rôles: accès réunis par les rôles"]
  roles -->|Non| modeAdmin["Mode admin de l'organisation: tous les accès des contrats"]

Le détail du calcul, y compris l'héritage entre organisations d'un même groupe, les procurations et la séparation par shop, est décrit dans Calcul des droits d'accès. La liste des rôles métier et des accès qu'ils réunissent est décrite dans Rôles et autorisations. Le fonctionnement des procurations, illustré sur une organisation fictive, est décrit dans Procurations et organisations complexes.

Sélection des accès dans l'admin

Depuis l'onglet « Accès » de la fiche utilisateur :

• « Admin de l'organisation » est coché par défaut et affiche l'ensemble des accès des contrats de l'organisation, sans possibilité de les modifier.
• « Rôles » ouvre un menu déroulant permettant de sélectionner un ou plusieurs rôles. Les accès affichés se mettent à jour, sans être modifiables : un rôle réunit toujours les mêmes accès. Un accès prévu par un rôle mais absent des contrats de l'organisation reste décoché.
• « Personnalisé » permet de retirer des accès par rapport à la liste disponible pour l'organisation. On ne peut jamais en ajouter au-delà des contrats.
• Revenir sur « Admin de l'organisation » réinitialise les accès : la personne récupère l'ensemble des accès de son organisation.

Gestion des accès depuis l'espace personnel

La page « Utilisateurs », dans le menu « Organisation », liste les utilisateurs rattachés à l'organisation avec leur identité, le statut de leur compte et leurs rôles.

Une personne disposant de l'accès de gestion des utilisateurs peut en plus :

• modifier les rôles des autres utilisateurs, sauf ceux dont les accès sont personnalisés;
• inviter un nouvel utilisateur depuis l'onglet « Gestion des invitations » et lui attribuer ses rôles dès l'invitation.

Les rôles définis depuis l'espace personnel se retrouvent dans l'onglet « Accès » de la fiche utilisateur côté admin, et inversement.

Workflow d'autorisation

flowchart TD
  action["Action demandée"] --> session{"Session valide ?"}
  session -->|Non| refuseSession["Refuser: connexion requise"]
  session -->|Oui| organisation{"Organisation active compatible ?"}
  organisation -->|Non| refuseOrganisation["Refuser: mauvais contexte"]
  organisation -->|Oui| droits["Calculer rôles, contrats et access keys"]
  droits --> autorise{"Droit disponible ?"}
  autorise -->|Non| refuseDroit["Refuser: droit absent"]
  autorise -->|Oui| statut{"Statut de l'objet compatible ?"}
  statut -->|Non| refuseStatut["Refuser: statut bloquant"]
  statut -->|Oui| sensible{"Action sensible ?"}
  sensible -->|Oui| audit["Autoriser et tracer"]
  sensible -->|Non| autorisation["Autoriser l'action"]

Ce qui est implémenté

• Les droits de session sont calculés depuis les contrats actifs de l'organisation.
• Les contrats des organisations parentes peuvent être pris en compte uniquement quand le transfert aux enfants est autorisé.
• Quand une personne agit pour une autre organisation, TARS applique l'intersection entre les droits de la personne et ceux de l'organisation active.
• Les access keys d'une personne et ses rôles métier peuvent restreindre les droits issus des contrats.
• Un profil super admin reçoit l'ensemble des droits disponibles sur tous les shops.
• Sans organisation de rattachement ou organisation active, aucun droit de session n'est retourné.
• L'accès à une URL de document exige une session et un lien autorisé avec l'organisation concernée, ou un profil admin compatible.
• Les frontaux consomment l'utilisateur, l'organisation active, les droits et les entitlements via un contexte de session commun.
• Le parcours d'enchère rafraîchit les droits après une enchère placée.
• Une personne en mode « Admin de l'organisation » (isOrgAdmin) passe systématiquement les vérifications d'accès du frontal, sans re-vérification clé par clé côté client; la garantie qu'elle ne dépasse pas les accès de ses contrats est appliquée lors du calcul de ce statut, pas au moment de la vérification.
• L'accès à une plateforme (admin, espace personnel, marketplace) est vérifié en plus de l'accès à l'action elle-même: une personne peut détenir un accès sans pouvoir atteindre la plateforme qui l'exploite.
• Chaque route protégée de l'admin et de l'espace personnel peut déclarer la liste des accès requis pour l'atteindre; si aucun de ces accès n'est présent, la navigation est redirigée vers une page d'erreur dédiée avant le chargement du contenu.

Actions contrôlées

Accès nommés et actions associées

Chaque accès porte un nom composé du domaine (thème), de la ressource et de l'action, par exemple SALES.CONTRACT.MANAGE dans le code, exposé côté session sous la forme aplatie SALES_CONTRACT_MANAGE. La liste des accès est un catalogue fermé et centralisé (le code ne permet pas d'en inventer un autre à la volée) ; en pratique, une vérification d'accès porte toujours sur une clé de ce catalogue.

Les principaux, côté organisation cliente :

Cette liste reprend l'intégralité du catalogue AccessKeys du package partagé @auctelia/access-manager (consommé aussi bien par les fronts de tars-monorepo que par le backend auctelia/api), soit une cinquantaine de clés au total. Certaines n'apparaissent pour l'instant que dans l'admin legacy (V1) et ses traductions: elles restent valides et actives côté droits, mais aucun usage n'a été retrouvé dans le code de l'admin moderne exploré — signe probable d'un écart de parité entre les deux versions plutôt que d'un accès obsolète.

Ces accès sont regroupés par thème (INTERNAL, FINANCE, SALES, SUPER, PURCHASE, ORGANISATION, SEANCE, EVENT, ITEM), ce qui correspond aux thèmes affichés dans l'onglet « Accès » d'un contrat. Les thèmes INTERNAL et SUPER ne comportent que des accès à usage interne.

Quand l'accès manque, le frontal ne réagit pas toujours de la même façon : l'action peut être masquée, désactivée, ou échouer avec un message explicite au moment du clic. Par exemple, une personne disposant de ITEM_ITEM_MANAGE sans ITEM_ITEM_PUBLISH voit l'item et peut l'enregistrer, mais la bascule de publication reste grisée; une personne sans ORGANISATION_USER_MANAGE voit la liste des utilisateurs sans les boutons d'invitation, de blocage et de modification; une personne sans PURCHASE_BID_CREATE voit le formulaire d'enchère et reçoit un message d'erreur au clic. Certaines pages entières sont protégées en amont : la navigation vers une route déclarée avec une liste d'accès requis redirige vers une page d'erreur (403) si aucun des accès n'est présent, avant même l'affichage du contenu.

Effets du changement d'organisation

Quand l'utilisateur change d'organisation active:

• ses ventes accessibles changent;
• ses factures accessibles changent;
• ses documents visibles changent;
• ses limites d'enchère peuvent changer;
• ses contrats applicables changent;
• ses rôles admin organisation peuvent changer;
• ses actions marketplace peuvent être autorisées ou bloquées.

Blocages courants

Le statut d'une personne suit une progression TO_VALIDATE → EMAIL_VALIDATED → MOBILE_VALIDATED → VALIDATED → COMPLETED, avec deux statuts de sortie possibles à tout moment : DISABLED et BLOCKED (le statut ARCHIVED clôt le compte). Une personne bloquée (BLOCKED) ne peut être débloquée que depuis ce statut précis; un admin disposant de ORGANISATION_USER_MANAGE peut bloquer une personne dans n'importe quel statut de la progression, hors BLOCKED, et la débloquer seulement si elle est BLOCKED. L'organisation suit une logique de statuts comparable (TO_VALIDATE, VALIDATED, DISABLED, BLOCKED, ARCHIVED).

Interaction frontaux

Pour lever un doute entre le paramétrage et les droits réellement appliqués à une session, voir Vérifier les accès d'un utilisateur.