In case anyone is interested, I have checked in openemr/acl_setup.php which is of interest to those who want to use phpGACL for access control. This program can be run at installation to create various entries in the phpGACL database that are required by OpenEMR.
I set this up in a test system. In my testing I noticed that a "front staff" user was able to still create an encounter even though there is no access for that in the ACL. The "Encounter" menu option still shows up. I created the initial encounter (chief complaint form), then created another encounter form (ankle form). I then went to see if it would show up in an authorized users list and sure enough it does.
So… all this to ask, is the ACL adherance dependent on the form creator or can we force it at the menu level?
Access control implementation is not yet complete. I.e. there are places where permissions checking still needs to be added, and evidently this is one of them.
To answer your question, the creator of an encounter may have more rights to it than others. See acl.inc for descriptions of the different types of access.
What is the methodology to determine if ACL are implemented? Should we check for the existance of $phpgacl_location or should there be a boolean variable set somewhere in acl.inc? Reason I’m asking is that the code in some places assumes the that ACL is being used (like <openemr>/interface/problem_encounter.php) and throws up the “Unauthorized message”.
OpenEMR logic should always assume that access control is implemented. When you check permissions by calling acl_check(), it will do the right thing if phpGACL is not in use.
This also leaves the door open to other access control methods besides phpGACL, just by making suitable changes to acl.inc.
So, I’m somewhat confused. If a person doesn’t impement ACL, then OpenEMR should behave like it did before ACL controls were put in, correct? If that is the case, then what I’m saying is that there is something wrong with the current implementation because I was getting the “Not authorized” messages before I implemented phpgacl. I was under the impression that it should look like it did before acl.
It’s possible to get a “not authorized” message without phpGACL. For example if the user is not a practitioner (i.e. the authorized flag is not checked in their user settings) then they will not be able to see the problem/encounter display, as it contains medical information about the patient (note there was no problem/encounter feature prior to phpGACL support).
If you think you are getting “not authorized” when you should not be, then I’ll need detailed information in order to track down the bug.
I updated from cvs as of last week and since then we started gettin the "Not authorized" messages. I just installed and setup phpgacl and all went well, so as to not get the unauthorized stuff without reason. At any rate, I was getting the message under interface/problem_encounter.php. The code checks:
if ($patdata[‘squad’] && ! acl_check(‘squads’, $patdata[‘squad’]))
$thisauth = 0;
if (!$thisauth) {
echo "<html>\n<body>\n";
echo "<p>You are not authorized for this.</p>\n";
echo "</body>\n</html>\n";
exit();
}
and from acl.inc it says:
function acl_check($section, $value, $user = ‘’) {
global $gacl_object, $phpgacl_location;
if (! $user) $user = $_SESSION[‘authUser’];
if ($phpgacl_location) {
return $gacl_object->acl_check($section, $value, ‘users’, $user);
}
So it seems that it is not setting the value correctly. Perhaps it should check if the the location variable is set isset($phpgacl_location) and if so return the acl_check otherwise return true.
Did you notice that the acl_check function in acl.inc has additional code that is executed in the case where $phpgacl_location is not defined? It does return true (actually ‘write’) in most situations. This is were we try to duplicate the original behavior of OpenEMR without phpGACL.
You didn’t say if the users getting the “unauthorized” message from problem_encounter.php were set up as practitioners. If they were not, then the message is to be expected.
Yes, I saw the rest of the code in the function, but the prior version did allow these things. I understand that now the ACL (even when not using phpgacl) is more stingent than before. I misunderstood thinking that if one did not implement ACL then the rules would be as before, which seemed to be only two types of users: authorized and unauthorized. Perhaps I am missing something. At any rate, I am using phpgacl which is better by far.