Anonymisation des utilisateurs et staff_action_logs

Soutien
1

Bonjour à tous,

Je trouve étrange que, après avoir anonymisé un utilisateur, je puisse toujours voir l’ancien nom d’utilisateur et l’ancien adresse e-mail liés au nouveau nom d’utilisateur « anonymisé » et aléatoire dans admin/logs/staff_action_logs. Cela ne me semble pas être une véritable anonymisation, et le fait de conserver ces données dans les journaux indéfiniment pourrait constituer une infraction aux lois européennes sur le RGPD.

Je ne vois pas non plus grand intérêt à conserver les journaux de ces actions. Pourriez-vous m’indiquer comment supprimer ces journaux de manière permanente ? Serait-il également possible de nettoyer périodiquement les journaux de Discourse et de limiter la politique de journalisation d’une certaine manière ?

Merci d’avance.

2

Bonjour,

Vous devez décocher ce paramètre log anonymizer details pour éviter que cela ne se reproduise. Pour être conforme au RGPD, vous devez le désactiver.

Je ne suis pas certain en revanche de pouvoir le supprimer des journaux.

3

Bonjour Ondrej, merci pour votre réponse rapide.

J’ai désactivé cette option, mais les actions déjà consignées restent visibles. Comment puis-je supprimer ces journaux ?

4

Pour supprimer les anciennes lignes après avoir activé le paramètre mentionné ci-dessus, inspectez d’abord les lignes pertinentes de l’historique des utilisateurs via la console Rails :
UserHistory.where(action: 24)

Une fois certain que la requête ci-dessus couvre toutes les lignes pour lesquelles vous voulez vous assurer qu’aucune donnée utilisateur n’est plus attachée dans les journaux, exécutez ceci dans la console Rails :
UserHistory.where(action: 24).update_all(details: nil, email: nil)

(Les champs « details » et « email » contiennent les données personnelles et seront effacés par la commande ci-dessus. La suppression des lignes n’est pas nécessaire pour la conformité RGPD, mais si vous le souhaitez, utilisez delete_all.)

Exécutez à vos propres risques et effectuez des sauvegardes avant d’exécuter des commandes de base de données à grande échelle.

Vous voudrez peut-être également déclencher un vacuum sur PostgreSQL afin que tous les tuples morts contenant encore ces valeurs soient effectivement supprimés, après avoir exécuté les commandes ci-dessus.

5

Merci Hooksmith, ta solution fonctionne. Cependant, je ne vois aucune raison de ne pas l’exécuter de temps en temps :

UserHistory.delete_all

Peut-être que je vais écrire un script pour l’exécuter chaque semaine.
Prends soin de toi.

6

Cette solution serait préférable, car il m’est parfois arrivé de devoir annuler une action anonyme en raison d’une mauvaise appréciation de la part d’un membre du personnel. Ce n’est pas parfait, mais en tant qu’administrateur, j’ai trouvé un moyen de restaurer et d’anonymiser un utilisateur.

7

Cette table fournit les données utilisées pour alimenter les journaux d’actions du personnel de votre site. Il est utile de conserver l’historique des membres du personnel de votre site intact. À tout le moins, cela aide au débogage des problèmes sur le site liés à des modifications de paramètres effectuées par des membres du personnel.