#56280 closed defect (bug) (duplicate)
Access denied to custom post type listing in admin when his submenu is empty
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | major | Version: | 6.0 |
Component: | Posts, Post Types | Keywords: | has-patch |
Focuses: | administration | Cc: |
Description
I created a custom post type and a custom role with capabilities only for the custom post type. Then I was trying to hide the submenu for the custom post type and leave only the main menu item, but when I do it, the user can't not longer access de page to view the custom post types or to add a new one.
"Sorry, you are not allowed to access this page."
Steps to reproduce:
- Add "Movies" Custom Post Type
- Hide "Movies" submenu (remove_submenu_page)
- Register "Movie Editor" role
- Create a user with "Movie Editor" role
- Login to the admin section as the new user
- Try to access the Movies page in the admin
I build a plugin that shows the problem.
https://gist.github.com/leo020588/c9b82883fc1b0275e0f46bf0b0ece083
My reasoning for why this is a bug, is because the custom post type and the role have the right permissions, so even if the submenu is hidden it should possible to view the list of custom post types from the main menu which is still visible.
Wordpress: 6.0.1
Change History (6)
This ticket was mentioned in PR #3017 on WordPress/wordpress-develop by luistar15.
3 years ago
#1
- Keywords has-patch added
#2
follow-up:
↓ 5
@
3 years ago
Thanks for the report and the patch. I thought this looked similar to #52043, so I quickly tested your patch against the other issue and it didn't seem to solve it. Do you think both issues share the same cause, meaning that your patch could potentially be amended to solve the other issue as well, or do you think the two issues are unrelated?
#3
follow-up:
↓ 4
@
3 years ago
- Component changed from Administration to Posts, Post Types
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
Hi there, welcome back to WordPress Trac! Thanks for the report.
We had similar reports in #29714, #32088, and #39745, and are now tracking this issue in #22895. Could you add your PR there? Just updating the ticket URL in the PR description should work.
Some other tickets that might be related: #16808, #48511, #50252.
#4
in reply to:
↑ 3
@
3 years ago
Replying to SergeyBiryukov:
Hi and thankyou for the response. I worked in another patch and updated in #22895.
#5
in reply to:
↑ 2
;
follow-up:
↓ 6
@
3 years ago
Replying to manfcarlo:
Hello, I read #52043 and I make rethink my patch.
I have proposed this new patch that I think also addresses the issue #52043.
https://core.trac.wordpress.org/ticket/22895#trac-change-40-1658819005403432
#6
in reply to:
↑ 5
@
3 years ago
Thanks for your work on this. It appears to solve #52043 as per my testing, so I left a note on the ticket for anyone following. I guess we will monitor #22895 now and hope the approval is not far away.
Replying to luistar15:
Replying to manfcarlo:
Hello, I read #52043 and I make rethink my patch.
I have proposed this new patch that I think also addresses the issue #52043.
https://core.trac.wordpress.org/ticket/22895#trac-change-40-1658819005403432
I located the issue in the
funcion get_admin_page_parent
and I made this patch for that works for me.Trac ticket: https://core.trac.wordpress.org/ticket/56280