[wp-trac] [WordPress Trac] #44176: Un-map Privacy Capabilities

WordPress Trac noreply at wordpress.org
Thu Dec 19 15:56:09 UTC 2019


#44176: Un-map Privacy Capabilities
------------------------------------------------+---------------------
 Reporter:  desrosj                             |       Owner:  (none)
     Type:  defect (bug)                        |      Status:  new
 Priority:  normal                              |   Milestone:  5.4
Component:  Privacy                             |     Version:  4.9.6
 Severity:  normal                              |  Resolution:
 Keywords:  2nd-opinion has-patch dev-feedback  |     Focuses:
------------------------------------------------+---------------------
Changes (by xkon):

 * keywords:  needs-patch 2nd-opinion => 2nd-opinion has-patch dev-feedback


Comment:

 Hey all,

 I wanted to take a different approach to this as I'm pretty sure that we
 had been discussing a "built-in" DPO since the start but as everything was
 new at that time we didn't move that forwards and we ended up "forcing"
 the privacy caps to Admins only basically.

 Let me explain what this patch does and where I'm facing some issues to
 see if we can figure out something either with or without the role ( it's
 easy this way to simply apply the patch and do a `wp role reset --all` so
 the DPO can be created to check it out ).

 First of all, it splits the caps into manage_privacy_options,
 export_others_personal_data & erase_others_personal_data ( I'm not even
 sure if we need all 3 to be honest as it doesn't make much sense to me to
 allow 1 and not the other but I just used what we have already in :) ).

 1] Changes the `erasure` procedures to not need the `delete_user` cap as
 these can be specifically applied to users now.

 2] Creates a new schema as `populate_roles_540()` that adds the new caps
 administrator role as well as create a new DPO role and gives that all the
 necessary caps.

 To break down the DPO role what it would need:

 {{{
 // These are the privacy-related caps so the role can have access to the
 Exporter/Eraser.

 $role->add_cap( 'export_others_personal_data' );
 $role->add_cap( 'erase_others_personal_data' );
 $role->add_cap( 'manage_privacy_options' );


 // These are the caps to allow access to Dashboard
 // (the lowest caps possible on this aspect).

 $role->add_cap( 'read' );
 $role->add_cap( 'level_0' );

 // Page caps are needed to edit/delete/create
 // (unfortunately the role must have full access
 // to pages to read drafts / from other users etc
 // but ok we can live with that I guess :) ).
 $role->add_cap( 'edit_pages' );
 $role->add_cap( 'edit_others_pages' );
 $role->add_cap( 'edit_published_pages' );
 $role->add_cap( 'publish_pages' );
 $role->add_cap( 'delete_pages' );
 $role->add_cap( 'delete_others_pages' );
 $role->add_cap( 'delete_published_pages' );
 $role->add_cap( 'delete_private_pages' );
 $role->add_cap( 'edit_private_pages' );
 $role->add_cap( 'read_private_pages' );
 }}}

 4] Adjust the menu. The 'Tools' is already opening for this role as-is,
 but I had to "adjust" the Settings so the Exporter/Eraser tools could be
 accessed. I simply added an `if` there to create a different Settings
 parent menu if a user has the manage_privacy_options cap but not the
 manage_options one. I'm not totally sure about this though but that's the
 only way that my brain allowed me to work with this since we can't pass
 arrays on the menus for caps.

 ---

 The caps after this are accessible from plugins like the "Member" that was
 mentioned here and they can be assigned to different roles also.

 I would love feedback on how to tackle the menu problem and if we really
 need 3 different caps for Privacy. Again it doesn't make any sense at all
 to me to split 3 and everything would be way easier if we just had
 `manage_privacy_options` only.

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


More information about the wp-trac mailing list