Difference between revisions of "Bugs to fix when installing & upgrading"

From pmusers
Jump to: navigation, search
Line 1: Line 1:
Recent versions of ProcessMaker Community Edition have introduced a number of critical bugs, which can be fixed by editing the source code. Eventually these bugs will be fixed in future versions of ProcessMaker, but for now the only solution is to edit the ProcessMaker source code to fix them.
+
Recent versions of ProcessMaker Community Edition have introduced a number of critical bugs, which can be fixed by editing the source code. Eventually these bugs will be fixed in future versions of ProcessMaker, but for now the only solution is to edit the ProcessMaker source code to fix them. For now, we recommend installing version 3.2.1 Community Edition. If using version 3.2.1 is not possible, then follow the following instructions to manually fix the code to avoid these bugs.
 +
 
 +
An upcoming version of ProcessMaker which solves these problems should be ready in October or November of 2019, so it is recommended to not upgrade until that version is ready.  
  
 
'''''None of these problems exist in the Enterprise Edition, which receives a higher level of testing and quality assurance.'''''
 
'''''None of these problems exist in the Enterprise Edition, which receives a higher level of testing and quality assurance.'''''

Revision as of 21:56, 18 September 2019

Recent versions of ProcessMaker Community Edition have introduced a number of critical bugs, which can be fixed by editing the source code. Eventually these bugs will be fixed in future versions of ProcessMaker, but for now the only solution is to edit the ProcessMaker source code to fix them. For now, we recommend installing version 3.2.1 Community Edition. If using version 3.2.1 is not possible, then follow the following instructions to manually fix the code to avoid these bugs.

An upcoming version of ProcessMaker which solves these problems should be ready in October or November of 2019, so it is recommended to not upgrade until that version is ready.

None of these problems exist in the Enterprise Edition, which receives a higher level of testing and quality assurance.

When editing the ProcessMaker source code, use a plain text editor such as Notepad++ in Windows or vim, nano, gedit or geany in Linux.

The ProcessMaker source code is typically located in the following directory:

  • Linux Manual Install:
        /opt/processmaker/
  • Linux Bitnami Install:
        /opt/processmakerenterprise-3.X.X.b1-0/apps/processmaker/htdocs/
  • Windows Manual Install:
        C:\opt\processmaker\
  • Windows Bitnami Install:
        C:\Bitnami\processmaker-3.X.X-1\apps\processmaker\htdocs\

Datetimes in logs use the UTC time zone in 3.2.2+

Bug: TRI-3528 Laravel in PM 3.2.2 is overwriting the time_zone setting in the env.ini file

Forum: Re: Timezone issue after upgrade to PM 3.2.2


Version 3.2.2 and later use the Laravel framework, which introduced a problem with datetimes in the logs. Laravel overwrites the time zone configured in the php.ini file and/or ProcessMaker's env.ini file, and sets it to UTC.

This is isn't a problem in the Enterprise Edition because it automatically adjusts datetimes to the time zone of the user, but it introduces problems in the Community Edition, which doesn't have this adjustment for the user's time zone. Datetimes found under Admin > Logs will be in the UTC time zone.


To fix this problem, edit the config/app.php file and add the following line:

'timezone' => 'region/zone',

See this list of supported PHP time zones.

For example, the following file sets the time zone used in Melbourne, Australia:

<?php

use Illuminate\Cache\CacheServiceProvider;
use Illuminate\Filesystem\FilesystemServiceProvider;
use Illuminate\View\ViewServiceProvider;

return [
    'name' => env('APP_NAME', 'ProcessMaker'),
    'env' => env('APP_ENV', 'production'),
    'debug' => env('APP_DEBUG', false),
    'log' => env('APP_LOG', 'single'),
    'log_level' => env('APP_LOG_LEVEL', 'debug'),
    'cache_lifetime' => env('APP_CACHE_LIFETIME', 60),
    'timezone' => 'Australia/Melbourne',

    'providers' => [
        FilesystemServiceProvider::class,
        CacheServiceProvider::class,
        ViewServiceProvider::class,
    ],

    'aliases' => [
    ],

];

Home > Participated doesn't work in 3.2.2+

Bug: PMC-24: Can not open any cases under Home > Participated in 3.2.3 Community because code uses the LIST_PARTICIPATED_LAST table

Forum: Re: Upgrading Workspace (to 3.2.3) - Unable to Create Guest User


User who don't have the PM_ALLCASES permission in their role (such as users with the PROCESSMAKER_OPERATOR role) can't open cases which are listed under Home > Participated in version 3.2.2 and later. When they try to open a case, they will see the following error:

Notice: Undefined index: objectPermissions in /opt/processmaker/workflow/engine/methods/cases/cases_Resume.php on line 57
You cannot open this case because on the reason below:
You do not have permission to see this case.
You have not participated in this case.
Case is already claimed.

OperatorUsersCantOpenCasesInHome Participated.png

The problem is that the code queries the LIST_PARTICIPATED_LAST table in the database to determine if the user participated in the case, but this table is only populated by the Enterprise Edition, so it doesn't work in the Community Edition.

