[RFC] Article 17 right to be forgotten implementation.

[daramousk]

Hello,

We are currently designing an implementation of this article in the context of Odoo and with attempts to be as abstract and extensible as possible and we would like your input and possibly organize our attempts on this so that we do not have a lot of people working in parallel.

Here is what we have in mind for now:

Workflow: 1) Partner invokes article, requests deletion of their data 2) Odoo user navigates to Customers -> finds customer -> More -> Delete 3) We find all the models that refer to res.partner and specifically to our customer and delete them. There are exceptions of course that have to do about legal documents that must remain in our system. There should be a settings page that we can set these models. In these models the partner_id or any other field that refers to our partner will be changed with a placeholder res.partner that this module will add. Also, in the case of any reports existing on these models, before the placeholder is set in place the reports will be generated and attached to the record 4) In any case that further clean up is required, possible extensions of this module can override res.partner.unlink()

Please, let us know what you think below. Thanks.

[pedrobaeza]

You can't delete the partner IMO. You should obfuscate/remove the possible personal information, but not to remove entirely from the system, and it's not going to even be possible due to not null restrictions and so on.

[hbrunn]

What I have in mind to happen after a user presses GDPR cleanup or however we call it:

• run res.partner#_pre_gdpr_cleanup, that for example loops through the partner's invoices, generates PDFs from them (at least in NL, you have to keep invoices for N years, always). With a little bit of trickery, modules can implement this without having to depend on the deletion module, and for standard things like invoices we can detect if the appropriate module is installed.
• loop through the results of res.partner#_get_gdpr_relevant_fields and overwrite them with 0, / or null for non-required fields, and possibly replace some linked records (think res.partner.bank) by generic 'I am the deleted record record' (because we can't null an IBAN for example). This could be more consultant-friendly by not having the definitions for this in code but some configuration where you can add fields that should be changed, and another column for what to do with them (null, overwrite with X, replace by record $record)
• make the partner inactive

[hbrunn]

...just discussing with @lfreeke another idea popped up: Replace my step 2 and 3 with depending on base_partner_merge and merge the partner with a special 'deleted partner' that the module brings along. Then the merging takes care of all the grunt work, and we only have to take care about linked records like messages, bank accounts etc.

This might however screw with some statistics as all 'deleted' partners collapse to one then.

[daramousk]

Maybe deleting the partner is not a good idea then, not only because it is not possible but mostly it will possibly mess up the installation in non predictable ways as you both mention.

So, would the obfuscation of personal information be enough?

-> GDPR Cleanup requested -> _pre_gdpr_cleanup (do what you have to do, keep records/files that must be kept. By default it does nothing and contains an overwrite me docstring. Different localization modules can override this to keep what they want. ie data-protection-nl with keep invoices for 7 years, data-protection-de will do something different etc..) ->_get_gdpr_relevant_fields and override them somehow (basically the second point on your @hbrunn first comment. -> make the partner inactive(your third point)

Merging partners will be avoided at this case because we will cause trouble down the road if we merge stuff.

@pedrobaeza @hbrunn Sounds good?

[pedrobaeza]

Yeah, I don't think merging partners is a good idea. Better to change relevant fields by a text like *** GDPR removed ***.

[hbrunn]

sounds good. Just don't delegate too much functionality to the localizations, I assume for example that pretty much every legislation in the EU has some rule about keeping invoices, so the code for invoices should be in this module I think, with some parameters so that localizations only have to fiddle with those.

I think you also should prepare the possibility to define _pre_gdpr_cleanup_$module on res.partner, which is then called in reverse module dependency order. This way, modules can support gdpr stuff in cases the installation needs it, but don't pull the gdpr modules for installations that don't.

[lfreeke]

Fields to be overwrite by GDPR removed :

• Name
• Street 1
• Street 2
• Zip
• City
• State
• Phone nr
• Mobile
• Fax
• Email address
• Website
• Bank account nr. (we should be careful here with there is sql constraints on this field)

I think this should be fields that should be overwritten. Note that I didn't put country in the list, because that could be useful for statistics and not identifiable for a partner.

[pedrobaeza]

About the country subject, why not applying the same criteria for state or city? Where is the limit on the personal information?

[lfreeke]

@pedrobaeza Yes, I think so too. In principle City and State couldn't be identifiable attribute.