Journal d'audit

Audience

Cet article s'adresse aux opérateurs de la plateforme GCM. Les administrateurs d'église voient une tranche par organisation des mêmes données sur Paramètres -> Activité dans leur espace de travail — cette page est le surensemble inter-locataires, réservé au personnel.

Le Journal d'audit (/platform/audit) est l'enregistrement canonique de chaque action du personnel et de chaque événement pertinent pour la sécurité dans GCM. Organisation créée, plan modifié, remboursement effectué, usurpation d'identité démarrée, usurpation d'identité terminée, échec de connexion, réinitialisation de mot de passe déclenchée, rôle attribué — tout atterrit dans platform_audit_log avec l'acteur, la cible, l'horodatage et un blob de métadonnées JSONB. Cet onglet est la façon dont vous demandez "qui a fait quoi, quand, à qui".

Le bandeau KPI

Trois compteurs en haut, tous en direct :

• Total des événements — chaque ligne dans platform_audit_log, depuis toujours. Surtout utile comme vérification de bon sens que le rédacteur écrit encore.
• Événements aujourd'hui — lignes depuis minuit dans le fuseau horaire de la plateforme. Une journée normale est de l'ordre de quelques milliers ; un week-end calme, de quelques centaines. Un zéro soudain signifie généralement que le rédacteur d'audit est cassé.
• Usurpations d'identité (7 jours) — lignes où action ilike '%impersonat%' sur la semaine dernière. C'est la métrique à surveiller — chaque début, fin et échec d'usurpation d'identité compte. Les pics ici méritent une lecture rapide.

La visionneuse

Sous le bandeau se trouve le composant unifié AuditLogViewer, également utilisé par la page Activité à l'échelle de l'organisation. Il prend en charge :

• Plage de dates — du / au avec granularité journalière. Par défaut sur les 30 derniers jours.
• Action — liste déroulante des valeurs distinctes dans platform_audit_log.action. La liste est auto-remplie depuis la DB pour rester à jour à mesure que de nouvelles actions sont ajoutées.
• Acteur — correspondance partielle d'e-mail. À utiliser pour restreindre à un utilisateur du personnel.
• Organisation — par id d'organisation. Recherche dans le chemin jsonb metadata->>target_org_id afin de capter chaque événement qui mentionne une organisation, même quand la propre organization_id de la ligne est nulle.

Les filtres se composent ; en effacer un garde les autres actifs.

Lire une ligne

Chaque ligne du tableau affiche :

• Quand — horodatage exact.
• Action — le verbe. L'ensemble complet est documenté dans la migration qui ajoute la contrainte de colonne ; les plus courantes incluent org_created, plan_updated, refund_processed, subscription_overridden, impersonation_started, impersonation_failed, email_template_updated, auth_login_failed.
• Acteur — e-mail de l'utilisateur du personnel qui a déclenché la ligne. Les lignes de fonctions edge et de cron affichent system@geniuschurchmanager.com.
• Cible — le nom de l'organisation affectée (résolu depuis les métadonnées) ou "platform" pour les lignes à l'échelle de la plateforme.
• Métadonnées — aperçu JSONB tronqué.

Cliquez sur n'importe quelle ligne pour développer les métadonnées. Les remboursements, par exemple, stockent le montant initial, le montant remboursé, la méthode manuelle (si hors plateforme) et le texte de la raison. Les surcharges d'abonnement stockent les valeurs avant / après pour chaque champ modifié.

Enquêtes courantes

"Qui a remboursé ce paiement de 79 $ de First Church mardi ?" Filtrez action = refund_processed, réglez la plage de dates sur mardi, filtrez organisation = First Church. La colonne acteur est votre réponse.

"Quelqu'un de notre équipe s'est-il connecté à l'espace de travail de Second Baptist ce mois-ci ?" Filtrez action = impersonation_started, réglez la plage de dates sur "le mois", filtrez organisation = Second Baptist. Chaque ligne porte la raison dans les métadonnées — lisez-les ensuite.

"Le plan du client a-t-il vraiment changé la semaine dernière ou se l'imagine-t-il ?" Filtrez action = plan_updated, filtrez organisation = <son org>. Si une ligne existe, les métadonnées affichent l'id du plan avant/après et qui l'a fait. Si aucune ligne n'existe, le client se trompe — mais vérifiez aussi subscription_overridden au cas où le changement serait passé par la boîte de dialogue d'édition d'opérations de facturation.

"Combien d'échecs de connexion ces dernières 24 heures ?" Action auth_login_failed, plage de dates "hier à aujourd'hui". Croisez l'acteur avec l'onglet Utilisateurs pour voir si un compte est ciblé.

Référence des actions (les plus importantes)

Action	Quand elle se déclenche	Métadonnées clés
org_created	Nouvelle organisation provisionnée	org_name, org_slug, plan_id, created_by_admin
org_deleted	Suppression définitive	org_name, org_slug, member_count, reason
plan_updated	Changement de plan en ligne sur l'onglet Organisations	target_org_id, previous_plan, new_plan
subscription_overridden	Boîte de dialogue Modifier l'abonnement	target_org_id, before, after, reason, email_sent
renewal_triggered	Renouvellement manuel (mode facturation)	target_org_id, mode, reason, result
refund_processed	Modale de remboursement	payment_history_id, amount, refund_type, reason
impersonation_started	Ouverture du compte depuis la feuille d'organisation	target_org_id, org_name, reason
impersonation_ended	Retour à la plateforme	target_org_id
impersonation_failed	Le RPC a refusé le démarrage	target_org_id, reason, error
email_template_updated	Enregistrement dans l'onglet Modèles d'e-mails	slug, before, after
landing_content_updated	Enregistrement dans l'onglet Landing	section, content_key, locale, before, after
branding_settings_saved	Enregistrement dans l'onglet Marque	keys
auth_login_failed	Mauvais mot de passe ou e-mail inconnu	email, ip, user_agent

La liste n'est pas exhaustive — de nouvelles actions sont ajoutées à chaque fonctionnalité.

Conservation

platform_audit_log n'est pas purgé automatiquement. Les lignes vivent pour toujours jusqu'à ce que quelqu'un les supprime, et nous n'exposons délibérément pas d'interface pour le faire — la piste d'audit est la piste d'audit. Si vous devez réduire la taille de la table pour une migration, écrivez une migration qui archive vers une table de stockage froid et documentez-la dans docs/runbooks/.

Ce que vous ne pouvez pas faire ici

La visionneuse est en lecture seule. Il n'y a pas d'"édition", pas d'"annotation", pas de "marquer comme important". Si vous avez besoin d'attacher du contexte à une ligne, écrivez une nouvelle ligne en effectuant l'action qu'elle décrit (par exemple, ajoutez un commentaire Slack sur le ticket que la ligne d'audit référence, ou ouvrez le problème Sentry lié). Traitez le journal d'audit comme un enregistreur de vol : lecture seule, écriture unique, jamais l'endroit où l'on va pour effacer un problème.