[wp-trac] [WordPress Trac] #53131: Disjunctive normal form for WP_User::has_cap

[WordPress Trac]

#53131: Disjunctive normal form for WP_User::has_cap
-----------------------------+------------------------------
 Reporter:  manfcarlo        |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Users            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by manfcarlo):

 Replying to [comment:1 joyously]:
 > Your proposed code would fail on the second set because the boolean is
 still the value from the previous set (assuming data of the first set
 doesn't match but second does).

 You're right. `$has_cap_set = true;` should be moved inside the first
 foreach loop. Thanks for pointing out.

 Also, the code is intended more as an illustrative example than an exact
 proposal. The tricky part is backward compatibility.

 Replying to [comment:1 joyously]:
 > Can you give an example of when multiple capabilities are checked, and
 the user has to have all of them to pass the check?


 An example is when a user tries to edit a post that is not their own and
 is already published. They would need all three of `edit_posts`,
 `edit_others_posts` and `edit_published_posts`.



 Replying to [comment:2 peterwilsoncc]:
 > @manfcarlo Thanks for the suggestion.
 >
 > I'm interested to know how this would be an improvement on something
 like:
 >
 > {{{#!php
 > <?php
 > if ( current_user_can( 'permission_one' ) || current_user_can(
 'permission_two' ) {
 >    do_something();
 > }
 > }}}
 >
 > I worry that including the `OR` relationship in the native
 `WP_Core::has_cap()` check could lead to developer confusion so both a
 strong use case and significant benefit would be needed for such a change.
 Are you able to expand on each?

 Because it needs to be able to filter the result of core capability
 checks, using the `map_meta_cap` filter.

 One of my plugins dynamically registers post types through a UI. To be
 able to edit a post of one of those dynamically registered post types, a
 user can either have the explicit capabilities for that post type (saved
 in the database) or they can alternatively pass the capability check if
 they can edit the record that represents the post type, which is a post
 itself.

 Currently, the plugin does this by prematurely calling up `user_can(
 $user_id, 'edit_post', $post_type_record )` and returning `exist` if
 `user_can` returns true. It works, but it's not really the correct
 behaviour of `map_meta_cap`. Ideally, it should be able to just call
 `map_meta_cap( 'edit_post', $user_id, $post_type_record )` and return the
 result as a second array.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53131#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform