[wp-trac] [WordPress Trac] #43443: Add a method for confirmation of requests for deleting or anonymizing of personal data

[WordPress Trac]

#43443: Add a method for confirmation of requests for deleting or anonymizing of
personal data
--------------------------------------------+-------------------------
 Reporter:  azaozz                          |       Owner:  mikejolley
     Type:  enhancement                     |      Status:  assigned
 Priority:  normal                          |   Milestone:  4.9.6
Component:  General                         |     Version:
 Severity:  normal                          |  Resolution:
 Keywords:  gdpr needs-testing needs-patch  |     Focuses:
--------------------------------------------+-------------------------

Comment (by mikejolley):

 Replying to [comment:32 azaozz]:

 > Another big disadvantage is that the hash, time, email are stored in a
 CSV which makes it impossible to look them up separately. If I remember
 right that was one of the main reasons a new DB table was so attractive.
 Given that such table will stay mostly empty on the great majority of
 sites, a CPT is the next best thing.

 Maybe there is some confusion about how this was intended to work.

 There are 2 completely separate parts here; let's call them:

 a) the request logging UI
 b) the verify action API

 The request logging UI (what you see/screenshot) lists requests. Requests
 are created during certain events. For example,

 - I may want to add a request manually without email confirmation.
 - I may want to add a request and get the user to confirm the action.

 **If there are duplicates, then the requests table logic needs an update,
 simply to check if a request already exists for the email address.**

 Actions can be verified via the other part: verify action API. This
 generates an action email, stores a hash, and gets confirmation from the
 user.

 Why is this separate? For a number of reasons:

 1. It can be used by things which don't need a logging table, or are
 completely unrelated to the request logging UI. Possible future examples:
    a) Lost password notifications
    b) Account update requests from WooCommerce (thinking ahead)
    c) Changing your email address
    d) Deleting your account

 By combining the request logging and this, you'll be restricting the above
 and it won't be as reusable.

 2. A request in the request logging UI can trigger multiple emails. E.g.
 'resend' will keep the same request ID and trigger a new email, with a new
 hash, via the verify action API

 3. When an action is confirmed, a generic action files. Anything can use
 this - request logging uses it to update the request but there are other
 use cases, again, outside of the request logging which could perform an
 action once confirmed.

 4. It doesn't matter that the verify action API stores it's hash and other
 supporting information as a CSV; it's not exposed via UI anywhere and
 isn't designed to be listed. It's just data that gets stored and sent via
 the actions once the request is confirmed.

 I feel they should remain separate. The duplication issue should be fixed
 but can be fixed without merging them into one thing.

 > Hm, don't think so. `wp_count_posts()` uses a simple db query to count.
 We actually can do better as it has some specific stuff for posts and
 pages that is not needed. Making another similar function which is adapted
 to our needs would be the right thing in any case.

 Just trying to KISS :) That functionality exists so piggybacking it where
 possible.


 > CPTs are the next best thing to a custom table. They can store a lot of
 information quite efficiently. Not using them to store the simple data
 needed for implementing email verification doesn't seem right. In
 addition, having two almost identical custom post types doesn't seem best.

 It's just for convenience. Seemed cheaper to query by post_type rather
 than name, meta, or any other abuse of the API. I still prefer the way it
 is.

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