List view
There are two things in Acl9 that I do in just about every project, and I think they should be part of Acl9. ### 1. Access Audit In just about every serious app I write I want to provide a list of all the permissions that exist in the system, someone wants to be sure that only the right people have the right access to the right things, and so this is a very valid real world requirement. ### 2. Hierarchical User Admin I always want to have a hierarchical structure of editing other users, so the `:admin, of: :school` can administer all the users of their school, that one's easy, but then I also want to have a `:head, of: :department` able to edit all the users in their department, I end up writing my own custom `has_role?` methods so I can put `:admin, of: :target_user` as the access and then I have the code to determine if that `@target_user` is a member of the `@department` that `current_user.has_role? :head` on. Worst is that the *most common use case* for this is being able to edit yourself which means either more `has_role?` code or a `has_role! :admin, self`role for every user in the system - ugly and/or repetitive for something which is a requirement for basically every single auth app I've ever written. --- Both of these things require the concept of sticky roles, these are roles that you will pre-declare in your object models, and when a new object is created the roles will be created too so that they exist already in the DB even before someone is granted one of them. This is an extension of the existing (undocumented) `:system` flag for new roles (which prevents them from being deleted). This will allow us to rely on those roles being there and also to imbue them with some hierarchy where appropriate.
No due date- Overdue by 9 year(s)•Due by March 31, 2016•3/5 issues closed