Opened 8 years ago
Last modified 5 years ago
#37917 new defect (bug)
Users without the edit_private_posts capability can still create private posts
Reported by: | ryan.kanner | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 2.1 |
Component: | Posts, Post Types | Keywords: | 2nd-opinion |
Focuses: | administration | Cc: |
Description
Currently, users without the "edit_private_posts" capability, can still view the "Private" radio button under "Visibility". They can also save / publish the post (depending on their capabilities) with no issue. The same goes for pages as well with the "edit_private_pages" capability. I think it's reasonable enough to assume that users that don't have the "edit_private_{post_type}" capability, shouldn't be able to create posts with a visibility of private.
Attachments (1)
Change History (5)
This ticket was mentioned in Slack in #core by helen. View the logs.
8 years ago
#3
@
8 years ago
- Version changed from trunk to 2.1
This likely dates back to the introduction of edit_private_posts
in 2.1 (https://codex.wordpress.org/Roles_and_Capabilities#edit_private_posts).
Note: See
TracTickets for help on using
tickets.
Hi @ryan.kanner, welcome to the WordPress Trac! Thanks for your report and for taking the time to create a patch.
While your assumption is indeed very reasonable, I think this is at least partly intended behavior. It is just unintuitive and does not allow fine grained enough control. That is, if I'm understanding things right after doing some research on the subject.
Users, who have the capability to
publish_posts
, but do not haveedit_published_posts
, can publish posts. They just can't edit them afterwards without the capability. Similarly, it makes sense that users cannot edit private posts afterwards withoutedit_private_posts
. But alas, there is no separatemake_posts_private
(the equivalent topublish_posts
for private posts).When trying to publish or make posts private without
publish_posts
their status status is set topending
inwp-admin/includes/post.php
. XML-RPC does its own similar validation, but throws an error. REST API too requires `publish_posts` for private status.So the
publish_posts
capability is used instead to also cover cases where status is changing toprivate
. It makes sense, because if this capability is missing, none of the visibility choices would appear. For more fine-grained control, a new capability would have to be introduced. And that would have to be enforced in many more places than on the UI level. XML-RPC and REST API included.I'm not totally convinced it makes sense to tie
publish_posts
with making postsprivate
, but that is how it works and it is would probably be very hard to change. So if we were to introducemake_posts_private
, then that would have to depend onpublish_posts
.I think the next step would be to hear some arguments why such new capability would need to exist, other than just for completeness (which would be a valid reason to me). What are the use cases for this? What sort of harm is done if people with
publish_posts
can also set status toprivate
? If there is not much harm and the thinking behind the tickets is just to prevent users accidentally setting posts to private, creating a plugin that hides the options with CSS based on for example a custom capability or a user role would do just fine. (It is another issue altogether, but personally I think private posts don't have much use, so they mostly just clutter the UI.)