Add ability to remove/anonymise user data

[JeremySkinner]

Continues the work that @yanniboi began in #2

This PR implements the "Remove" task that will go through and remove/anonymize fields. When editing a field definition, and "Right to be forgotten" is set to "Anonymise", then a new Sanitizer dropdown appears. This uses the same sanitizer plugins available from the original gdpr_dump module.

For non-editable fields (such as base fields on User), these settings can be attached for now using hook_entity_base_field_info_alter:

gdpr/modules/gdpr_tasks/gdpr_tasks.module

Lines 203 to 218 in 8a77cad

	function gdpr_tasks_entity_base_field_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type) {
	if ($entity_type->id() == 'user') {
	$fields['mail']['third_party_settings']['gdpr_fields']['gdpr_fields_enabled'] = TRUE;
	$fields['mail']['third_party_settings']['gdpr_fields']['gdpr_fields_rta'] = 'inc';
	$fields['mail']['third_party_settings']['gdpr_fields']['gdpr_fields_rtf'] = 'anonymise';
	$fields['mail']['third_party_settings']['gdpr_fields']['gdpr_fields_sanitizer'] = 'gdpr_email_sanitizer';
	$fields['name']['third_party_settings']['gdpr_fields']['gdpr_fields_enabled'] = TRUE;
	$fields['name']['third_party_settings']['gdpr_fields']['gdpr_fields_rta'] = 'inc';
	$fields['name']['third_party_settings']['gdpr_fields']['gdpr_fields_rtf'] = 'anonymise';
	$fields['name']['third_party_settings']['gdpr_fields']['gdpr_fields_sanitizer'] = 'gdpr_random_text_sanitizer';
	$fields['roles']['third_party_settings']['gdpr_fields']['gdpr_fields_enabled'] = TRUE;
	$fields['roles']['third_party_settings']['gdpr_fields']['gdpr_fields_rta'] = 'no';
	$fields['roles']['third_party_settings']['gdpr_fields']['gdpr_fields_rtf'] = 'remove';
	}

(Aside: We should be consistent with use of UK or US English for anonymise/anonymize, sanitise/sanitize etc)

When viewing the task, fields are listed with their corresponding action:

Once run, the "Processed by" field will be populated and a log will be created indicating which fields were affected and which sanitizer was used on them (this data should be backed up separately from the database backup and used as the basis of re-playing remove requests after a database restore). This will need to be tidied up at some point and probably moved to a separate tab.

If a field is set to anonymise, but no sanitizer is defined then it'll attempt to find the default for the datatype. At the moment, TextSanitizer is used for string fields and DateSanitizer is used for datetime fields. Others can be added by implementing the gdpr_type_sanitizers_alter hook:

gdpr/modules/gdpr_tasks/src/Anonymizer.php

Lines 184 to 191 in 4a27249

	// No sanitizer defined directly on the field. Instead try and get one for the datatype.
	$sanitizers = [
	'string' => 'gdpr_text_sanitizer',
	'datetime' => 'gdpr_date_sanitizer',
	];
	$this->moduleHandler->alter('gdpr_type_sanitizers', $sanitizers);
	$sanitizer = $sanitizers[$type];

A few things to note:

• I changed the interface declaration for GdprSanitizerInterface::sanitize to also receive an instance of the field which can be used for metadata purposes (eg calculating max length of the field).
• The IDs for the sanitizers had a typo (gpdr_* instead of gdpr_*), which I've fixed but is technically a breaking change.
• Introduced RandomTextSanitizer as an alternative to TextSanitizer and UsernameSanitizer. This generates a random string of a specified length prefixed by anon_. This is useful for sanitizing usernames as it shows it's been anonymized at a glance (while the original UsernameSanitizer generates usernames that don't 'look' like they've been sanitized).

[andrewbelcher]

GDPR is a European thing, so I would be inclined to break convention and go with UK English!

Description and screenshot all look great to me, let me know if you need a code review from me and I can try and get to that tomorrow.

[JeremySkinner]

@andrewbelcher yes please, that'd be great. I've assigned Yan too so he can take a look.

[yanniboi]

You dont need to explicitly set $max_length to NULL as you are checking for isset later anyway. Just remove the else.

[JeremySkinner]

Thanks - that's my C# background coming through!

[JeremySkinner]

Done.

[yanniboi]

For this you can use \Drupal\Component\Utility\Random::string() or \Drupal\Component\Utility\Random::name() for alpha numeric strings.

[JeremySkinner]

Done.

[yanniboi]

Cool, can you stick a @todo in here to remove the gdpr_task specific continue once we have solved the concept of 'ignore/excluded' relationships and entity types.

[JeremySkinner]

Done.

[yanniboi]

Can we document the class properties? At least lets stick in the classes so that IDE's can tell what it is we are working with.

[yanniboi]

Similarly the rest of the Anonymizer methods. Can we add @param and @doc definitions to the docblocks?

[JeremySkinner]

@yanniboi Yes, I can add those. What's the convention for where to apply doc blocks usually? I assumed it was for public/protected members, but not private.

Regarding the IDE, it can already tell without the docblocks on the fields as it picks it up form the type hints on the constructor parameters used to initialize the fields.

[andrewbelcher]

@JeremySkinner the convention in Drupal is to document everything. If nothing else, it makes it easier for other developers in the team to read and understand what's going on.

Also, generally I would use protected rather than private unless there is a specific reason why we'd need this to be the final implementation/use of it. Generally the convention is to assume that people could extend these classes if they required unless there are specific reasons not to (e.g. security).

[JeremySkinner]

@yanniboi @andrewbelcher I've added the export on completion functionality.