[wp-trac] [WordPress Trac] #43738: Make the personal data Export/Delete functionality available in network-wide for super admins

[WordPress Trac]

#43738: Make the personal data Export/Delete functionality available in network-
wide for super admins
-------------------------------------------------+-------------------------
 Reporter:  TZ Media                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  privacy-roadmap has-patch 2nd-       |     Focuses:  multisite
  opinion                                        |
-------------------------------------------------+-------------------------

Comment (by pbiron):

 Replying to [comment:54 SirLouen]:
 > Yes now it applies, but it's barely the bare bones for the whole thing,
 right?

 Correct, as I commented when I posted the original patch: "It does NOT
 actually do network-level exports/erasures."  It just:

 1. adds the network-level UI for exports/erasures
 2. sets up the request posts and WP_User_Requests objects so that they can
 distinguish between requests submitted at the network- or site-level

 The "Invalid request status" message you got is a bug in my refreshed
 patch, sorry...I'll fix that tomorrow.

 > At first glance I anticipated that it could required a lot more (and a
 lot to review, generally this kind of patches with a ton of code, take
 ages to be reviewed). But now that I'm reviewing, I don't think that is
 going to be enough big to be a feature plugin
 >
 > I wonder how this could be dealt in order to avoid doing the whole thing
 and being left there, falling into oblivion. I will comment next wednesday
 in `dev-chat` and report back to see how we should handle future upgrades
 and testing.

 There are **a lot** of high-level decisions that need to be made before
 the actual export/erase can be done...because not all networks are equal.

 In some networks, each sub-site is completely independent of all others
 (e.g., an agency setups up a network to host each of their client sites,
 and none of the sub-sites has **any** relationship to one another).  In
 such a network it may not even make sense to allow network-level
 export/erase.

 In others, each sub-site is like a "division/department" of a single
 company's site (e.g., the main site is the corp headquarters, sub-site 1
 is Department X, sub-site 2 is Department Y, etc).  In such a network, the
 corporate DPO could manage network-level requests and department DPOs
 could manage site-level requests.

 And there are other "kinds" of networks with a myriad of different
 relationships between sites within the network (including sites 1-10
 having one relationship to one another, sites 11-20 having a different
 relationship to one another and **no** relationship to sites 1-10, etc).

 Core is **rightly** agnostic to those different "kinds" of networks.  What
 we need to figure out is how we can implement things so that site owners
 can have control over how network-level requests are managed.  In typical
 core fashion, we probably do **not** want a settings UI; rather we
 probably want some well designed filters (and maybe actions) that would
 allow plugins to be written that managed the myriad of network "kinds" and
 relationships, etc...not to mention appropriate defaults for such filters!

 From my perspective, things petered out 5 years ago trying to get input on
 the various ways real-world networks are set up (with the full array of
 relationships between sub-sites that may exist in the wild) so that we can
 sure that what ever hooks we define would allow plugins to handle the
 variety of networks that exist.

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