[wp-hackers] User Capabilities

[Owen Winkler]

Michael E. Hancock wrote:
> Expanding on the capability/role model described by Mr. Boren, couldn't the
> use of database tables support both capabilities and roles?
> 
> This could be done with two new tables and an additional field in wp_users
> called 'role'.

Alternatively, you could store an array of role definitions in the 
options table, and store an array of roles as a usermeta record.

For example, a record in options with the key "user_roles" could store 
this structure:

array(
	'admin'=>array(
		'create_posts',
		'edit_posts',
		'edit_users',
		'etc.',
	),
	'editor'=>array(
		'create_posts',
		'edit_posts',
		'etc.',
	),
	// etc.
);

In the usermeta table, a single core-defined permission entry would 
contain an array of permissions and roles for each user:

array(
	'editor',
	'edit_users',
);

An array entry that matches the name of a role causes WordPress to 
recursively pull the permissions for that role from its entry in the 
options table.  This system would allow the system to supply both 
numeric-level roles that are parallel to 1.5 and name-based roles for 
future use.

Using this recursive role method, one could define complicated 
heirarchical roles that are transparent to the user without adding 
special parent fields by using this as the roles definition:

array(
	'admin'=>array(
		'editor',
		'edit_users',
	),
	'editor'=>array(
		'create_posts',
		'edit_posts',
		'etc.',
	),
);

(Prevent endless self-referential recursion by keeping the role names in 
the user's permissions list as it's built, and only add permissions from 
a new role if the role isn't already in the permission list.  Maybe 
prefix role names in the permission list with a special character to 
make detection easier?)

There would be no interface to edit this data in the core beyond 
defining a single role for a single user.  A more complete user 
permissions plugin could allow admins to define multiple roles and 
permissions for a single user and/or alter roles and their permissions 
directly.

The nice thing about this system is that it doesn't require additional 
tables, it allows for future use of core-based per-user permissions, 
provides for heirarchical roles in more complicated custom permission 
schemes, and I think it hits all of the requirements we've discussed 
previously.

Owen