Opened 9 years ago
Last modified 4 weeks ago
#37917 new defect (bug)
Users without the edit_private_posts capability can still create private posts
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | 2.1 |
| Component: | Role/Capability | Keywords: | needs-refresh has-patch close |
| Focuses: | 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 (7)
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#3
@
9 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).
This ticket was mentioned in Slack in #core by sirlouen. View the logs.
4 weeks ago
#6
@
4 weeks ago
- Component changed from Posts, Post Types to Role/Capability
- Focuses administration removed
- Keywords needs-refresh has-patch close added; 2nd-opinion removed
Reproduction Report
Description
✅ This report validates that the issue can be partially reproduced.
Environment
- WordPress: 6.9-alpha-60093-src
- PHP: 8.2.29
- Server: nginx/1.29.1
- Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
- Browser: Chrome 140.0.0.0
- OS: Windows 10/11
- Theme: Twenty Twenty-Three 1.6
- MU Plugins: None activated
- Plugins:
- BBB Testing Dolly
- Classic Editor 1.6.7
- Test Reports 1.2.0
- User Switching 1.10.0
Testing Instructions
- Switch to classic editor
- Create an Author user
- Create a new Post
- ❓ You can select the Private Posts.
Actual Results
- ✅ Error condition occurs (reproduced).
Additional Notes
- As @akibjorklund commented, this is technically not a bug, but how you interpret it. This is happening both in Gutenberg and classic editor. Unless, we want a revamp on capabilities, I also think that this is how it is.
- Given that this has had 0 traction for almost 1 decade, and the patch is not applying anymore, I reasonably believe that this is no interst anymore and most people figure out how these capabilities are working. So personally I would tag this as a
closecandidate.
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_postsfor private posts).When trying to publish or make posts private without
publish_poststheir status status is set topendinginwp-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_postscapability 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_postswith 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_postscan 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.)