Closed jedwards1211 closed 8 years ago
Hey, take a look at the 2.0 branch, @mitar is doing a great job with these issues, group changed to partition, there is permission hierarchy, etc... Probably you will enjoy :)
Okay, thanks!
Yes, it looks like 2.0 has good solutions to these problems. Thanks for letting me know, and thanks @mitar!
OK, closing this.
In all other permissions systems I've seen, if a user is in an 'admin' group, it means they inherit all permissions from the 'admin' group. Users in the same group all have at least the permissions for that group in common. Not so in this package: groups don't have any permissions associated with them that users inherit, and users in the same group may have no permissions in common at all.
Think about it: is "group" really the best word for what groups do in this package, or should they be called "contexts" instead? Because really, they allow you to give users different permissions in different contexts.
Secondly, granting a user a set of permissions just by adding them to a group is very convenient, yet not possible with this package. To support an "admin" role along with granular permissions in this package, one has to check either
userIsInRole(user, "myPermission")
oruserIsInRole(user, "admin") everywhere. And think about how this scales with multiple user levels. If traditional groups were provided, one would simply need to check
userIsInRole(user, "myPermission"), and if any of the user's groups have "myPermission", it would return
true`. That cuts out a lot of boilerplate.