[wp-trac] [WordPress Trac] #44468: Introduce infrastructure for testing primitive capabilities granted via `user_has_cap`

WordPress Trac noreply at wordpress.org
Tue Jun 26 17:58:40 UTC 2018


#44468: Introduce infrastructure for testing primitive capabilities granted via
`user_has_cap`
-----------------------------+--------------------
 Reporter:  flixos90         |      Owner:  (none)
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  5.0
Component:  Role/Capability  |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+--------------------
 There are three ways of granting capabilities to a user:
 * Via the database, with capabilities being granted through a role. Those
 capabilities are referred to as "primitive capabilities".
 * Via the `map_meta_cap` filter, with capabilities being resolved to one
 or more primitive capabilities. Those capabilities are referred to as
 "meta capabilities".
 * Via the `user_has_cap` filter, with capabilities being granted as if
 they were in the database too. This has existed for a very long time, but
 has not been used in core until recently.

 **So what is this about?**

 New capabilities introduced to core should not be added to the database.
 However, many of the new capabilities are not meta capabilities, and it
 would be wrong to use `map_meta_cap` for them. Those capabilities should
 be dynamically granted, but essentially behave just like primitive
 capabilities.

 There are numerous of those capabilities in core that historically use
 `map_meta_cap()` (for example `customize`, `manage_privacy_options`, ...),
 and we probably cannot change that. But for the future, we should ensure
 we stick to this separation and only use `map_meta_cap()` for actual meta
 capabilities, i.e. capabilities that receive additional arguments (like a
 post ID, a plugin slug, ...) and are then resolved.

 Originally introduced as part of #41332 (but not being suitable for
 discussion in there), this ticket aims at providing a comprehensive
 testing infrastructure for those capabilities. While currently the only
 capability granted like that is `install_languages`, this infrastructure
 will encourage granting dynamic primitive capabilities the proper way.

 cc @johnbillion

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44468>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list