Upgrading OpenEMR

xiaoanri wrote on Friday, May 15, 2009:

Hi,all,

I followed Brady’s instruction to upgrade to 3.0.1, somehow could not login with admin/pass or any other user for that matter.  I tried the following workaround, it seems working so far:

I dumped  openemr.sql first, then dropped the database.  Next, I did a clean install of the new 3.01 version, let the program create new openemr.sql, with the gacl tables builin. I then restored data to the new file, loggedn in to openemr with admin, I have all users there, all I needed was to reset the acl control to each user.  yes, the user/passwd data must be in openemr.sql, not in gacl database. 

Not sure about long term complications with this way.

hui

bradymiller wrote on Friday, May 15, 2009:

hui zhu,

sounds painful.

To help out others:
What was your OS?
Previous OpenEMR version?
Did you have php-gacl installed externally?
Were you using sql-ledger?
It sounds like you had a user named ‘admin’?

Which instructions did you follow (this thread, from oemr.org, or bradymd.com appliance ugprade)?

How did you migrate your external php-gacl (did you use the http://bradymd.com/prefixMod.tar.gz script or did you re-build it with the setup scripts)?

Did you make any modifications to other files not mentioned in instructions (such as openemr/library/acl.inc)?

What happened when you logged in as admin/pass (I’m assuming your password was ‘pass’)?

If experience this after upgrading the things I’d make sure are:
-The database settings in openemr/library/sqlconf.php file are identical to the opeenmr/gacl/gacl.ini.php and openemr/gacl/gacl.class.php settings.
-The gacl tables names start with gacl_ in the openemr sql database.

If you are locked out of the embedded gacl (this should only happen to users who do not have an ‘admin’ user in their openemr), there is a method to get back in; it involves uncommenting acl control from several php-gacl files and manually putting a user directly through php-gacl with administration privileges.

As long as you upgraded your openemr sql database via sql_upgrade.php script before creating the openemr.sql dumpfile then you should be ok.  You wouldn’t by chance have a dumpfile of the openemr database when you weren’t able to login; that would shed lots of light on the unable to login problem.

-brady

drbowen wrote on Friday, May 15, 2009:

I don’t have an “admin” user.

Sam Bowen

bradymiller wrote on Friday, May 15, 2009:

Sam,
   To simplify, create an "admin" user in openemr whom is authorized and active before you do the upgrade.  Otherwise you will fall into a minority of upgraders whom will need to "break into" openemr/gacl after your upgrade (to be included in this privileged minority you would need to upgrade without an "admin" user and rebuild your gacl tables instead of migrate them).  If your curious, breaking in just means commenting out the acl access controls on several of the php-gacl embedded scripts, and then runnning them directly to add a user and give admin access to them (the old way of adding users in php-gacl documented by Rod in the old user manual).
-brady

drbowen wrote on Friday, May 15, 2009:

Yes, I have all my scans stored as blobs in the database.  I just migrate my code in the the “history.php” page after I upgrade.  So far I have not had a problem with this.  I think everybody is allowed access to “history.php” so far I haven’t had a problem.

I think Brady, you are suggesting dropping the current GACL to a non-GACL configuration, up grade to 3.0.1 then reinstitute GACL as the new GACL?

Sam Bowen

bradymiller wrote on Friday, May 15, 2009:

hey,
I should also add, that it’s a good idea to keep an ‘admin’ user around (unauthorized ok) in 3.0.1 since the admin->acl tool has been hard-coded to not allow removal of the admin user from the administrator group. This will then stop a user from erroneously locking themselves out of openemr/gacl administration with the click of a mouse button, which would require again breaking into the embedded php-gacl.
-brady

bradymiller wrote on Friday, May 15, 2009:

Sam,
Forgot to ask where are your gacl tables? I’m gonna assume in a separate database.
I’m also assuming you are not using sql-ledger.

No need to really even drop your gacl tables (except to clean things up), since below upgrade process will re-direct to the embedded tables. I’d actually keep them around until upgrades successful, because you can always re-direct the library/acl.inc file in upgraded openemr to your external version of gacl if things go awry.

Here’s what I would do in your situation (I can’t provide any useful advice regarding the blobs):
1) Move old openemr directory to a backup directory
2) Move new version into openemr directory
3) Copy openemr/library/sqlconf.php file from old version into the new version
4) Edit openemr/interface/globals.php (set $webserver_root and $web_root to be same as old version)
5) Open up your openemr/library/sqlconf.php file and note the variables for host, login, pass, and dbase variables (I’d suggest writing these on a piece of paper in the order listed). Then place these values (with above ordering) in the corresponding blank variables found in openemr/gacl/gacl.ini.php (host, user, password, name) and openemr/gacl/gacl.class.php (db_host, db_user, db_password, db_name). Don’t touch anything else in these files.
6) Open sql_upgrade.php in browser and follow instructions (this will upgrade your sql database)
7) Open in browser openemr/gacl/setup.php (installs new embedded gacl tables)
8) Open in browser openemr/acl_setup.php (configure gacl for openemr - this script also makes admin access for the ‘admin’ user. This is why you should make an admin user before the upgrade.)
9) Configure optional settings in interface/globals.php and includes/config.php files

