Permissions and roles in OSCAR are complex. We have a large set of roles by default which grant varying rights to different objects within the system. Moreover, I'm not certain these objects are fully enumerated in the UI. We also have the complicating factors of how these may interact with CAISI (eg programs), the integrator, or with other similar systems (multisite) – and I don't know that we have enough information for the desired workflows in these cases (in CAISI, how do you determine what program something is relating to? with the integrator, should there be different permissions for integrated items? does multisite have any bearing on this?). We also need to have this information available if we want to make any changes to the UI for this, such as to provide tooltips/additional information on what _admin.misc (a real object) actually means or to show someone's effective permissions or so on.
- Make list of current objects that can be assigned to roles by using the UI list as well as searching at the code level
- Document what those objects control (at a general code/page level) as well as whether this can be set on a patient/provider-specific level and the permission needed (r/w/d/u). (This is In progress: we need to finish off the permission information as well as note whether a page is associated with multiple roles.)
- Make sure each of those objects works as "expected"
- assign a provider with one of read/write/delete/update, then log in to check and see if the pages/page elements listed in the document are visible/modifiable/etc as per the permission
- repeat for each permission
- then work to see if priority works correctly (assign read then "no rights" set higher priority for "no rights", then check)
- then check that updating/deleting permissions/priority for objects works correctly (example: what happens if you have a "no rights" and a "read" permission with same priority)
- if the object includes patient-specific permissions, check to make sure those override correctly
- if there is a call to the object in Oscar that has two roles (eg on billinghistory.jsp, objectName="_admin,_admin.billing") check to see what happens if you have a "no rights" on one and a "read" permission on the other. reverse the rights and repeat.
- check role vs personal rights and whether the order of application matters
- add a role, add a right to the same object with different permissions, check results, then set priorities for one/both and check results
- add a role, add a different role with different permissions on an object, check results, set priorities for one/both and check results
- Make sure the default rights for the roles make sense (for example, all the "newCaseManagement" objects don't seem to exist for anything other than admin/doctor roles. I suspect they simply haven't been updated since those objects were added, but this has knock-on effects such as anyone other than doctor/admin roles being unable to access the eChart by default).