[wp-trac] [WordPress Trac] #2787: New Method of storing and calculating cap2user and user2cap

[WordPress Trac]

#2787: New Method of storing and calculating cap2user and user2cap
----------------------------+-----------------------------------------------
       Id:  2787            |      Status:  new                     
Component:  Administration  |    Modified:  Sun Jun  4 23:00:04 2006
 Severity:  normal          |   Milestone:  2.1                     
 Priority:  normal          |     Version:  2.1                     
    Owner:  anonymous       |    Reporter:  markjaquith             
----------------------------+-----------------------------------------------
 This idea came from a conversation I had with Ryan in #wordpress-dev

 '''The Problem'''
 The role/cap system is hindered by having much of its data buried in
 arrays.  User2cap is ridiculous.

 '''The Solution'''
 Roles are meaningless.  Getting users who have role X proves nothing,
 because they could have extra capabilities.  Capabilities are the thing
 you want. ''''Roles are just a capability container... a short way of
 granting a bunch of capabilities to a user.''''  Once you realize that,
 you see that what you really need is a cap2users table, that could double
 as a users2cap table.  That gives you one-query access to "what users can
 do X?" and "What can user X do?"

 '''How Roles Fit In'''
 In order for the role2cap table to be correct, it would need to be updated
 whenever:

  * A user is given an extra capability
  * A user is stripped of an extra capability
  * A role is given an extra capability
  * A role is stripped of an extra capability
  * A user is moved to a different role

 So we'd need a solid API for this.  This is the heavy lifting... done only
 when something is changed on the back end (infrequent).

 '''Schema'''

  * $wpdb->user2cap (per blog)
  * * u2cid
  * * user_id
  * * cap_id
  * * extra_cap

 extra_cap would be a binary flag.  Basically, it would say whether or not
 this cap is associated with a role or not.  It would be used on the
 backend.  The scenario is this:

 User gets granted an extra cap, foo_bar.  Then, they get upgrade to a new
 role that includes foo_bar.  The "extra_cap" flag stays on, because they
 were granted this capability specifically.  If they are then subsequently
 downgraded in roles, or if the role is edited to now have foo_bar cap
 anymore, they keep foo_bar cap, because it is an extra role.  To strip
 users of extra roles, you should have to specifically take it away.
 Changing their role, or editing the role they have shouldn't mess with
 their extra caps.

  * $wpdb->usermeta (multiple blogs can share this)
  * * wp_role => Administrator
  * * wp_otherblog_role => Garbage Collector
  * * wp_otherblog_role => Little League Coach

 Note that a usermeta table can have roles for that user on different blogs
 and that there can be multiple roles for each user, even on the same blog.
 That just means that cap2user has all the capabilities of all the roles
 that the user has, along with all extra caps (marked with extra_cap = 1).

 The array that stores the Role => Cap information could stay as an array.
 It would only be used in API functions on the back end.

 Original conversation.

 {{{
 MarkJaquith: what do you think about doing all the heavy lifting on the
 back end?
 [6:32pm] MarkJaquith: like... just have user2cap
 [6:33pm] MarkJaquith: don't grab the roles live when doing
 current_user_can() or users_with_cap()
 [6:33pm] MarkJaquith: calculate that when a user is changed or when roles
 are changed, and populate user2cap
 [6:34pm] MarkJaquith: who really cares if editing a user takes 4
 queries... it's seldom done.
 [6:34pm] rboren: That's fine.
 [6:34pm] MarkJaquith: Roles are meaningless anyway
 [6:34pm] MarkJaquith: this tells people to focus on capabilities
 [6:34pm] MarkJaquith: define their role in usermeta.  keep role2caps in an
 array, it's only used when updating the user.
 [6:35pm] rboren: We should be able to retrieve all users with a given cap
 though.
 [6:35pm] rboren: We don't do that very well now.
 [6:35pm] MarkJaquith: user2cap doubles as cap2user, right?
 [6:36pm] rboren: It can.
 [6:36pm] MarkJaquith: SELECT DISTINCT user_id FROM $wpdb->cap2user WHERE
 cap = 'foo';
 [6:37pm] rboren: As long as cap2user contains the caps inherited from the
 role.
 [6:37pm] MarkJaquith: yes... calculated when things are changed
 [6:37pm] rboren: We'd have to make sure that a role change updated all
 affected users too.
 [6:37pm] MarkJaquith: yep.  we'd need that to be solid
 [6:38pm] MarkJaquith: And we'd need to deactivate older versions of Owen's
 Role Manager... they could really screw things up with that
 [6:38pm] rboren: Okay.  That sounds like a good possibility.
 }}}

 Paging Owen... your feedback is important on this one.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/2787>
WordPress Trac <http://wordpress.org/>
WordPress blogging software