Workflow rapports et audit

Ce workflow explique comment les rapports et l'historique soutiennent les opérations.

Rapport

flowchart TD
  demande["Demande de rapport"] --> filtres["Choix des filtres"]
  filtres --> droits["Contrôle droits"]
  droits --> contenu["Sélection des données"]
  contenu --> generation["Génération"]
  generation --> usage["Usage métier"]
  usage --> trace["Trace si rapport sensible"]

Audit

flowchart TD
  action["Action sensible"] --> capture["Capture auteur, date, objet, action"]
  capture --> context["Ajout contexte et motif"]
  context --> storage["Historique conservé"]
  storage --> support["Consultation support ou contrôle"]

Détail complet dans les domaines fonctionnels Rapports et Audit trail; ce qui suit résume les règles au niveau workflow.

Règles

• Un rapport ne doit contenir que les données utiles au rôle demandeur.
• Un rapport financier doit être réservé aux profils finance ou admin.
• Un export contenant des données personnelles doit être justifié.
• Une action sensible doit laisser une trace.
• L'audit ne remplace pas la règle de gestion, il explique ce qui s'est passé.
• La consultation de l'audit trail est réservée aux comptes admin (contrôle sur le statut admin, pas sur un profil admin particulier); pas d'accès self-service.

Rapports observés

• Les rapports couvrent lots, enchères, factures, commissions, retraits, personnes, organisations, recherches sauvegardées, watchlists, séances et audit.
• Les rapports de facture exposent statuts, montants, modes, types de documents, acheteur et vendeur.
• Les rapports de lots exposent vendeur, statut, dates, prix, taux, mode de vente, self-service, nombre d'enchères et date de publication.
• Les rapports de retrait consolident lots, rendez-vous, factures, commentaires, vendeurs et adresses.
• Les exports analytiques synchronisent aussi les suppressions.
• Distinct des rapports exportables: le tableau de bord admin (restitution vivante, filtrable boutique/portefeuille) et les vues sauvegardées (PRIVATE/ORGANISATION/ADMIN_GROUP, modifiables seulement par leur créateur, à jour de révision) sont deux mécanismes de pilotage séparés — voir le domaine fonctionnel Rapports pour leurs règles précises.

Audit observé

• Une trace d'audit contient un événement, une organisation, une personne, une IP, des métadonnées libres (meta) et une liste d'entités liées (related).
• Les traces peuvent être recherchées par identifiant de trace, par personne, ou par type + identifiant d'entité liée; sans aucun filtre, la recherche est bornée aux 500 traces les plus récentes.
• Le filtre par période (dernière heure, aujourd'hui, semaine, mois, année) n'existe que pour une recherche par personne, pas pour les autres types d'entité.
• Les résultats sont triés du plus récent au plus ancien.
• Une enchère crée une trace BID_CREATED; un refus d'autorisation d'accès à une vente crée une trace SALE_AUTHORIZATION (uniquement en cas de refus, pas à chaque contrôle réussi).
• L'ancienne et la nouvelle valeur d'une modification ne sont présentes que si l'action qui déclenche la trace choisit de les fournir dans les métadonnées libres; ce n'est pas systématique.
• Aucune purge ni politique de rétention automatique n'a été identifiée dans le code consulté.