[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