Make WordPress Core

Opened 8 years ago

Last modified 3 months ago

#40197 reviewing defect (bug)

meta cap 'publish_post' is not being used

Reported by: panjmp's profile panjmp Owned by: johnbillion's profile johnbillion
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.5
Component: Role/Capability Keywords: good-first-bug has-patch needs-refresh
Focuses: administration Cc:

Description

#21288 adds publish_post to meta cap but it is not being called anywhere. I tried to log it using map_meta_cap at the post edit page. There is only publish_posts called but not publish_post

Change History (11)

#1 @swissspidy
8 years ago

Hey there,

Would you suggest using the publish_post meta cap where possible or removing it? Because just because core isn't using this capability doesn't mean plugins won't.

#2 @swissspidy
8 years ago

  • Version changed from 4.7.3 to 3.5

#3 @panjmp
8 years ago

Hi @swissspidy
I am suggesting that core should implement publish_post where possible since all other meta cap variables are used correctly.

I was working on an advanced role/capability system that allow specific group of users to have edit/publish access based on page's root ancestor. I still cannot find any workaround on this. Advices are thankfully welcomed.

#4 @johnbillion
4 years ago

#52023 was marked as a duplicate.

#5 @johnbillion
4 years ago

  • Keywords needs-patch good-first-bug added

This ticket was mentioned in PR #810 on WordPress/wordpress-develop by carlomanf.


4 years ago
#6

  • Keywords has-patch added; needs-patch removed

#7 follow-up: @manfcarlo
4 years ago

Here is a patch. All four post type meta capabilities are now handled through the same code block, since there was a lot of code being duplicated verbatim between them. The patch moves this to the bottom of the switch block, purely to avoid a messy diff.

The patch attempts to preserve the existing behaviour as much as possible, with two exceptions:

  1. Fixed an error that was accessing non-existent edit_page, delete_page and read_page properties on the post type capabilities object, now edit_post, delete_post, read_post and publish_post are accessed instead.
  1. The publish_post meta capability now respects $args['map_meta_cap'] = false and does not map, previously it was mapping anyway.

As far as changing publish_posts to publish_post, the patch changes it wherever there is a readily available post reference. I verified that this successfully changes the behaviour on the post editor. Some cases, however, (such as the Quick Edit) appear to require a deeper re-tooling to support this meta capability, which this patch does not attempt.

#8 in reply to: ↑ 7 @manfcarlo
4 years ago

  1. The publish_post meta capability now respects $args['map_meta_cap'] = false and does not map, previously it was mapping anyway.

I would guess that last unit test is failing because of this? If a post type has $args['map_meta_cap'] = false then it should be responsible to map publish_post. Obviously this risks breaking many post types, but I would say they are taking on that risk by setting $args['map_meta_cap'] = false.

#9 @johnbillion
4 years ago

  • Owner set to johnbillion
  • Status changed from new to reviewing

This ticket was mentioned in Slack in #meta by joyously. View the logs.


4 years ago

#11 @rmccue
3 months ago

  • Keywords needs-refresh added

One big benefit of changing this would be that you can filter the meta cap, and conditionally allow/deny publication based on the post's content - e.g. you could block publish at the caps level if a condition isn't met. This isn't possible with the generic publish_posts cap, which is missing the context.

I suspect this patch probably needs refreshing, and we need to check that there haven't been any new uses introduced (e.g. for Gutenberg).

Note: See TracTickets for help on using tickets.