#52043 closed defect (bug) (duplicate)
Post type listings in submenus require parent menu capability
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Posts, Post Types | Keywords: | has-patch |
Focuses: | administration | Cc: |
Description
If a post type is registered under a submenu, such as $args['show_in_menu'] = 'options-general.php'
or $args['show_in_menu'] = 'themes.php'
, viewing the post type listing seems to require the capability to access the parent page.
If a user lacks the capability for the parent page but does have the capability to edit the post type, the post type appears in the admin menu, but returns a 403 error when navigated to.
This makes no sense because the user actually does have the capability to access that page, and it's an independent page with its own capabilities.
Note that even the parent menu link will be modified to point to the post type listing, rather than the normal parent page that they genuinely lack the capability for.
There appears to be handling for this equivalent scenario for options pages, but not for post type listings.
Change History (9)
This ticket was mentioned in Slack in #core by manfcarlo. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by mamaduka. View the logs.
4 years ago
#5
@
3 years ago
Is this bug likely to be prioritised for 5.9? I don't know whether it still directly affects the new core post types, as things are moving too fast for me to keep up, but it could affect many plugins and should be fixed in any case.
#7
@
3 years ago
- Keywords has-patch added
There's a pull request at https://github.com/WordPress/wordpress-develop/pull/3024 that appears to solve this issue.
I just now noticed this trac ticket mentioned in the Core Slack channel.
"It's also quite relevant to FSE, since it will affect the new post types."
@aristath @gziolo @annezazu