Login as Admin
Navigate to Site admin -> Users -> Privacy -> Privacy settings
Enable the " Contact the privacy officer " setting
Navigate to Site admin -> Users -> Privacy -> Data registry
Configure a basic purpose and category against the system
Navigate to Site admin -> Users -> Privacy -> Data requests
Create new requests for:
One user to have their data exported
A different user to be deleted
Confirm:
That the status for both requests was set to " Awaiting approval "
Log out
Log in as a regular user
From the User Menu, choose " Profile "
Click on the " Contact the privacy officer " link and leave a brief message
Confirm that your request was submitted
Click on " Data requests "
Confirm that you see your pending enquiry
Create a new request for export of your data and add a note
Confirm that you see your export is awaiting approval
Logout
Log in as a different user
From the User Menu, choose " Profile "
Click on " Data requests "
Create a new request for your data to be deleted
Confirm that you see your request is awaiting approval
Log out
Log in as admin/dpo again
Navigate to Site admin -> Users -> Privacy -> Data requests
Open the contact request and mark it as complete
Confirm it is marked as complete
Approve all of the other requests
Run Cron
php admin/cli/cron.php
Confirm that the cron finished without error
Refresh the requests page
Confirm that both download requests were marked as Download ready
Confirm that both delete requests were marked as Deleted

Description

We originally planned to allow for an interface to approve and reject individual contexts. This necessitated splitting the request into a Pre-processing stage, and a processing stage, with the pre-processing stage locating everywhere that the user holds data.

This interface never materialised, and now that we have a combination of per-purpose protection, and per-role deletion, this is arguably no longer required. Any rejection of a context for a specific user should be done via a per-role override to the context purpose instead.

As such, we should remove the preprocessing stage. This becomes especially important given MDL-62563, and MDL-62564, where we will see the creation of automated requests.

This pre-processing stage has a number of existing issues, namely it allows for data to become stale between addition and removal.

Removing this stage and jumping straight to the awaiting approval state, and then fetching the list of contexts immediately before they are handled reduces complexity, and the possibility for this stale state. This also alleviates the need for most (but not all) of MDL-62589.