Child pages
  • 2009 Implementers Group Meeting Program Fixing Roles
Skip to end of metadata
Go to start of metadata
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
  • No labels