Steps to reproduce:
Scenario "A"
1. install drupal core: 8.5.4 standard profile
2. set up private file system
3. enable gdpr_tasks (with dependencies)
4. create an authenticated user
5. add permissions for Authenticated role:
Access GDPR Data Summary
Create GDPR tasks
View GDPR tasks
6. as an authenticated user create a removal request
7. as admin (user 1) try to execute the task. Note that no field is configured as "This is a GDPR field".
As admin (user 1) when I push the button to execute a removal task ("remove and anonymize data") it leads to an error.
php error Error: Call to a member function getField() on null in
Drupal\gdpr_tasks\Anonymizer->getFieldsToProcess() (line 320 of
web/modules/contrib/gdpr/
modul
Scenario "B"
Same as scenario "A", with the following difference:
When the Email field in the User is configured to be Anonymized with Email anonymizer the email gets anonymized, but there is an error message "An export directory has not been set. Please set this under Configuration -> GDPR -> Right to be Forgotten". I wasn't able to find such config page. The task remains in the "Requested tasks".
Scenatio "C"
When I first (after steps 1-5 of scenario "A") create a request data removal request and as admin I execute it,
and when the Email field in the User is configured to be Anonymized with Email anonymizer
then as admin (user 1) try to execute the removal task it results with the same error as scenario "A".
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2977818-3.patch | 2.79 KB | yanniboi |
Comments
Comment #2
yanniboi commentedThis sounds to me as though it is trying to process removal on an entity that has not been configured through the UI.
We should probably wrap getFieldsToProcess() in a try/catch and mark the entity as failed so that we can get the error messages at the end of the removal request.
Comment #3
yanniboi commentedComment #4
yanniboi commentedComment #5
keshavv commentedI have tested #3 patch working perfectly.
Comment #6
james.williamsThe current patch will stop the entity being saved at all, even if its due to some rogue config that contains a single missing field (perhaps one that was deleted?). I don't think that's right. We should certainly log/report the error, but can't we still continue with saving other changes to the entity?
Comment #7
yanniboi commentedWe either save all entities or none of them.
When any issue happens during a removal we want to output the issue to the user and make them correct it. A removal should only happen once and should remove/anonymise completely. We cannot allow any partial removals because it may make it impossible to fix in the future.
So with any error we should output error messages that are helpful enough for the site user to go and fix the configuration.
Comment #8
james.williams> We cannot allow any partial removals because it may make it impossible to fix in the future.
I suppose that's a fair point. Can we identify exactly what the issue was in this case, and handle it specifically though? For example, could it happen if no fields have actually been configured for users / the bundle in question yet? Because, it looks to me like its the loading of the GdprFieldConfigEntity that has failed. If that's the case, we shouldn't even enter the loop over fields, and we shouldn't even allow running the task?
Comment #9
pedrop commentedIssue description extended with scenarios. I hope this helps to fix it.
Comment #11
mhavelant commented@pedrop
I tested all 3 scenarios, the applied fixes should have fixed it.
Comment #12
mhavelant commentedComment #13
pedrop commentedThanks, I confirm that now with the latest dev this problem is gone, great!
Comment #14
pedrop commentedComment #16
baluertlChanges committed, is there any work left as todo on this issue, maybe?
Comment #17
baluertlMoving issue state manually from Fixed 🠂 to Closed (fixed) in the hope that issue queue gets cleaner a bit.