WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 6 days ago

#44176 new defect (bug)

Un-map Privacy Capabilities

Reported by: desrosj Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords: needs-patch 2nd-opinion
Focuses: Cc:

Description

Three new capabilities were added in WordPress 4.9.6 to allow granular control over the new privacy features:

  • erase_others_personal_data
  • export_others_personal_data
  • manage_privacy_options

If a site activates a role management plugin (such as Members), the capability is not listed under the Administrator role (which receives these capabilities by default), and is not available to be assigned to other roles. Adding this role as a custom capability does nothing because the capabilities are mapped to manage_options and manage_network.

A site could create a custom role specifically for someone to manage privacy requests that should not have access to other manage_options related functionality.

Related: #44079, ticket:44055#comment:5.

Change History (15)

#1 @desrosj
8 months ago

  • Summary changed from Missing Privacy Capabilities to Un-map Privacy Capabilities

#2 @johnbillion
8 months ago

  • Keywords 2nd-opinion added

These are meta capabilities that map to a primitive capability in the map_meta_cap() function.

The same problem is true for the other meta capabilities that have been introduced recently, for example the term management capabilities introduced in 4.7: https://make.wordpress.org/core/2016/10/28/fine-grained-capabilities-for-taxonomy-terms-in-4-7/ . There's really no way around this other than an update to the role management plugin to add support for the newly added capabilities.

It's not really possible to add new primitive capabilities any more because there will always be custom user roles that don't get those caps and therefore can't perform an expected action.

cc @flixos90

#3 @flixos90
8 months ago

There's really no way around this other than an update to the role management plugin to add support for the newly added capabilities.

I fully agree with that statement. The only issue I see with the current core implementation of the new capabilities is that those are not meta capabilities. They are primitive capabilities that can't / shouldn't be part of the database.

Due to that, I'd recommend to grant them via user_has_cap, based on the same capabilities that they are currently mapped to in map_meta_cap. Such a filter can easily be unhooked if someone wants to add the capabilities in another way. With them being part of map_meta_cap() it's harder to tweak the behavior because they are hard-coded in the switch clause in the actual function.

What do you think @johnbillion? See https://core.trac.wordpress.org/ticket/41332#comment:3 for more thoughts on primitive capabilities in the database vs primitive capabilities via user_has_cap vs meta capabilities.

#4 follow-ups: @juliobox
8 months ago

Excuse me, I'm looking for the ticket that started this discussion. I'm explaining.

You're already talking about the admin capa that is not sharable, ok. But, since this is a page, why an editor can't just edit it like any other page, it's their job after all! At the opposite, admin should not add content to the front website, this is not their role, only administration stuff.

Example 1: Many clients are not administrators on their site because of you know what (meeeeess). So they are editor based role with some more capa if needed. So, they can't even edit their own privacy page. Me, as admin, as site maintener, as webmaster, I don't know what to add in this page for them, it's their job, not mine.

Example 2: In the company we have 1 IT perso and 3 editors, they are hired to fill content in the website. Blog, landing pages, privacy page, HO WAIT, they can't do that.

Do you see what I mean? So, I'm looking for the "why" of this decision, in a ticket, a discussion, somewhere.

Then this ticket could have sense here, but not now. See you soon.

This ticket was mentioned in Slack in #core-multisite by earnjam. View the logs.


8 months ago

This ticket was mentioned in Slack in #core by iandunn. View the logs.


8 months ago

#7 @desrosj
8 months ago

#44194 was marked as a duplicate.

#8 in reply to: ↑ 4 @lakenh
8 months ago

Replying to juliobox:

Excuse me, I'm looking for the ticket that started this discussion. I'm explaining.

You're already talking about the admin capa that is not sharable, ok. But, since this is a page, why an editor can't just edit it like any other page, it's their job after all! At the opposite, admin should not add content to the front website, this is not their role, only administration stuff.

Example 1: Many clients are not administrators on their site because of you know what (meeeeess). So they are editor based role with some more capa if needed. So, they can't even edit their own privacy page. Me, as admin, as site maintener, as webmaster, I don't know what to add in this page for them, it's their job, not mine.

Example 2: In the company we have 1 IT perso and 3 editors, they are hired to fill content in the website. Blog, landing pages, privacy page, HO WAIT, they can't do that.

Do you see what I mean? So, I'm looking for the "why" of this decision, in a ticket, a discussion, somewhere.

Then this ticket could have sense here, but not now. See you soon.

Here you go, pulled these up after a <5-minute search:

https://core.trac.wordpress.org/ticket/43935

https://core.trac.wordpress.org/ticket/44055

https://core.trac.wordpress.org/ticket/44079

#9 in reply to: ↑ 4 @Ov3rfly
8 months ago

Replying to juliobox:

Example 1: Many clients are not administrators on their site ..., I don't know what to add in this page for them, it's their job, not mine.

Example 2: In the company we have ... 3 editors, they are hired to fill content in ... privacy page, HO WAIT, they can't do that.

Exactly the same situation here. This needs to be changed without rolling out extra capabilities to editor roles of hundreds of sites. Otherwise most of our clients won't be able to use the new and shiny "privacy policy page" feature, see our +1 here: #44194

#10 @Ov3rfly
8 months ago

For interested readers, as long as editor role users can't edit the privacy policy page, instead of the core feature we are now using a simple custom solution for login and registration pages, which supports

  • multiple links,
  • the real post titles,
  • configurable order,
  • any post types

Find details and code in #44194

#11 @garrett-eclipse
5 months ago

#44810 was marked as a duplicate.

This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.


5 months ago

#13 @ianatkins
5 weeks ago

Agree that giving the DPO admin rights is a recipe for disaster. Am trying to enable the privacy tools for the editor role.

@flixos90 you mention it's an architectural issue. Have tried the filter you suggested ( code below ), this now gives an editor the 'tools' option in the menu that only redirects back to the dashboard and has no sub menus. Correct me if I'm missing something, or that's not the right filter.

I can only get it this to work by granting manage_options via the members plugin, which is less than ideal.

function editor_cap_filter( $caps, $cap, $args ) {
        
        // Bail out for users who can't publish posts:
        if ( !isset( $caps['publish_posts'] ) or !$caps['publish_posts'] )
                return $caps;

        // Add Privacy Capabilties
        $caps[] ='erase_others_personal_data';  
        $caps[] ='export_others_personal_data'; 
        $caps[] ='manage_privacy_options';      
        
        return $caps;

}

add_filter( 'user_has_cap', 'editor_cap_filter', 10, 3 );

#14 @swissspidy
5 weeks ago

  • Milestone changed from Awaiting Review to 5.1

It'd be great to get this fixed.

#15 @garrett-eclipse
6 days ago

  • Milestone changed from 5.1 to Future Release

I'm moving this ticket to 'Future Release' as it hasn't seen much attention. Once a patch has been worked on this can be re-milestoned.

Note: See TracTickets for help on using tickets.