The GDPR enforce the right to erasure. To help companies to be GDPR compliant, we could provide a generic tool for this.
We could consider that personal data can be defined as a set of data that can be reach via any relation from a party, for example: addresses, contact mechanisms, identifiers, bank accounts etc.
Proposal
As Tryton is using a relational database to store data, there is no duplication of those personal data. But this means also that they can not be deleted without having a cascade effect or break that database integrity.
So the proposal is to simply nullify or hash the existing data so they can no more identify the person.
The solution should be extensible to allow each modules to define the fields that must be erased and how to erase it.
Implementation
We can use the same design as for Party duplication.
The party module define a generic wizard to erase the personal data of a selected party.
The wizard must ensure that the party can be erased by raising a warning if some condition are meet, for example: some parties can not be erased: with open sales, purchases or invoice or with dunning etc. This check must be filled by each modules.
The fields to be erased will be defined as a path from the party record. For example to erase the street field of the addresses: addresses/street, or to erase the bank accounts: bank_accounts/numbers/number.
For each field, the method to erase will be passed. By default there will be: None to nullify and md5 to hash with md5.
The wizard must perform the operations also on the parties that the selected party replace (included the condition) and on the historized row. The operations must be performed with SQL queries to avoid the creation of history record and skip any ORM constraint.
A special keyword will be used to remove the attachment links. Ex: :attachments or contact_mechanisms:attachments
Indeed standard SQL does not have a md5 method so we can not really use it in Tryton. But indeed we do not really need to hash the existing content, we can just use a random string generated.
This syntax does not allow to search for the row to erase because we need to construct the reverse clause for searching the ids of the Model to erase. When there is a Many2Many, we can not be sure to have and find the right reverse Many2Many.
So instead, the fields and records should be defined using a domain from their Model.
While it is strictly important to respect the GDPR, the implementation should also take care not to delete data, that must be preserved by the company for some time. E.g. in Germany the obligation to preserve records of business documents (sales, invoices etc.) is 6 years beginning from the end of the year of the document creation. I assume other EU countries will have comparable terms. So the planned wizard should not only refuse to delete business related data for open processes (invoices, dunnings), but also for processes undue with respect to record retention.
Commercial letters, as limited by section 257 (2) of the HGB, are only documents relating to a commercial transaction. Business transactions are legal acts or legal transactions of a merchant belonging to the business of his trade (§ 343). It follows that commercial letters can only be sent by merchants within the meaning of the HGB; Letters from private individuals with business content are called business letters. Since also a so-called one-sided trading business (§ 345 HGB) belongs to the commercial transactions, also the correspondence with business contents to or from private persons is to be regarded as commercial letter. Any correspondence that serves the initiation (such as the response to an offer), execution (such as a delivery) or cancellation (such as cancellation) of a commercial transaction, is in this sense as a commercial letter.
So do we have copies of opportunities, sales, delivery notes…?
If it is possible to erase data that could be required by the company for legal purposes, this wizard is a dangerous add-on at least for Germany. Please make it a separate module with the adequate warnings in this case.
The wizard in the current conception eases a lot to perform broad changes to various documents with legal relevance without the slightest knowledge of the user what will be the result in total (i.e. that a variety of legal documents could be touched).
Indeed you reveal a profound weakness of the party model being the required reference model on all sorts of legal documents, but having no default access group, thus allowing per default the manipulation of party data by any logged in user. Basically the unhindered access to the party model undermines the permission model of all sorts of sale, purchase, etc. documents. Any logged in user has the power to change very sensitive data of these documents without being part of the relative groups.
With tools like this wizard this can lead to catastrophic results. The very minimal requirement at least will be to create a separate group with permissions to use this wizard.
If so then this wizard must be secured against potential misuse. In the current conception it will be a available to simply each logged in user.
Indeed there is a group, sorry for not checking thouroughly enough. It would indeed be better to have a separate group different from party administration. You may want to empower a subset of users to perform the erasing of parties, but not having access to the configuration of company, emplyees, etc. …
I see that you are not interested in a sustained planing of the application, so I will stop here.
You can have look at the current demo 4.6. All sales are currently belongig to Angela Martin. It was possible to do that as the user with minimalistic access permissions. If it is not a problem for you it could be a problem for a company using Tryton.