Require `manage_privacy_options` capability to edit the privacy policy page

[iandunn]

#44055 identified the problem that Editors are shown a link to the privacy guide, but can't actually view it. The solution there, in r43248, was to hide the link if users don't have the manage_privacy_options capability.

It doesn't seem like people without that capability should be able to edit the privacy page in the first place, though. Preventing them from editing it would solve the issue in #44055, and also any other issues stemming from the fact that editors could edit the page. An example of that kind of issue would be an editor who isn't trained in privacy law or organizational policies making edits that don't reflect the organization's desires.

Also, if someone is editing the page, then they should probably be able to read the guide as well, because the guide informs what edits should be made.

Previous discussion:

• ticket:44055#comment:5
• ​https://wordpress.slack.com/archives/C02RQBWTW/p1526315451000694
• ​https://wordpress.slack.com/archives/C02RQBWTW/p1526319469000326

[iandunn]

44079.diff​ is a first pass. Does anyone have feedback on it?

[dlh]

There are currently exceptions for page_for_posts and page_on_front in map_meta_cap() itself: ​https://github.com/WordPress/wordpress-develop/blob/e72d50370273c2741329e1a102ec90b35cf1b492/src/wp-includes/capabilities.php#L76.

I'm curious whether exceptions for wp_page_for_privacy_policy could or should go in map_meta_cap() as well?

[iandunn]

Ah, great catch, thanks!

44079.2.diff​ removes the filter callback and makes the modifications directly in map_meta_cap().

[dlh]

After testing further, I'm not sure that using either map_meta_cap() itself or the map_meta_cap filter will work for this purpose.

If I'm reading correctly, because manage_privacy_options is a new meta capability, it needs to be mapped for it to be granted to anyone (by default).

Appending manage_privacy_options to the array of required $caps doesn't allow that mapping to occur — the case 'manage_privacy_options': statement in map_meta_cap() is never reached.

44079.3.diff​ attempts to allow manage_privacy_options to be mapped with another call to map_meta_cap(), although it's not nearly as straightforward an approach.

[desrosj]

44079.2.diff​ did not work for me in my testing. As a user with the manage_privacy_options capability, I was unable to edit the selected privacy policy page.

44079.3.diff​ works for me as expected.

[iandunn]

Restore notice cap check, clarify comment

[iandunn]

Ah, you're right. 44079.2.diff​ was only working in my tests b/c I was in Multisite, and has_cap() always returns true as long as $caps doesn't contain do_not_allow.

44079.4.diff​ restores the capability check for the notice (​per Slack discussion), and iterates on the comment to make it a bit more clear.

This tested well for me in Multisite and single-site, but I'd like another committer's review before committing to trunk, to make sure we're not missing anything.

[azaozz]

44079.4.diff seems to work well here.

[SergeyBiryukov]

44079.4.diff​ looks good to me.

[iandunn]

In 43286:

Privacy: Require manage_privacy_options to edit policy page.

A user is required to have the manage_privacy_options capability in order to determine which page is set as the privacy policy (the wp_page_for_privacy_policy). Given that, it doesn't make sense to allow users without that capability to edit or delete the page.

A similar situation exists with the page_for_posts and page_on_front options, but Editors are allowed to edit those pages. The reason that this situation is different is because it is more likely that an administrator will want to restrict modifications to the privacy policy, than it is that they will want to allow modifications. Modifications to the policy often require specialized knowledge of local laws, and can have implications for compliance with those laws.

Props dlh, desrosj.
Fixes #44079.

[iandunn]

In 43287:

Privacy: Require manage_privacy_options to edit policy page.

A user is required to have the manage_privacy_options capability in order to determine which page is set as the privacy policy (the wp_page_for_privacy_policy). Given that, it doesn't make sense to allow users without that capability to edit or delete the page.

A similar situation exists with the page_for_posts and page_on_front options, but Editors are allowed to edit those pages. The reason that this situation is different is because it is more likely that an administrator will want to restrict modifications to the privacy policy, than it is that they will want to allow modifications. Modifications to the policy often require specialized knowledge of local laws, and can have implications for compliance with those laws.

Props dlh, desrosj.
Merges [43286] to the 4.9 branch.
Fixes #44079.

[desrosj]

Moving to the new Privacy component.