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, selfrole 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.