-brady

bradymiller wrote on Friday, May 15, 2009:

oops, one more step:

10) Login to openemr as the ‘admin’ user you created before upgrade.

-brady

drbowen wrote on Friday, May 15, 2009:

Sounds like MS Winodws… uh…I mean MS Windows.

“it’s a good idea to keep an ‘admin’ user around (unauthorized ok) in 3.0.1 since the admin->acl tool has been hard-coded to not allow removal of the admin user from the administrator group”

Sam Bowen

xiaoanri wrote on Friday, May 15, 2009:

Brady,

it IS painful!

Here are some details:

What was your OS?  Ubuntu 8.04
Previous OpenEMR version?  2.9.1dev
Did you have php-gacl installed externally?  yes
Were you using sql-ledger?  not externally, the accounting feature was embeded for 2.91
It sounds like you had a user named ‘admin’?  yes, I changed back the password to ‘pass’ for the upgrade.

I followed the instruction in this thread, in one of your previous posting.

I used your program: prefixMod.tar.gz  to put the prefix ‘gacl’ on.  I did not make any other changes in the newly installed openemr,  but do not recall if I ever made any other changes to other files in the old install. 

When I log in with “admin/pass”, I had the same log in screen flashing back, with red words superimposed on it, saying something like “an unauthorized user ‘admin’ was trying to access openemr at hours:minutes”. 

I have changed all the user names and passwords as it was set in the old files, in sqlconf.php, gacl.ini.php and gacl.class.php.  the only thing is the user in the old install was ‘openemr’ in sqlconf.php, and ‘root’ in the 2 gacl files.  I kept this way since it was working in the old install.

There are 24 gacl tables, I made sure they are all with the prefix ‘gacl’ before sending to openemr.sql.

Last thing is I dumped the openemr.sql first in command line, before I did any upgrade.  I did the upgrade after I restored the database for the new install.  not sure if that would make a big difference? 

hui

bradymiller wrote on Friday, May 15, 2009:

hey,

> I have changed all the user names and passwords as it was set in the old
> files, in sqlconf.php, gacl.ini.php and gacl.class.php. the only thing is the
> user in the old install was ‘openemr’ in sqlconf.php, and ‘root’ in the 2 gacl
> files. I kept this way since it was working in the old install.

My best guess is above was likely your downfall; these settings need to match in all three files. Check out your php log file, I’m guessing you have a mysql unable to connect error when you tried to login.

I think your database should be fine, just a painful road to get there.

-brady

bo2999 wrote on Saturday, May 16, 2009:

If you do everything correctly then the last thing to do is to reboot, or stop and restart apache/mysql to clear cache memory, cookies…  At least, that was my problem as Brady points out earlier.  If it does not work then I suggest that you disable GACL and initialize the GACL database, and log back in as admin. 

Good luck,

Bo,

drbowen wrote on Monday, May 18, 2009:

How do I turn off phpGACL?

I don’t see the following in my version of acl.inc:

[code]

//unset($phpgacl_location);