To fix this bug, edit workflow/engine/src/ProcessMaker/BusinessModel/Cases.php and change the definition of the userAuthorization() function (starting on line 3331) from:

    ) {
        $arrayAccess = [];

        //User has participated
        $participated = new ListParticipatedLast();
        $listParticipated = $participated->loadList($usrUid, [], null, $appUid);
        $arrayAccess['participated'] = (count($listParticipated) == 0) ? false : true;

To:

    ) {
        /*$arrayAccess = [];

        //User has participated
        $participated = new ListParticipatedLast();
        $listParticipated = $participated->loadList($usrUid, [], null, $appUid);
        $arrayAccess['participated'] = (count($listParticipated) == 0) ? false : true;
        */	
        $arrayAccess = [
            'rolesPermissions'  => [],
            'objectPermissions' => []
        ];

        if ($usrUid and $appUid) {
            $oCriteria = new \Criteria( 'workflow' );
            $oCriteria->add( \AppDelegationPeer::APP_UID, $appUid );
            $oCriteria->add( \AppDelegationPeer::USR_UID, $usrUid );
            $oDataset = \AppDelegationPeer::doSelectRS( $oCriteria );
            $oDataset->setFetchmode( \ResultSet::FETCHMODE_ASSOC );
            $oDataset->next();
            $aRow = $oDataset->getRow();
            
            $arrayAccess['participated'] = is_array($aRow) ? true : false;
        }
        else {
            $arrayAccess['participated'] = null;
        }

Then, edit the file workflow/engine/methods/cases/cases_Resume.php and change line 58 from:

if (!$aUserCanAccess['participated'] && !$aUserCanAccess['supervisor'] && !$aUserCanAccess['rolesPermissions']['PM_ALLCASES']) && !$aUserCanAccess['objectPermissions']['SUMMARY_FORM']) {

To:

//if (!$aUserCanAccess['participated'] && !$aUserCanAccess['supervisor'] && !$aUserCanAccess['rolesPermissions']['PM_ALLCASES']) && //!$aUserCanAccess['objectPermissions']['SUMMARY_FORM']) {

if (!$aUserCanAccess['participated'] && !$aUserCanAccess['supervisor'] && 
       (!key_exists('PM_ALLCASES', $aUserCanAccess['rolesPermissions']) || !$aUserCanAccess['rolesPermissions']['PM_ALLCASES']) && 
       (!key_exists('SUMMARY_FORM', $aUserCanAccess['objectPermissions']) || !$aUserCanAccess['objectPermissions']['SUMMARY_FORM'])) {

Warning: There is an additional problem that users who don't have the ALL_CASES permission in their role will see no documents listed under Home > Documents. This code change doesn't fix this problem.

Options in the Information menu don't work in 3.3.0+

Bug: TRI-3758: None of the options in the Information menu work and the "Reassign my cases" permission doesn't work in the Community Edition

Forum: Re: Upgrading Workspace (to 3.2.3) - Unable to Create Guest User


When a case is opened, none of the options under the Information menu work in ProcessMaker 3.3.0 and later, except for Process Information and Task Information.

To fix this problem, change the code in workflow/engine/src/ProcessMaker/BusinessModel/Cases.php, starting at line 3379, from:

        //Object Permissions
        if (count($objectPermissions) > 0) {
            $case = new ClassesCases();
            foreach ($objectPermissions as $key => $value) {
                $resPermission = $case->getAllObjectsFrom($proUid, $appUid, $tasUid, $usrUid, $value);
                if (isset($resPermission[$key])) {
                    $arrayAccess['objectPermissions'][$key] = $resPermission[$key];
                }
            }
        }

To:

        //Object Permissions
        $arrayAccess['objectPermissions'] = array();
        
        if (count($objectPermissions) > 0) {
            $case = new ClassesCases();
            foreach ($objectPermissions as $key => $value) {
                $resPermission = $case->getAllObjectsFrom($proUid, $appUid, $tasUid, $usrUid, $value);
                if (isset($resPermission[$key])) {
                    $arrayAccess['objectPermissions'][$key] = $resPermission[$key];
                }
                else {
                    $arrayAccess['objectPermissions'][$key] = array(); 
                }
            }
        }

The "Last Login" date for users is empty in 3.3.0+

Bug: TRI-3978: The users' "Last Login" date does not appear under Admin > Users > Users in the Community Edition

Forum: Re: Last login time don't update

The "Last Login" date is not recorded in the USERS table in the database, because the Community Edition doesn't have the \ProcessMaker\Model\Users class which is used to update the last login date in the Enterprise Edition.

To fix this problem, edit the file workflow/engine/methods/login/authentication.php and change line 307 from:

    if ($RBAC->singleSignOn) {        
        G::header('Location: ' . $sLocation);
        die();
    }

To:

    if ($RBAC->singleSignOn) {
        // Update the User's last login date:
        $u = new Users();
        $aUserProps = array(
           'USR_UID' => $aLog['USR_UID'],
           'USR_LAST_LOGIN' => $aLog['LOG_INIT_DATE']
        );
        $u->update($aUserProps);
        
        G::header('Location: ' . $sLocation);
        die();
    }

In the same file, change line 380 from:

    if ($activeSession){
        setcookie("PM-TabPrimary", 101010010, time() + (24 * 60 * 60), '/');
    }
    
    G::header('Location: ' . $sLocation);

To:

    if ($activeSession){
        setcookie("PM-TabPrimary", 101010010, time() + (24 * 60 * 60), '/');
    }
    
    // Update the User's last login date:
    $u = new Users();
    $aUserProps = array(
       'USR_UID' => $aLog['USR_UID'],
       'USR_LAST_LOGIN' => $aLog['LOG_INIT_DATE']
    );
    $u->update($aUserProps);

    $oPluginRegistry = PluginRegistry::loadSingleton();
    if ($oPluginRegistry->existsTrigger ( PM_AFTER_LOGIN )) {
        $oPluginRegistry->executeTriggers ( PM_AFTER_LOGIN , $_SESSION['USER_LOGGED'] );
    }

    G::header('Location: ' . $sLocation);

After making that code change, the "Last Login" date should appear:

LastLoginDateInUsersList.png