[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 azaozz):

 Replying to [comment:37 mikejolley]:
 > Maybe there is some confusion about how this was intended to work.

 Yeah, I agree. Seems we are still talking about different things. The
 title of this ticket is "Add a method for confirmation of requests for
 deleting or anonymizing of personal data" and that is what we need to do.
 Anything else is out of scope.

 Three of the four DOTO items from seven weeks ago are still not done:
 1. Prevent "flood" of requests. If a request is made and it hasn't
 expired, perhaps limit how many new requests can be made for the same
 email.
 2. Perhaps add garbage collection function to delete expired requests.
 3. Consider how this can be used through the REST API and add an endpoint.

 In addition this stores random data in the options table which is a bad
 thing to do. Yep, it's true I committed the first patch that adds this,
 but the reason was to not hold back development of the UI and other
 functionality that depended on this, not because it is the proper way to
 do things.

 > - I may want to add a request manually without email confirmation.

 I'm not sure what that means. Are you talking about some sort of a
 messaging system between users inside of WP?

 > **If there are duplicates, then the requests table logic needs an
 update...**

 No. See the TODO list above. Duplicates have to be detected and discarded
 as soon as a new request is made. That has nothing to do with the logging.

 > 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

 This currently is out of scope. I'd argue that it would be a very nice
 feature to have logging for all of the above actions (security/user
 activity log?). Not sure why we shouldn't log them. However we simply
 don't have the time to implement this now. Opened #43841 as a follow-up.

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

 Uh, I'm still thinking we misunderstand each other :(

 My strongest concern is that this feature uses the options table
 inappropriately and stores the requests inefficiently (in different places
 and with no way to fetch them from the db when needed). The main reason we
 moved to using CPTs was to not store the requests in the options and
 user_meta tables.

 My second concern is that it uses multiple CPTs. It seems inefficient/not
 a good design to use more than one CPT, and this hinders any possibility
 to extend it in the future.

 > ...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.

 I'm not sure what you mean here too. A db query is pretty much the same on
 any table field as long as it has an index. It makes no difference if we
 are going to select posts by id, post_name, post_type, GUID, etc.

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