[wp-trac] Re: [WordPress Trac] #2531: Functions for registering
additional capabilities and getting a list of all capabilities
WordPress Trac
wp-trac at lists.automattic.com
Fri Apr 21 18:53:16 GMT 2006
#2531: Functions for registering additional capabilities and getting a list of all
capabilities
----------------------------+-----------------------------------------------
Id: 2531 | Status: new
Component: Administration | Modified: Fri Apr 21 18:53:16 2006
Severity: normal | Milestone: 2.1
Priority: normal | Version: 2.0.1
Owner: anonymous | Reporter: markjaquith
----------------------------+-----------------------------------------------
Comment (by ringmaster):
I must assume that ryan's table idea was just a lark. Five new tables for
capabilities? That's insane.
Here are my other thoughts:
I like the idea of the WP-native get_all_caps(). That seems practical.
I do not like the idea of registering caps using only the registration
functions. Here's why:
Suppose you have a plugin that replaces a single intrinsic cap with three
custom caps that provide different tiers of access to the same feature.
Using only the registration functions, it is not possible to remove the
intrinsic cap from the list. (In case you were wondering how this would
be done technically, you could use hooks to grant/deny the intrinsic cap
from users based on the application of your custom caps in whatever
circumstances happened to apply.)
What difficulty would there be with moving the Role Manager's cap filter
into the core? It allows direct access to the array of available caps so
that caps can be added ''and'' removed.
If we're talking about making grander changes....
Un-array the caps. Currently, it's very difficult to answer questions
like "Which users have cap X?" If we stored caps as multiple individual
rows in the options table instead of as an array in a single row, these
types of queries would be easier.
If you really needed to, the caps could be pushed to their own table- one
row per cap per user. There would also need to be a store for caps in
roles, which could probably just as efficiently stay in options as make a
second table. So two new tables at most, but I don't see a lot of benefit
there.
--
Ticket URL: <http://trac.wordpress.org/ticket/2531>
WordPress Trac <http://wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list