lh-ehr
lh-ehr copied to clipboard
LibreHealthIO
Discussion for User Authorization with Menu and Database functions
This thread is to discuss a possible new format of user authorization that allows the user to only see the menu items allowed by the authorization level. This eliminates the Unauthorized Access errors that may be encountered.
This discussion began in issue 1419.
Currently, a particular page/script tells GACL who has access to it, such as acl_check('admin'). We should flip that in it's head. Instead, a particular page should just identify itself, such as ACCESS_ID('thisreportname'); The ACL then engine looks to the configuration to see if the user "bob" has access to this specific report, not to see if 'bob' has access to 'admin' stuff.
How can we make this happen?
So I need your feedback, ideas and we need to make it look understandable...
Great so we need to go through all the menu and submenu items to note down how they can identify themselves. So, when we create a user we just assign the users the menus that can be seen. User can now only see what is required. Is that it?
This is great since any new developer can easily implement his own access id and just add to the current documentation instead of trying to figure out the gacl system which may lead to potential future malfunctioning.
I see several things that might help.
- Start your project by simply ripping out anything related to GACL, or the functions therein.
- Each page/feature/script top level page should have an ID function added with that feature/page unique ID.
- DB tables that hold references/links to a "registry" of pages/features/scripts that are directly accessed should be created.
Additional ISSUES: Some SUB-FEATURES/views of data need additional checks. For instance, let us say you have a clinic with THREE facilities: Facility Alpha: A central office where doctors work out of. They do all administrative tasks here, and they may or may not actually see any patients here. Facility Beta: Another building that the doctors travel to and see patients. There are staff here that should only see their patients that visit or are at Facility Beta. Facility Gamma: Same as Facility Beta, but should be restricted to seeing patients that have visited Gamma.
So, in Patient Search, on the Flow Board, and in the Calendar, the staff at Facility Beta and Gamma should only see the patients and appointments for their respective facility. The doctors and staff at Facility Alpha should be able to see EVERYONE. The above is what the Facility ACL changes that have never gotten merged do. There is still an unreviewed branch with those changes floating around here, and it is also in the latest PR SunCoast RC 2.02. Those have not been tested, and deployment elsewhere has been limited due to issues with the iziModal User and Facility Admin stuff. If the above can be worked out within the same ACL system by making it "user facility authorized" aware, that would be great. Otherwise, we can make/keep the separate functions for limiting view as-per feature, as they are in those pull requests.
You can find your list of things already restricted by searching the code-base for "acl_check".
You can find your list of things already restricted by searching the code-base for "acl_check".
Yeah i did that and saw everything
I think you are on top of this, frankly. I am going to offer advice, but this can totally be your baby. -Raise it right!
ABSOLUTELY. Anything and everything we can compartmentalize is good. We may, at some point start needing to mark certian "modules" as "core", but it is great to have everything in one place for a given feature. This will be one we will revisit many times, as we are, at first, simply looking for an minimal viable product. There are too many advantages to leveraging access control to ever leave it alone for long periods. Also, while we might not implement much initially, this could become the primary security module. It would always be under scrutiny, so having it all in one place makes a LOT of sense. Moving all the usergroup stuff into here would help that a lot.