Title: User capability Bug?
Last modified: August 25, 2026

---

# User capability Bug?

 *  Resolved [bluelumines](https://wordpress.org/support/users/bluelumines/)
 * (@bluelumines)
 * [1 week, 3 days ago](https://wordpress.org/support/topic/user-capability-bug/)
 * If going to the Advanced tab for a custom post type and change User capability
   to custom and later deside to revert back to post, administrator lose control
   over the post type. If checking “Full User Capabilities” administrator gain control
   again. But this checkbox isn’t checked as default for other custom post types
   while administrator still have full controll? Why is that?

Viewing 3 replies - 1 through 3 (of 3 total)

 *  Plugin Author [Scott Kingsley Clark](https://wordpress.org/support/users/sc0ttkclark/)
 * (@sc0ttkclark)
 * [1 week, 3 days ago](https://wordpress.org/support/topic/user-capability-bug/#post-19002442)
 * You might try to flush caches with Pods Admin > Settings > Clear Pods Cache
 * If that doesn’t work, what capabilities does the Access Rights tab list when 
   you are editing the Pod config? When you toggle between the settings you will
   have to refresh the page after save to get the latest list of capabilities to
   show.
 *  Thread Starter [bluelumines](https://wordpress.org/support/users/bluelumines/)
 * (@bluelumines)
 * [1 week, 3 days ago](https://wordpress.org/support/topic/user-capability-bug/#post-19002473)
 * 
   Custom post type: booking. User Capability: post.Full User Capabilities: unchecked
   Role administrator has full control, this is the default setting by Pods
 * 
   Change User Capability to custom -> booking -> SaveChange User Capability back
   to post -> SaveRole administrator loses full control You now have to check “Full
   User Capabilities” to gain control again which as default did not have to be 
   checked.
 * Clear Pods Cache does not reset capabilities for administrator
 *  Plugin Support [pd](https://wordpress.org/support/users/pdclark/)
 * (@pdclark)
 * [5 days, 12 hours ago](https://wordpress.org/support/topic/user-capability-bug/#post-19006839)
 * The reason for the unexpected behavior is likely due to multiple misunderstandings
   regarding how [WordPress roles & capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)
   operate:
 * **edit/read/delete capabilities:**
 * As indicated in the help **?** text of the **User Capability** option, a custom
   capability such as `booking` will be used in several forms, same as `post` or`
   page` : `edit_booking`, `delete_booking`, `read_booking`
 * **“full user capabilities” (delete/private/plural variations)**:
 * As indicated in the help **?** text of the **Full User Capabilities** option,
   checking the box will cause many more capabilities to be defined and used for
   the post type, including:
 * `delete_{capability}s`
 * `delete_private_{capability}s`
 * `delete_published_{capability}s`
 * `delete_others_{capability}s`
 * `edit_private_{capability}s`
 * ` edit_published_{capability}s`
 * …notice how the three capabilities now have plural versions, and variations depending
   on whether a post is public, private, authored by another user, etc.
 * **Users with role **`administrator` **do not automatically have all capabilities:**
 * **administrator** is a role which is assigned certain capabilities
 * If you define new capabilities, they do not necessarily get automatically assigned
   the administrator role
 * If you change capabilities for the role, but do not clear caches, the user interface
   might not update immediately
 * Within Pods, you can check and edit capabilities assigned to roles using **Pods
   Admin > Components > Roles & Capabilities**
 * **WordPress roles & capabilities are a facade**
 * It is important to understand that the WordPress user roles and capabilities 
   system is DEFINED WITHIN THE SYSTEM TO WHICH IT ATTEMPTS TO CONTROL ACCESS
 * For this reason, it is not capable of doing the thing it is designed to do except
   within very narrow conditions.
 * Specifically, for a capability to be respected by PHP, it has to be CHECKED by
   PHP. Most plugins within WordPress and all systems outside WordPress do not check
   these capabilities.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fuser-capability-bug%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/pods/assets/icon.svg?rev=3286397)
 * [Pods - Custom Content Types and Fields](https://wordpress.org/plugins/pods/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/pods/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/pods/)
 * [Active Topics](https://wordpress.org/support/plugin/pods/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/pods/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/pods/reviews/)

 * 3 replies
 * 3 participants
 * Last reply from: [pd](https://wordpress.org/support/users/pdclark/)
 * Last activity: [5 days, 12 hours ago](https://wordpress.org/support/topic/user-capability-bug/#post-19006839)
 * Status: resolved