Règles transverses
Règles transverses
Ces règles s'appliquent à tous les parcours TARS, quel que soit le domaine ou le frontal.
Accès
| Règle | Application |
|---|---|
| Une action sensible exige une session valide | Enchérir, payer, déposer un document, modifier une organisation, bloquer un compte |
| L'organisation active détermine le contexte | Droits, ventes, factures, documents et statistiques changent selon l'organisation active de la session |
| Les droits doivent être calculés au moment de l'action | Le frontal affiché ne suffit pas à autoriser: chaque appel recalcule rôles, contrats et access keys |
| Un admin doit avoir le bon périmètre | Un profil admin n'a pas nécessairement tous les accès; un super admin reçoit l'ensemble des droits sur tous les shops |
| Sans organisation de rattachement, aucun droit de session n'est retourné | Une personne sans organisation active ne peut agir dans aucun domaine métier |
Le détail du calcul des droits (contrats, rôles métier, access keys, procurations, séparation par shop) est décrit dans Accès et autorisations et Calcul des droits d'accès.
Statuts
Chaque domaine porte son propre cycle de statuts; un objet ne peut avancer que par les transitions que son workflow autorise, jamais par modification directe d'un champ. Le détail complet, statut par statut et droit par droit, est dans Statuts et transitions; pour la facture spécifiquement, voir La facturation.
Un point qui ne figure pas ailleurs: le commentaire (question, remarque) a lui aussi un cycle propre — statuts TO_CHECK, REPLIED, IGNORED, SIGNALED, CLOSED, types REMARK/QUESTION/ACCEPTED/REFUSED/REQUEST_MODIFY — piloté par les actions REPLY, EDIT, IGNORE, CLOSE, DELETE_ANSWER, SIGNAL. IGNORE exige un motif (ignoredReason) et REPLY/EDIT portent un indicateur public qui décide si la réponse est un jour visible de l'auteur de la question.
Règles générales qui découlent de ces cycles:
- Une correction ramène l'objet à une étape antérieure du même workflow (document refusé, lot à modifier), jamais à un état arbitraire.
- Un statut final (facture soldée, document validé, lot supprimé) limite les modifications possibles, mais ne doit jamais faire disparaître l'historique utile à l'audit, à la finance ou à la conformité.
- Une suppression logique (
DELETED,REMOVED,ARCHIVED) conserve l'objet en base pour la traçabilité; elle ne correspond pas à un effacement physique.
Blocage d'une organisation ou d'une personne
Le blocage (action BLOCK) et le déblocage (UNBLOCK) d'une organisation exigent chacun un motif et peuvent porter un commentaire libre, conservés avec l'action. Une fusion d'organisations (MERGE) exige également un commentaire obligatoire et identifie l'organisation absorbée.
Ce que cela implique concrètement:
- Un motif de blocage/déblocage est obligatoire; il figure ensuite dans l'historique de l'organisation.
- Bloquer une organisation retire l'accès aux fonctions sensibles à toutes les personnes qui agissent en son nom, sans qu'il soit nécessaire de bloquer chaque personne individuellement.
- Le blocage d'une personne (statut
BLOCKED) est distinct de celui d'une organisation: il empêche la connexion et les actions de cette personne, y compris si son organisation reste active. - Au-delà de ces mécanismes vérifiables dans le code, certaines conséquences en cascade (par exemple sur des enchères ou ventes en cours au moment du blocage) relèvent de procédures organisationnelles traitées au cas par cas par les équipes support/compliance plutôt que d'un automatisme technique documenté ici.
Confidentialité
Le détail par donnée et par frontal est dans Confidentialité. Les principes transverses:
| Règle | Application |
|---|---|
| Les données personnelles sont limitées au besoin métier | Personnes, documents d'identité, contacts, adresses |
| Les données financières sont réservées aux profils autorisés | Factures, paiements, commissions, mouvements bancaires |
| Les enchères concurrentes restent protégées | Marketplace et espace personnel: seule la personne concernée voit ses propres offres en détail |
| Les commentaires internes ne sont pas publics | Une réponse à une question n'est visible de l'auteur que si elle est explicitement marquée publique |
Audit
| Règle | Application |
|---|---|
| Une action sensible doit être tracée | Validation, refus, blocage, paiement, modification critique |
| Une action automatique doit être identifiable | Notifications, clôtures, synchronisations, génération de documents |
| Une correction admin doit garder son contexte | Motif, auteur, objet, date |
Ce que l'audit trail enregistre concrètement, par entrée: un type d'événement (event), l'adresse IP d'origine quand elle est pertinente, les entités liées (related, une liste de couples type/identifiant), l'organisation et/ou la personne à l'origine de l'action, et des métadonnées libres (meta). La consultation admin (page « Audit » des outils) filtre par identifiant d'entité, par type ou par période (timeRange); elle reste un accès très restreint, non disponible aux frontaux marketplace et espace personnel.
Règles observées dans l'implémentation
| Règle | Application observée |
|---|---|
| Les droits sont recalculés par contexte | Personne, organisation active, contrats, rôles, access keys et shop |
| Les objets ont des filtres obligatoires en lecture | Personnes, adresses et rendez-vous exigent des critères explicites |
| Les actions dépendent du statut | Lots, contrats, documents, commentaires et factures |
| Les changements importants réindexent les objets | Personnes, organisations, lots, séances, marques et modèles |
| Les décisions enrichissent les métadonnées | Validation, refus, archivage, expiration, blocage, audit |
| Les notifications sont conditionnelles | Documents, recherches sauvegardées, commentaires, séances et autorisations |
Procurations et organisations complexes
Comment une organisation agit pour une autre grâce aux procurations, comment les droits se croisent, ce que montre l'espace personnel et qui reçoit les emails, illustré sur une organisation fictive.
Rôles et autorisations
Cette page distingue deux choses : les rôles métier attribuables à un utilisateur client, qui sont un objet concret de la plateforme, et la lecture métier des profils d'acteurs, qui sert à comprendre les responsabilités sans correspondre à un paramétrage.