Perhaps we could not have our Roles library decide this for the users, but instead provide examples of how to use the library for a few of the most common access/revoke patterns.
This is what I wanted to explain with the code samples above. As I see it, there are three levels in designing an application that includes permissioning:
- The base role data types and the functions that manage them.
- The rules on how to add and remove roles and permissions, which change for each business.
- The actual business functions, that only use RBAC to check if bearers hold specific roles.
The base rbac contract should be common to all applications, but rarely used as is. This should be provided as part of your packages.
The business rbac contract implements how the business sees roles. There are multiple variations of these, all extending from the base contract. You can provide some common implementations for reuse or as example (SuperAdminRBAC, TransferrableRBAC, etc…). However, many businesses will code their own contracts at this level.
The business functions contract implements the business, and only calls
view functions from RBAC. I think that this separation between business and permissioning is important.