[/code]

I do have the following line:

[code]

  // $phpgacl_location = "/var/www/gacl";

But it is already commented out (AND my gacl is working).

This is the entire file (if this is helpful):

[code]
<?

  // If you have installed phpGACL (http://phpgacl.sourceforge.net/)

  // and have configured it for your site, then uncomment the following

  // statement and change it to point to the location where

  // gacl.class.php is intalled.

  //

  // $phpgacl_location = "/var/www/gacl";

  // Tentatively, the following Access Control Objects will be supported.

  // These are the "things to be protected":

  //

  // Section "admin" (Administration):

  //   super       Superuser - can delete patients, encounters, issues

  //   calendar    Calendar Settings

  //   database    Database Reporting

  //   forms       Forms Administration

  //   practice    Practice Settings

  //   superbill   Superbill Codes Administration

  //   users       Users/Groups/Logs Administration

  //   batchcom    Batch Communication Tool

  //   language    Language Interface Tool     

  //

  // Section "acct" (Accounting):

  //   bill        Billing (write optional)

  //   eob         EOB Data Entry

  //   rep         Financial Reporting - my encounters

  //   rep_a       Financial Reporting - anything

  //

  // Section "patients" (Patient Information):

  //   appt        Appointments (write optional)

  //   demo        Demographics (write,addonly optional)

  //   med         Medical Records and History (write,addonly optional)

  //   trans       Transactions, e.g. referrals (write optional)

  //   docs        Documents (write,addonly optional)

  //   notes       Patient Notes (write,addonly optional)

  //

  // Section "encounters" (Encounter Information):

  //   auth        Authorize - my encounters

  //   auth_a      Authorize - any encounters

  //   coding      Coding - my encounters (write,wsome optional)

  //   coding_a    Coding - any encounters (write,wsome optional)

  //   notes       Notes - my encounters (write,addonly optional)

  //   notes_a     Notes - any encounters (write,addonly optional)

  //   date_a      Fix encounter dates - any encounters

  //   relaxed     Less-private information (write,addonly optional)

  //               (e.g. the Sports Fitness encounter form)

  //

  // Section "squads" applies to sports team use only:

  //   acos in this section define the user-specified list of squads

  if ($phpgacl_location) {

    include_once("$phpgacl_location/gacl.class.php");

    $gacl_object = new gacl();

  }

  // acl_check should return 0 if access is denied.  Otherwise it may

  // return anything that evaluates to true.  In addition if any of the

  // following types of access are applicable, then the corresponding value

  // must be returned if and only if such access is granted (ony one may

  // be specified):

  //

  // * write   - the user may add or modify the ACO

  // * wsome   - the user has limited add/modify access to the ACO

  // * addonly - the user may view and add but not modify entries

  //

  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);

    }

    // If no phpgacl, then apply the old static rules whereby "authorized"

    // users (providers) can do anything, and other users can do most things.

    // If you want custom access control but don’t want to mess with phpGACL,

    // then you could customize the code below instead.

    if ($section == ‘admin’ && $value == ‘super’) return 0;

                                                                                                                                 

    if ($_SESSION[‘userauthorized’]) return ‘write’;

    if ($section == ‘patients’) {

      if ($value == ‘med’) return 1;

      return ‘write’;

    }

    else if ($section == ‘encounters’) {

      if (strpos($value, ‘coding’ ) === 0) return ‘write’;

      if (strpos($value, ‘notes’  ) === 0) return ‘write’;

      if ($value == ‘relaxed’) return ‘write’;

    }

    else if ($section != ‘admin’) {

      return ‘write’;

    }

    return 0;

  }

  // Get the ACO name/value pairs for a designated section.  Each value

  // is an array (section_value, value, order_value, name, hidden).

  //

  function acl_get_section_acos($section) {

    global $phpgacl_location;

    if ($phpgacl_location) {

      include_once("$phpgacl_location/gacl_api.class.php");

      $gacl = new gacl_api();

      $arr1 = $gacl->get_objects($section, 1, ‘ACO’);

      $arr = array();

      foreach ($arr1[$section] as $value) {

        $odata = $gacl->get_object_data($gacl->get_object_id($section, $value, ‘ACO’), ‘ACO’);

        $arr[$value] = $odata[0];

      }

      return $arr;

    }

    return 0;

  }

  // Return an array keyed on squad ACO names.

  // This is only applicable for sports team use.

  //

  function acl_get_squads() {

    return acl_get_section_acos(‘squads’);

  }

  // Return an array keyed on encounter sensitivity level ACO names.

  // Sensitivities are useful when some encounter notes are not

  // medically sensitive (e.g. a physical fitness test), and/or if

  // some will be “for doctor’s eyes only” (e.g. STD treatment).

  //

  // When a non-blank sensitivity value exists in the new encounter

  // form, it names an additional ACO required for access to all forms

  // in the encounter.  If you want some encounters to be non-sensitive,

  // then you also need some default nonblank sensitivity for normal

  // encounters, as well as greater encounter notes permissions for

  // those allowed to view non-sensitive encounters.

  //

  function acl_get_sensitivities() {

    return acl_get_section_acos(‘sensitivities’);

  }

