lh-ehr
lh-ehr copied to clipboard
LibreHealthIO
Authorizations show Unknown Tab
A)Outreach username: sakshi.munjal
B) Issue Title: Authorizations show Unknown Tab
C)Bug Report Date: March 7, 2019
D) Site Affected: Documentation Site
E) OS/ Browser used: Firefox on Windows 10
F) EHR Workflow Module: Authorizations in Miscellaneous module
G) Steps to Reproduce the Bug:
1.Login to LibreHealth EHR and choose English as the chosen Language. 2.Click on the Miscellaneous in the navigation bar and open Authorizations.
H) The Expected Behavior: Module related to clicked link to open.
I) Details of What Actually Happened:
1.The module opens an Unknown Tab.
J) Provide Relevant Screenshot and Explain the Screenshot:
Click on Authorizations in Miscellaneous.
Unknown tab opens up on clicking Authorizations in Miscellaneous.
K) Estimation of The Bug Severity:
• Modules function ceases and user cannot access Authorizations (Major).
L) Workaround:
• User can continue the workflow by closing Unknown Tab.
On the docs site @KoniKodes and should be same for NHANES - see below surely this should be due to limited permissions
That makes sense @muarachmann I'm sorry @sakshi1499 but as an applicant, you don't have full administrative authorization.
I have a Test User-Intern who has the same admin restrictions as the applicant. And the issue is the same. Instead of a simple Unknown Tab, should it not have an alert stating something like "You do not have permission to access this information. Please see your Administrator."
Yes, totally. Or not even show in the menu. Biggest issue currently is the ACL system, which is a smarty based GACL. A much more simple application specific fine-grain set of user access table check items should replace it.
Current implementation of GACL is the same as it was in OpenEMR about 100 years ago. It was inexplicable and implemented in a random way at the time, and it has hardly been touched since.
YES! YES YES YES! Issues with that: GACL is too big for the simple use-case we need. The "objects" and "groups" defined in the implementation were defined around a tiny clinic doing certain things on a version of the software from 15 years ago, and is irrelevant. None of the above was documented or particularly well tested even at the time. What is "office, write wsome"? No one really knows! We have to define code pieces relevant to certain features, continue to organize the code into modules, then relate those to security roles as well as to sections of the patient population. The last bit is pretty complex. The first bit is simply a matter of enabling fine-grain control over everything in the EHR. Instead of saying that a piece of code like "patient search" can only fire if someone has "front desk" access, it needs to ask if the user has "patient search" access. Literally every report and feature needs it's own unique ID.
Great! This is something I have been wanting to see since I began as an intern.
I would love to be a part of it, and I think our chosen EHR Coder Outreachy Intern would be interested as well.
This is seriously a project that comes from the use-case, and therefore documentation side. On one hand, it is a huge thing to manage. On the other, the approach is simple. It boils down to a function call named "acl_check()". Still no-where near as complex of an issue as the translations bit.
Ensuring you understand how this bit is used is also important. I can at least advise you there. Trust me, it is a clinical logic bit that could use some help, but making it work is the first step. Making it work right is the second. Last but not least is making it work fast.
Right now, we have a user on a site that is getting a broken link (essentially the "unknown" tab display) when they click on Authorizations. Basically, this means that a lower access level person needs to have "view authorizations (all) in their user access settings. It is not inappropriate to change the ACL in the doc site to allow someone to use this particular interface. At the same time, the role-based menu or the menu ACL settings should be set up to remove the report option from the user's view if they do not have access to it. Last option is to, in the report's code, allow the code to run and display "You do not have permission to see [$this]" instead of simply allowing the script to die.
Hi @aethelwulffe working on ACL was part of my interim project with with while waiting to hear the announcement. Here is what I have come up with so far https://docs.google.com/spreadsheets/d/1uy7iSa9sUcPttXWKRYyfXsLo0yvkeUs0MqHZ-4fucqM/edit?usp=sharing
I have done a search on the entire EHR and found where the different permissions where used. So My next update will be stating privileges are required for viewing and editing particular sections of the EHR.
For example, an admin(because admin can do anything) , accountant or a user with an accountants role of 'rep_a' ( rep_a is explained in the above document) can view a drop-down list of providers in Reports -> Financial -> Sales by Item and an additional role of 'rep' can perform a search. By default admins and accounting have this but any other created user like 'Outreachy' (as i saw on the docs site) will need to be these privileges by an admin.
I recommend that you ignore how it was done in the past, if that pleases you. "rep_0" is a terrible name, as is "billing_wsome". Use real specific identifiers, and give the administrator a way to see all that is possible, and understand the full effect of what a user has access to.
IMO:
I would drop the role level concepts currently in the GACL and invent your own based on a list of Major features (Menu items) and sub-features (where we check the access level within a script). Having an interface that actually names the feature and sub-feature, then allowing group or individual user access to each (allowing the administrator to clearly see what is what) would be a great thing. This would require developers of new features to publish an ACL unique identifier for their new features.
ACL should drive the creation of a user's menus, vs. the menu checking the user's ACL
On 2019-05-13 06:38, Ngai Elizabeth wrote:
Hi @aethelwulffe https://github.com/aethelwulffe working on ACL was part of my interim project with with while waiting to hear the announcement. Here is what I have come up with so far https://docs.google.com/spreadsheets/d/1uy7iSa9sUcPttXWKRYyfXsLo0yvkeUs0MqHZ-4fucqM/edit?usp=sharing
I have done a search on the entire EHR and found where the different permissions where used. So My next update will be stating privileges are required for viewing and editing particular sections of the EHR.
For example, an admin(because admin can do anything) , accountant or a user with an accountants role of 'rep_a' ( rep_a is explained in the above document) can view a drop-down list of providers in Reports -> Financial -> Sales by Item and an additional role of 'rep' can perform a search. By default admins and accounting have this but any other created user like 'Outreachy' (as i saw on the docs site) will need to be these privileges by an admin.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LibreHealthIO/lh-ehr/issues/1419#issuecomment-491770194, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEHGF2CXE36YPQICESNOJ3PVFAIXANCNFSM4G4GIWCA.
Thanks very much Art for this
On Mon, May 13, 2019, 15:08 Toni Shortsleeve [email protected] wrote:
Yes.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LibreHealthIO/lh-ehr/issues/1419?email_source=notifications&email_token=AD4X4XXE5TBW73EIU7JHK33PVFY5JA5CNFSM4G4GIWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVINSXA#issuecomment-491837788, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4X4XVCJ5CJGYFDO2VHV5LPVFY5JANCNFSM4G4GIWCA .
For what? Telling you not to let our ancestors decide on how we are going to do things? -Ignore them! You KNOW THIS! :) -Anywho, we want to get rid of the whole GACL package. Basically, that whole package has a lot of database tables, and complex code and utilities that 1998 is calling demanding the return of. We use (essentially) a single function that checks two arguments against values (out of all that). It was implemented in a quickie fashion about 17 years ago, and no-one has altered it since.
-Oh yeah, and I think we should resurrect the database side menu approach, and dump the JSON file. It is a nightmare when you have multiple /sites directories you need to update, and even if you do use JSON to store the data that drives the menu, it should be stored as a string in a DB, not a file that requires editing and directory permissions.
So if I understand correctly, we want the view to only show what the user is authorized to access. We can have it Menu and Submenu based, using a script to confirm authorization. ACL should access the Menu's database according to that authorization - which the administrator will understand because the codes are now in easy to understand names. Am I missing anything?
Yes. You are missing the stuff we have not thought of yet. -Push for an elegant solution. Start an issue thread to discuss. Explore use cases and though experiments. Write the end-user documentation on how it works, mock it up, and show how to administer it before you start to code. Figure out what the boat looks like before you start cutting wood, and don't worry about how Grandpa used to build boats.
OK. This is going to be interesting... So we'll close this and open a new thread?
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.
-Yeah, do the writeup for the discussion. We can start a "Project" here for that. In the meantime, this is still showing a bug, unless there was nothing in the test data that gave a result, even then it should still work.
Ok. I've opened the new discussion: https://github.com/LibreHealthIO/lh-ehr/issues/1475