Это не проблема этого замечательного плагина, но знает ли кто-нибудь, как получить эти данные? У меня есть Data Explorer, но я не знаю структуру всех таблиц базы данных, в каких таблицах мне нужно искать эти данные и какие из них нужно соединить, чтобы получить их.
Посмотрите предыдущий пост, я думаю:
Нет, эти настройки сайта уже были включены, и у меня уже есть эти данные.
Однако они не включают административные записи, как указал выше Энгус:
Теперь я изучаю, как можно извлечь эти административные записи.
Хм, я думал, что это и есть смысл расширенного — это практически всё, что можно экспортировать.
Да, всё верно. К сожалению, на этот вопрос нет простого ответа. Именно поэтому эти записи не включены, как объяснялось выше. Обратите особое внимание на следующее:
Тем не менее, чтобы собрать дополнительные записи, содержащие идентификатор пользователя (user_id), можно использовать следующий подход:
-
Установите плагин Data Explorer.
-
Создайте новый запрос (например, назовите его «Дополнительные записи пользователя (GDPR)»).
-
В правой части найдите в схеме базы данных поле «user_id», чтобы увидеть, в каких таблицах оно присутствует. Вы заметите, что многие из них уже включены (см. список в первом посте + «активность пользователя», упомянутую во втором моём посте).
-
Определите
user_idинтересующего пользователя (его можно найти по адресу/u/username.json). -
Для каждой дополнительной таблицы, которую вы хотите включить, составьте запрос, извлекающий строки, где
user_idсовпадает с нужным идентификатором. Например:select * from [table_name] where user_id = [user_id]
Я рекомендую рассматривать каждую из этих «дополнительных» таблиц отдельно, исходя из её значимости, а не пытаться выгрузить все записи, содержащие идентификатор пользователя.
Записи могут содержать информацию, касающуюся других пользователей, чьи интересы противоречат вашим, либо быть чувствительными в ином смысле. К сожалению, универсального ответа на вопрос о «объёме» данных здесь нет. Вам необходимо принять решение, исходя из того, как вы интерпретируете свои конкретные обязанности. GDPR — не единственная нормативная база, имеющая значение в данном случае. Не стоит просто передавать все записи, содержащие идентификатор пользователя.
Честно говоря, мне не совсем понятно, что именно мотивирует интерес к этим дополнительным записям? Это запрос самого пользователя, то есть данные, выходящие за рамки уже включённых? Если пользователь не запрашивал их, то что побуждает вас к этому? Иная интерпретация ваших обязанностей согласно GDPR, чем та, которую я изложил выше? Если так, мне было бы интересно узнать больше о правовых основаниях такого подхода (возможно, я захочу учесть эту аргументацию при доработке этого плагина).
2 лайка
Да, но, конечно, мы не готовы предоставить ему всю эту информацию. Особенно если записи содержат также данные других пользователей. Мы просто хотим быть готовы предоставить эту дополнительную информацию, если она действительно потребуется. Скорее всего, мы не предоставим эту информацию данному пользователю, но нам, возможно, придётся сообщить сведения органам власти, поскольку мы ожидаем, что пользователь обратится к ним.
Наш новый сотрудник по защите данных также сказал, что пока мы не должны предоставлять административные записи.
1 лайк
Понятно.
Если ваш сотрудник по защите данных решит, что потребуются дополнительные записи и у него уже есть в виду определённые таблицы, я с радостью предоставлю более конкретный SQL-запрос, чтобы помочь вам. По причинам, которые я уже упомянул, я не хочу рекомендовать конкретные дополнительные таблицы в качестве общего совета вне контекста конкретного случая.
Однако, если в ходе рассмотрения этого дела вам потребуется что-то конкретное, я с радостью окажу помощь pro bono, так как это соответствует духу этого плагина, то есть упростить сообществам Discourse соблюдение GDPR. Если такое случится, и у вас будут на примете конкретные таблицы и понадобится помощь с SQL-запросом, напишите мне в личные сообщения здесь, на meta.
Коротко: я готов предоставить разовую техническую (не юридическую) помощь сообществам Discourse в ответ на конкретные случаи в рамках GDPR, но я стараюсь не устанавливать общие стандарты за пределами того, что разумно для большинства случаев. Если появится юридический аргумент в пользу расширения функционала плагина, я открыт к обсуждению.
4 лайка
Хорошо, наш сотрудник по защите данных сообщил мне, что на данный момент нет необходимости извлекать дополнительные административные данные. Большое спасибо за вашу помощь, и если потребуется, я снова к вам обращусь.
3 лайка
Этот плагин отличный!
Обработка запросов субъектов данных в рамках GDPR — это боль, полная трата времени, а этот плагин помогает справиться со всем этим с гораздо большей уверенностью. Спасибо.
Планируется ли добавление новых функций? В частности, я испытываю трудности с принципами удержания и минимизации данных. Меня особенно интересует минимизация «административных записей» — сообщений и постов в командных разделах, которые могут содержать заметки об IP-адресах и других персональных данных, требующих ручной сортировки и поиска. Пять лет спустя данных слишком много для аудита, а ценность старых сообщений невелика, поэтому я хочу/нуждаюсь в их постоянном удалении. На самом деле я хотел бы установить политику удержания таких сообщений и приватных переписок всего на 6 месяцев.
Хотя я могу выбирать и удалять данные с помощью rake, они лишь помечаются как удалённые и по-прежнему полностью присутствуют в базе данных 
Поэтому я подумываю о плагине «уничтожитель», который либо заменит исходный и обработанный текст удалённых постов на что-то вроде «это сообщение было уничтожено», либо (что предпочтительнее) разберёт и полностью удалит посты. Поскольку я никогда не писал на Ruby или создавал плагины, я не нахожусь в идеальной стартовой позиции, хотя, возможно, смогу просто написать SQL-запросы для прямого выполнения в базе данных, а затем использовать rake для перестроения поисковых индексов.
@angus — я задавался вопросом, учитывали ли вы в своих юридических соображениях аспекты удержания данных в рамках GDPR и как вы с этим справляетесь?
1 лайк
Интересно!
Да, я открыт к идее добавить такую функцию. Мне нужно будет ещё глубже изучить этот вопрос после проведения дополнительных исследований.
Пожалуйста, отправьте подробный запрос на новую функцию (выберите «Юридические инструменты» на этапе настройки плагина), описав все детали вашего сценария использования и любые другие исследования, которые вы провели. После этого я изучу фоновую информацию и свяжусь с вами для обсуждения.
2 лайка
Этот плагин всё ещё поддерживается?
Не могу переключить настройку, чтобы включить плагин 
Привет, Ник, я постараюсь взглянуть на это на следующей неделе.
1 лайк
Очень признателен!
Привет, наткнулся на это и интересно, насколько это уже включено в ядро или планируется к включению.
1 лайк
Похоже, что что-то сломалось где-то до позавчерашнего дня
Невозможно одобрить пользователей и загрузить страницы вроде /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'
Да, это не работает уже довольно давно. Большинство функций сейчас находится в ядре.
Я добавлю тег broken.