Ce n’est pas un problème lié à cette excellente extension, mais quelqu’un sait-il comment récupérer ces données ? J’ai l’explorateur de données, mais je ne connais pas la structure de toutes les tables de la base de données. Je ne sais pas dans quelles tables chercher ces données ni lesquelles il faut joindre pour les obtenir.
Voir le message précédent, je pense :
Non, ces paramètres du site étaient déjà activés et ce sont les données que j’ai déjà.
Mais cela n’inclut pas les enregistrements administratifs, comme Angus l’a écrit ci-dessus :
Et maintenant, je cherche comment je pourrais extraire ces enregistrements administratifs.
Hmm, je pensais que c’était le sens de étendu — c’est tout ce qui est pratiquement exportable.
Oui, c’est exact. Malheureusement, il n’y a pas de réponse simple à cette question. C’est pourquoi ces dossiers ne sont pas inclus, comme expliqué ci-dessus. Notez en particulier
Cela dit, pour recueillir des dossiers supplémentaires contenant l’identifiant de l’utilisateur, vous pouvez utiliser cette approche.
-
Installez le plugin Data Explorer
-
Créez une nouvelle requête (peut-être appelez-la “Dossiers supplémentaires de l’utilisateur (RGPD)”)
-
Effectuez une recherche pour “user_id” dans l’explorateur de schéma à droite pour voir quelles tables de base de données incluent un user_id. Vous verrez qu’un certain nombre d’entre elles sont déjà incluses (voir la liste dans le premier message + “activité utilisateur” comme mentionné dans mon deuxième message).
-
Déterminez l’
user_idde l’utilisateur concerné (vous pouvez le trouver à l’adresse/u/nomutilisateur.json) -
Pour chaque table supplémentaire que vous souhaitez inclure, construisez une requête qui extrait les lignes où le
user_idcorrespond à l’identifiant pertinent. Par exemple :select * from [nom_table] where user_id = [user_id]
Je vous suggère d’examiner chacune de ces tables “supplémentaires” en fonction de leurs propres mérites, plutôt que de simplement tenter de télécharger chaque dossier contenant l’identifiant de l’utilisateur.
Les dossiers peuvent contenir d’autres informations, pertinentes pour d’autres utilisateurs ayant des intérêts contraires, ou peuvent être sensibles d’une autre manière. Malheureusement, il n’y a pas de réponse unique à la question de la “portée” ici. Vous devrez prendre cette décision en fonction de votre interprétation spécifique de vos responsabilités. Le RGPD n’est pas la seule responsabilité pertinente ici. Vous ne devriez pas simplement remettre chaque dossier contenant l’identifiant d’un utilisateur.
Je suis en fait un peu incertain quant à ce qui motive l’intérêt pour ces dossiers supplémentaires ? Est-ce quelque chose que l’utilisateur a demandé, c’est-à-dire au-delà de ce qui est déjà inclus ? S’ils ne l’ont pas fait, qu’est-ce qui motive cela ? Une interprétation différente de vos responsabilités en vertu du RGPD par rapport à ce que j’ai exposé ci-dessus ? Si tel est le cas, je serais curieux d’en savoir plus et de connaître le raisonnement juridique derrière cela (je pourrais souhaiter intégrer ce raisonnement dans ce plugin).
Oui, mais bien sûr, nous ne sommes pas disposés à lui fournir toutes ces informations. Surtout si les enregistrements contiennent également des données d’autres utilisateurs. Nous souhaitons simplement être préparés à fournir ces informations supplémentaires si vraiment nécessaire. Nous ne fournirons probablement pas ces informations à cet utilisateur, mais nous pourrions devoir en communiquer aux autorités, car nous nous attendons à ce que l’utilisateur s’adresse à elles.
Notre nouveau délégué à la protection des données nous a également indiqué que nous ne devrions pas encore fournir les dossiers administratifs.
Je vois.
Si votre délégué à la protection des données estime que des enregistrements supplémentaires sont nécessaires et a certaines tables à l’esprit, je serais heureux de fournir une requête SQL plus spécifique pour vous aider. Pour les raisons que j’ai mentionnées, je ne souhaite pas désigner des tables supplémentaires spécifiques à fournir en tant que conseil général en dehors du contexte d’un cas.
Cependant, si vous avez besoin de quelque chose de spécifique à mesure que ce cas avance, je serais heureux de vous aider à titre gracieux, car cela correspond à l’esprit de ce plugin, à savoir faciliter la navigation des communautés Discourse dans le RGPD. Si cela se produit, que vous avez des tables spécifiques à l’esprit et que vous avez besoin d’assistance pour la requête SQL, envoyez-moi un message privé ici sur meta.
En bref, je suis heureux de fournir une assistance technique (non juridique) ponctuelle aux communautés Discourse en réponse à des cas spécifiques dans le cadre du RGPD, mais je suis conscient de ne pas établir de normes générales au-delà de ce qui est raisonnable pour la majorité des cas. S’il existe un argument juridique de ce type suggérant que la portée du plugin devrait être élargie, je suis ouvert à cela.
Eh bien, notre délégué à la protection des données m’a indiqué qu’il n’y a pas, pour le moment, besoin d’extraire de données administratives supplémentaires. Merci beaucoup pour votre aide ; si nécessaire, je reviendrai vers vous.
Ce plugin est génial !
La gestion des demandes d’accès aux données (SAR) dans le cadre du RGPD est une corvée, une perte de temps totale, et cela permet de tout couvrir avec beaucoup plus de sérénité. Merci.
Avez-vous prévu d’ajouter plus de fonctionnalités ? Je rencontre particulièrement des difficultés avec les principes de conservation et de minimisation des données. Je suis notamment intéressé par la minimisation des « dossiers administratifs » — les messages privés et les publications dans les espaces d’équipe qui peuvent contenir des notes sur les adresses IP et d’autres données personnelles nécessitant un tri et une recherche manuels. Cinq ans plus tard, il y a trop de choses à auditer, et les anciens messages ont peu de valeur, je veux donc / dois les supprimer définitivement. J’aimerais d’ailleurs appliquer une politique de conservation de seulement six mois pour ce type de messages et de discussions privées.
Je peux donc sélectionner et supprimer des éléments via Rake, mais ils sont simplement marqués comme supprimés et sont toujours présents dans la base de données ![]()
J’ai donc pensé à un plugin « oblitérateur » qui soit modifierait le texte brut et formaté des messages supprimés en quelque chose comme « ce message a été oblitéré », soit (de préférence) désassemblerait et supprimerait entièrement les messages. N’ayant jamais écrit de Ruby ni créé de plugin, je ne suis pas dans une position idéale pour démarrer, mais je pourrais éventuellement écrire du SQL pour l’exécuter directement sur la base de données, puis utiliser Rake pour reconstruire les index de recherche par la suite.
@angus - Je me suis demandé si, dans vos considérations juridiques, vous aviez des réflexions sur les aspects de conservation des données du RGPD et sur la manière dont vous les gérez ?
Intéressant !
Oui, je suis ouvert à l’idée d’ajouter une fonctionnalité pour cela. Je devrai l’examiner plus en détail après avoir fait quelques recherches supplémentaires.
Pourriez-vous s’il vous plaît soumettre une demande de fonctionnalité détaillée (en sélectionnant « Outils juridiques » à l’étape du plugin) en exposant tous les détails pertinents de votre cas d’utilisation et toute autre recherche que vous avez collectée ? Je ferai un suivi et m’engagerai ensuite après avoir effectué quelques recherches préliminaires.
ce plugin est-il toujours maintenu ?
Impossible de changer le paramètre pour activer le plugin ![]()
Salut Nick, je vais essayer de regarder ça la semaine prochaine.
J’apprécie vraiment ! ![]()
Salut, je suis tombé sur ça et je me demande quelle partie est déjà incluse ou prévue dans le cœur.
On dirait que quelque chose s’est cassé avant-hier
Impossible d’approuver les utilisateurs et de charger des pages comme /admin/users/5996.json
plugins/discourse-legal-tools/lib/export_csv_file_extension.rb:41:in `can_export_entity?'
app/serializers/admin_detailed_user_serializer.rb:189:in `include_latest_export?'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:375:in `include?'
(eval at /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/active_model_serializers-0.8.4/lib/active_model/serializer.rb:467):74:in `_fast_attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:456:in `attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:480:in `_serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:359:in `serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:347:in `as_json'
app/controllers/application_controller.rb:499:in `serialize_data'
app/controllers/application_controller.rb:508:in `render_serialized'
app/controllers/admin/users_controller.rb:48:in `show'
actionpack (8.0.4) lib/action_controller/metal/basic_implicit_render.rb:8:in `send_action'
Oui, cela est cassé depuis un certain temps. La plupart des fonctionnalités sont maintenant dans le noyau.
J’ajouterai l’étiquette broken.