WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 4 weeks ago

#44176 new defect (bug)

Un-map Privacy Capabilities

Reported by: desrosj Owned by:
Milestone: Awaiting Review 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 (10)

#1 @desrosj
4 weeks ago

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

#2 @johnbillion
4 weeks 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
4 weeks 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
4 weeks 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.


4 weeks ago

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


4 weeks ago

#7 @desrosj
4 weeks ago

#44194 was marked as a duplicate.

#8 in reply to: ↑ 4 @lakenh
4 weeks 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
4 weeks 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
4 weeks 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

Note: See TracTickets for help on using tickets.