Problems stemming from dual-purposing roles for job titles, and application privileges
Example: nurse, doctor, data manager roles to represent jobs, but not all doctors have the same privileges
Should we also solve location-based privileges during this discussion?
First let's solve dual-purposing of roles in the first 10 minutes.
Then let's move on to location privileges and data privileges (e.g. don't show HIV results)
---dual purposed role---
We should have:
Organizational Role, aka Job Title
these would be assigned to Person (not User)
No heirarchy needed
You would drive UI for "choose provider" via this.
Application Role, aka Privilege Group
(Ben says: this could just be a privilege if privileges can contain other privileges)
Jim: MS Authorization Manager uses this terminology
Operation (like a Privilege)
Task = group of Operations, (or inherit from other Tasks)
Role = group of Tasks and/or Operations
User: can have roles assigned
User groups: can have roles assigned
---Options for ORG_ROLE naming---
should we have Manage be Add + Edit + Remove
How do we distinguish in the UI between system privileges, and user-created privilege groups
Burke: I don't want to have to maintain a separate list of "here's the subset of privileges that are really privileges and not groups"
It would be awesome if the mere fact that a method has and @Authorized annotation on it creates that privilege
Burke: the system itself should support inheritable privileges
Manage Locations contains Add Locations, Edit Locations, Remove Locations
Privilege groups should also be inheritable
Privileges and privileges groups can be combined, but we need to add locked or type or something so we know what's a system-provided privilege, and what's a user-created group
We need the idea of purging a module (in the future) that will clean out its privileges.
Assume we have Manage Locations = Add, Edit, Remove Locations
argument about whether code is allowed to check against Manage Location (i.e. a group) or not
do we just allow hasAny vs hasAll
Burke wants a clean way of having a "lockedBy" hack, which would be a string describing which modules (and core) are preventing deletion of a privilege