2009 Implementers Group Meeting Program Fixing Roles

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
2 min read
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--- Organizational Role Job Title Job Role Position ... Privileges: View Person Add Concept Manage Locations 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