[wp-trac] [WordPress Trac] #37917: Users without the edit_private_posts capability can still create private posts

[WordPress Trac]

#37917: Users without the edit_private_posts capability can still create private
posts
-------------------------------+------------------------------
 Reporter:  ryan.kanner        |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+------------------------------

Comment (by akibjorklund):

 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 have
 `edit_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 without `edit_private_posts`. But
 alas, there is no separate `make_posts_private` (the equivalent to
 `publish_posts` for private posts).

 When trying to publish or make posts private without `publish_posts` their
 status status is set to `pending` in `wp-admin/includes/post.php`. XML-RPC
 does it's own similar validation, but throws an error. [https://github.com
 /WP-API/WP-API/blob/develop/lib/endpoints/class-wp-rest-posts-
 controller.php#L880 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 to `private`. 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 posts `private`, but that is how it works and it is would probably
 be very hard to change. So if we were to introduce `make_posts_private`,
 then that would have to depend on `publish_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 to
 `private`? 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.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37917#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform