Plugin Strumenti Legali

[GuidoD (Guido Drehsen)]

@GuidoD

If I would like to also include ‘administrative’ records with the user’s user_id such as flags, complaints and staff whispers, what would be the best SQL statements to get the data with the data explorer?
If needed I could then provide this data separately to the user who requested the data.

it is not a problem of this great plugin but does someone know how can get this data. I do have the data explorer but I do not know the structure of all database tables and in which tables I would have to look for the data and which ones I would have to join in order to get this data.

[Ed_S]

@GuidoD

does someone know how can get this data

See the earlier post, I think:

@angus

There are now two site settings that enable the extended download…

[GuidoD (Guido Drehsen)]

@Ed_S

See the earlier post, I think:

no these site settings were already enabled and that is the data I do already have.
But that does not include the administrative records , as Angus has written above:

@angus

We also considered whether to include ‘administrative’ records with the user’s user_id such as flags, complaints and staff whispers. We decided against this, reasoning as follows:

• They’re already in the territory of information associated with the user purely by their identifier. They are not information about the user per se (i.e. name, email, age, location etc). This is already assuming a wide interpretation of A.4.1.
• Whether administrative records intrude on the privacy of other parties, or other relevant concerns (i.e. R. 63.5 & A.15.4) must be determined on a case-by-case basis.
• Other parties, such as Facebook, do no include such data in their user download functionality.

And now I am looking how I could extract these administrative records.

[Ed_S]

Hmm, I thought that was the meaning of extended - it’s everything practically exportable.

[angus (Angus McLeod)]

@GuidoD

But that does not include the administrative records , as Angus has written above…

Yes, that’s right. Unfortunately, there’s not a straightforward answer to this question. This is why those records are not included, as explained above. Note, in particular

@angus

Whether administrative records intrude on the privacy of other parties, or other relevant concerns (i.e. R. 63.5 & A.15.4) must be determined on a case-by-case basis.

That said, to gather additional records containing ther user’s user id, you can use this approach.

1. Install the data explorer plugin

2. Create a new query (perhaps call it “Additional User Records (GDPR)”)

3. Do a search for “user_id” in the schema explorer on the right to see which database tables include a user_id in them. You’ll see that a number of them are already included (see list in OP + “user activity” as mentioned in my second post).

4. Determine the user_id of the user in question (you can find it at /u/username.json)

5. For each additional table you want to include, construct a query that extracts the rows where the user_id matches the relevant id. e.g.

   select * from [table_name] where user_id = [user_id]
   

I suggest you review each of these “additional” tables on their own merits, rather than just attempting to download every single record that contains the user’s id.

The records may contain other information, relevant to other users with counterveiling interests, or may be senstive in some other way. Unfortunately there’s no single answer to the question of “scope” here. You’ll need to make that call based on how you read your specific mixture of responsibiities. The GDPR is not the only relevant responsibility here. You shouldn’t just hand over every single record that contains a user’s id.

I’m actually a little unclear what’s driving the interest in these additional records? Is this something the user has asked for, i.e. beyond what’s already included? If they haven’t what’s motivating this? A different interpretation of your responsibilities under the GDPR than what I’ve laid out above? If so I’d be curious to learn more and the legal reasoning behind it (I may want to consider assimilating the reasoning into this plugin).

[GuidoD (Guido Drehsen)]

@angus

Is this something the user has asked for, i.e. beyond what’s already included?

yes but of course we are not williing to give him all these information. Especially if the records do have also data from other users. We just want to be prepared to have these additional information if really needed. We will most probably not provide these information to this user but we might have to give information to the authorities because we expect that the user will address it to the authorities.
Our new data protection officer also told us that we should at least not yet provide the administrative records.

[angus (Angus McLeod)]

I see.

If your data protection officer decides that additional records are needed, and has some tables in mind, I would be happy to provide a more specific sql query to help you out. For the reasons I mentioned, I don’t want to nominate specific additional tables to be provided as a general piece of advice outside of the context of a case.

But if you need something specific as this case progresses, I’d be happy to help you out pro bono, as that is in the spirit of this plugin, i.e. to make it easier for Discourse communities to navigate the GDPR. If that happens, and you have specific tables in mind, and you’re in need of assistance with the SQL query, PM me here on meta.

In short, I’m happy to provide some ad-hoc technical (non-legal) assistance to Discourse communities in response to specific cases under the GDPR, but I’m conscious of not setting general standards beyond the scope of what is reasonable for the majority of cases. If there is a legal argument of that sort that the scope of the plugin should be expanded, I’m open to it.

[GuidoD (Guido Drehsen)]

well our data protection officer told me that there is at least currently no need to extract additional administrative data. Thanks a lot for your help and if needed I would get back to you.

[TallTrees]

This plugin is great!

Handling GDPR subject access requests is a pain, a total time drain, and this helps cover all of that with much more confidence. Thank you.

Are there any plans to add more features? Particularly I’m struggling with data retention and minimisation principals. Specifically I’m interested in minimising ‘administrative records’ - whispers and posts in team areas which could contain notes on IP addresses and other personally identifying data that needs sifting and searching by hand. Five years on there’s too much to audit, and little value in the old messages so I want / need to permanently delete them. I’d actually like to have just a 6 month retention policy on such messages and whispers.

So I can select and delete stuff using rake, but it’s just marked deleted and still all there in the database

I’ve therefore been thinking about an ‘obliterator’ plug-in that would either change the raw and cooked text of deleted posts to something like ‘this message has been obliterated’, or (preferably) unpick and remove the posts entirely. Having never written ruby or a plug-in, I’m not at an ideal starting position, though could potentially just write some SQL to run against the db directly, then use rake to rebuild the search indexes afterwards.

@angus - I did wonder if in your legal considerations you had any thoughts on the data retention aspects of GDPR, and how you handle it?

[angus (Angus McLeod)]

Interesting!

Yes, I’m open to adding a feature for that. I’ll have to consider it in some more depth after doing a bit more research.

Could you please a detailed feature request (select “Legal Tools” at the plugin step) laying out all the relevant details of your use case and any other research you’ve collected, I’ll then follow up and engage after doing a bit of background.

https://thepavilion.io/w/feature-request

[Nick_Tomlinson]

questo plugin è ancora mantenuto?

Non riesco a cambiare l’impostazione per abilitare il plugin

[angus (Angus McLeod)]

Ciao Nick, ci proverò la settimana prossima.

[Nick_Tomlinson]

Lo apprezzo molto!

[kOS (KilianS)]

Ciao, mi sono imbattuto in questo e mi chiedo quanto di questo sia già incluso o pianificato di essere incluso nel core.

[pfaffman (Jay Pfaffman)]

Sembra che qualcosa si sia rotto prima di ieri

Non riesco ad approvare gli utenti e non riesco a caricare pagine come /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'

[RGJ (Richard - Communiteq)]

Sì, questo è rotto da parecchio tempo. La maggior parte delle funzionalità è ormai nel core.
Aggiungerò il tag broken.