New Method of storing and calculating cap2user and user2cap
|Reported by:||markjaquith||Owned by:||jacobsantos|
Description (last modified by markjaquith)
This idea came from a conversation I had with Ryan in #wordpress-dev
The role/cap system is hindered by having much of its data buried in arrays. User2cap is ridiculous.
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).
- $wpdb->user2cap (per blog)
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.
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.
Change History (22)
10 years ago
- Description modified (diff)
- Owner changed from anonymous to markjaquith
- Status changed from new to assigned
- Milestone changed from 2.3 to 2.5 (future)
- Type changed from defect to enhancement
- Owner changed from markjaquith to jacobsantos
- Status changed from assigned to new