?>

[/code]

Sam Bowen

sunsetsystems wrote on Monday, May 18, 2009:

Sam, why do you think phpgacl is in use?  I don’t see how it can be if the $phpgacl_location line is commented out.  In that case there is default behavior for permissions, which is is probably not doing what you want.

Rod
www.sunsetsystems.com

bradymiller wrote on Monday, May 18, 2009:

hey,
That likely your explains permissions issues; php-gacl isn’t being used. On a optimistic note, that should make the upgrade easier :slight_smile:
-brady

drbowen wrote on Monday, May 18, 2009:

When I first started using phpGACL all of my users (except my original admin user) were locked out of large portions of the records.

I slowly built up the ARO definitions using GACL until I got the functionality I wanted. 

Whenever I add a new user to OpenEMR they are loacked out until I add them to a group using GACL.

I assign the front office staff to "front office".

I assign the back office staff to "clinicians" group.

Myself and the office manager are assigned to "administrators" group.

The current problem is being caused because my "front office" and "clinician" AROs can view but are not allowed to change the medications, issues, surgeries, allergies  which is causing a severe problem with our work flow.  The message that the non authorized users get is:

"Add is not authorized"

The "physicians" ARO group still behaves the same as it did before.

So, yes, GACL is working.

Sam Bowen

sunsetsystems wrote on Monday, May 18, 2009:

Well your question was, how do you turn off phpgacl.  You’re first going to have to find out where it’s turned on, because that’s not happening in the acl.inc that you presented.

Maybe this would help:

cd /var/www/openemr  (or whatever your openemr base directory is)
grep -r 'phpgacl_location = ’ *

Rod
www.sunsetsystems.com

sunsetsystems wrote on Monday, May 18, 2009:

An improved version of that search:

grep -r ‘^\s*$phpgacl_location\s*=’ *

Rod
www.sunsetsystems.com

drbowen wrote on Monday, May 18, 2009:

Thanks Rod,

grep -r ‘^\s*$phpgacl_location\s*=’ *

Returns an empty string.

Sam Bowen

drbowen wrote on Monday, May 18, 2009:

Perhaps I am a bit feeble minded and don’t understand, but if I could add and modify the ACL lists, ARO groups  and have the access change in the OpenEMR web pages as expected from my phpGACL changes how is it that phpGACL is not working?

from httpd.conf

Include /etc/apache2/modules.d/*.conf

# Virtual-host support
#
# Gentoo has made using virtual-hosts easy. In /etc/apache2/vhosts.d/ we
# include a default vhost (enabled by adding -D DEFAULT_VHOST to
# APACHE2_OPTS in /etc/conf.d/apache2).
Include /etc/apache2/vhosts.d/*.conf
Include /etc/apache2/gacl.conf

from gacl.conf

Alias /gacl /var/www/localhost/gacl/
   <Directory  "/var/www/localhost/gacl">
       AllowOverride None
       Options FollowSymLinks
       Order allow,deny
       Allow from 192.168.***.***
       Allow from 192.168.***.***
   </Directory>