[wp-trac] [WordPress Trac] #43546: Add to the privacy tools UX a means to export personal data by username or email address

[WordPress Trac]

#43546: Add to the privacy tools UX a means to export personal data by username or
email address
--------------------------------+-----------------------
 Reporter:  allendav            |       Owner:  allendav
     Type:  enhancement         |      Status:  assigned
 Priority:  normal              |   Milestone:  4.9.6
Component:  General             |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  gdpr needs-testing  |     Focuses:
--------------------------------+-----------------------

Comment (by iandunn):

 [attachment:43546.11.diff] has these changes:

 * First pass at a cron job instead of manually calling
 `wp_privacy_delete_old_export_files()` when generating a new file. Right
 now it's setup on the admin side, because
 `wp_schedule_delete_old_privacy_export_files()` is in `wp-
 admin/includes/file.php`, but I think it'll need to be moved to a front-
 end include file, because otherwise the job is even less likely to run as
 often as needed on small sites.
 * Switch from `rand()` to `wp_generate_password()`.
 * Fix the failing unit test. sanity check on fix for unit test - seems
 wiser to compare the urls, not hardcode/duplicate  the surrounding link
 markup in the test itself, but don't have a lot of context, so could be
 missing something
 * Add `wp_privacy_export_expiration` filter for determining the expiration
 lifetime. The email text previously had it hardcoded, but I switched to
 pulling from the filter instead, and updated the string to list the date
 it will expire on, rather than "3 day from now". I tried using
 `human_time_diff()` to preserve the original string, but it's not accurate
 enough in all cases, because it often rounds to the nearest
 week/month/etc). I think a date is probably less ambiguous, too, because
 there may be a delay between when the email is sent and when the user
 opens it. So it could say "3 days" because it was sent 2 days ago, but in
 reality the reader only has 1 day left to open it. I also added an
 explanation of ''why'' the file will be deleted, to avoid any confusion.
 * Adds `@group privacy` to the unit tests. If someone has time, it'd be
 good to make sure all the GDPR tests have this.
 * Removes the `@` from `unlink`, since suppressing error messages is
 general a bad practice. I'm guessing it was originally done to avoid them
 showing up in an AJAX response? That's no longer an issue since it's
 called via cron now.
 * Tell `list_files()` to exclude `index.html`, so it doesn't get deleted.
 * Miscellaneous cleanup.

 Some other feedback

 * `Download Personal Data` and `Email Data` function like buttons, and are
 visually formatted as buttons, but are setup as links. Would it be more
 semantic (and maybe accessible?) to use an actual `<button>`?
 * If we're going to add additional files to the `.zip` besides the
 `index.php`, then it might be nice to prefix a folder for all the files.
 That way, if someone downloads the file to `~/Downloads`, when they unzip
 the file, they don't get a ton of files extracted to `~/Downloads`, where
 they'd be mixed in with tons of other files, making them hard to find, and
 creating a mess. Instead, they'd be extracted to `~/Downloads/wp-personal-
 data-file-iandunn-at-example-org-ZG56zBVyy0jynV8W61aVsZ5vKfUmLk1o/`.
 * Similarly, would the HTML file be better named something like `wp-
 personal-data-file-iandunn-at-example-org-
 ZG56zBVyy0jynV8W61aVsZ5vKfUmLk1o.html` instead of `index.html`, which
 doesn't describe the contents at all, and may conflict with other export
 files?
 * If no data is available, it'd be nice to display a message in
 `index.html` indicating that; otherwise the user might be confused why
 they're not seeing anything. Or, maybe short circuit the entire process,
 and just send them an email saying that there isn't any data, instead of
 giving them a link to click?
 * I'm not sure why the email says, "This email has been sent to
 {address}". Isn't that obvious from the `To` header?

 Replying to [comment:25 aaroncampbell]:
 > It would also be nice to have a manual delete option so an admin could
 choose to delete the file once it has been downloaded or emailed.

 It looks like this exists in the bulk edit row, but it'd be nice to have
 `remove` link next to the `download` link, too, to make it more
 discoverable and convenient.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43546#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform