[wp-hackers] User roles - GSOC proposal
n.prasath.002 at gmail.com
Mon Mar 29 12:48:49 UTC 2010
I also think scaling roles hierarchically I not a good idea.
(Currently joomla 1.6 ACL scales roles hierarchically and I also
experience difficulties with that)
I,m trying to implement a friendly UI to set permissions for roles in one view
(like drupal permission settings).
I installed your plugin, but it only shows userdata when you are
logged in as admin.
Thank for your suggestions.
>> roles per category is a non-starter
I wonder why it I not desirable to have category level roles within a
It has been requested by many in the forum and mailing lists.
It is also mentioned in the ideas list.
>>from 3.1 storing capabilities in user meta is to be removed and and replaced with roles(unserialized).
If I,m not wrong the implemetation would be an additional
table(wp_roles) to store information about roles which will include
userId's belonging to that role.
It I possible to have category level permissions by having a table which maps
userId , roleId, categroyId(termId).
Querying for users will also be easy by filtering
categoryId → roleId → userId.
I,m from a joomla backround and joomla does access control like this.
in addition to multiple roles in multiple blog this would be an
Correct me if I,m wrong
thanks for the feedback.
On Mon, Mar 29, 2010 at 9:37 AM, Andrew Nacin <wp at andrewnacin.com> wrote:
> On Sun, Mar 28, 2010 at 9:51 PM, 24/7 <24-7 at gmx.net> wrote:
> > Better user-management: +1
> > Reworking the system: +1
> > Category level permissions: +1
> > Multiple Roles: +10!!
> Roles per category is a non-starter, honestly, for the reasons outlined
> below -- there are intentions to move in the opposite direction.
> (Workaround: A custom post type has its own set of capabilities.)
> So, currently:
> - users can have multiple roles
> - users can have multiple caps that override those of roles
> - for each user, we store the roles and caps as a serialized array in
> - to get all users who have a role or cap, we query all users in the DB,
> load up their roles and capabilities, and filter out those that don't have
> the role or cap
> There aren't too many plugins that actually use multiple roles -- membership
> or newsletter plugins is the main use case.
> These two tickets should be studied closely:
> http://core.trac.wordpress.org/ticket/10201, and
> http://core.trac.wordpress.org/ticket/2531. The IRC log in #10201 in
> particular (from summer 2009) was a conversation among at least four core
> developers, and a consensus was reached.
> The general (and admittedly controversial) idea for 3.1 would be the
> - users can have *one* role
> - users cannot have any user-specific caps
> - for each user, we store the role in usermeta (unserialized)
> - to get all users with a role or cap, we can query usermeta
> (Just something to keep in mind, roles/capabilities are stored in usermeta *per
> blog*, not per user. Hence, in a shared user table or multisite/MU setup,
> the user still has a different role for each blog, even with #10201.)
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers