Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#43922 closed defect (bug) (fixed)

Data removal/erasure requests don't get marked as "Completed" after erasure happens

Reported by: coreymckrill's profile coreymckrill Owned by: iandunn's profile iandunn
Milestone: 4.9.6 Priority: normal
Severity: normal Version:
Component: Privacy Keywords: gdpr fixed-major
Focuses: Cc:

Description

Either forcing removal with the Force Remove Personal Data row action, or clicking the Remove Personal Data button once a request has been confirmed, the request is never transitioned to a "Completed" status.

Attachments (2)

43922.diff (3.0 KB) - added by coreymckrill 7 years ago.
Process confirmation of completed data erasure. Note that this patch depends on the patch in #43913 to work correctly.
43922.2.diff (3.0 KB) - added by coreymckrill 7 years ago.
Refresh

Download all attachments as: .zip

Change History (18)

#1 @allendav
7 years ago

Possibly same root cause as #43913

#2 @coreymckrill
7 years ago

It appears that the problem here is that _wp_privacy_completed_request() never gets fired anywhere during the data erasure process. I'm not sure where the best place for it would be, though.

Maybe add a function that hooks into the wp_privacy_personal_data_erasure_page filter and fires it from there?

Thoughts, @allendav ?

#3 follow-up: @allendav
7 years ago

Hey @coreymckrill - good catch - yup - unlike the exporter - which calls this from file.php, there is no such call for the erasers.

I recommend we add a call to it near the end of wp_ajax_wp_privacy_erase_personal_data but we'll need to wrap it in a condition to make sure we are on the last eraser and that that eraser has returned done = true

Exporters do something like this in wp_privacy_process_personal_data_export_page - where you can see that they don't call _wp_privacy_completed_request except for the last time through, i.e.:

<?php
        // If we are not yet on the last page of the last exporter, return now.
        $exporters = apply_filters( 'wp_privacy_personal_data_exporters', array() );
        $is_last_exporter = $exporter_index === count( $exporters );
        $exporter_done = $response['done'];
        if ( ! $is_last_exporter || ! $exporter_done ) {
                return $response;
        }

If you can prep a patch awesome - if you would like me to prep a patch, just let me know.

#4 in reply to: ↑ 3 @coreymckrill
7 years ago

Replying to allendav:

If you can prep a patch awesome - if you would like me to prep a patch, just let me know.

I'll work on it. You've already got your hands full :)

This ticket was mentioned in Slack in #gdpr-compliance by coreymckrill. View the logs.


7 years ago

#6 @desrosj
7 years ago

  • Milestone changed from Awaiting Review to 4.9.6

@coreymckrill
7 years ago

Process confirmation of completed data erasure. Note that this patch depends on the patch in #43913 to work correctly.

#7 @coreymckrill
7 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

In 43922.diff:

  • Add a function similar to wp_privacy_process_personal_data_export_page for processing the Ajax responses during data erasure.

I added a separate function rather than adding it into wp_ajax_wp_privacy_erase_personal_data because:

  • It's more in sync with how data export works.
  • It gives us more flexibility if more steps need to be added to the erasure process in the future.

This ticket was mentioned in Slack in #gdpr-compliance by coreymckrill. View the logs.


7 years ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


7 years ago

#10 @allendav
7 years ago

  • Keywords needs-refresh added

@coreymckrill - tests well - thank you - patch doesn't apply without intervention - needs refresh then i think it is good to go

@coreymckrill
7 years ago

Refresh

#11 @coreymckrill
7 years ago

Thanks @allendav. Should apply cleanly now.

#12 @allendav
7 years ago

Applies cleanly now - thank you!

#13 @iandunn
7 years ago

  • Owner set to iandunn
  • Resolution set to fixed
  • Status changed from new to closed

In 43185:

Privacy: Mark erasure requests as completed after processing.

r42986 introduced the beginnings of an Ajax handler for processing requests to erase personal data. At the time, a method for marking requests as completed was planned, but had not yet been created. This commit introduces that mechanism, bringing the erasure process closer to completion.

Props coreymckrill, allendav.
Fixes #43922.

#14 @iandunn
7 years ago

  • Keywords fixed-major added; has-patch needs-testing needs-refresh removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for 4.9 backport.

#15 @SergeyBiryukov
7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 43188:

Privacy: Mark erasure requests as completed after processing.

r42986 introduced the beginnings of an Ajax handler for processing requests to erase personal data. At the time, a method for marking requests as completed was planned, but had not yet been created. This commit introduces that mechanism, bringing the erasure process closer to completion.

Props coreymckrill, allendav.
Merges [43185] to the 4.9 branch.
Fixes #43922.

#16 @desrosj
7 years ago

  • Component changed from General to Privacy

Moving to the new Privacy component.

Note: See TracTickets for help on using tickets.