[jezmathers]

I am upgrading to 3.2.3 and received an error during the workspace upgrade:

Errors upgrading workspace workflow: Can not create guest user: Unable to execute INSERT statement. [wrapped: Could not execute update [Native Error: Duplicate entry '00000000000000000000000000000002-0000000000000000000000000000000' for key 'PRIMARY'] [User Info: INSERT INTO RBAC_USERS_ROLES (`USR_UID`,`ROL_UID`) VALUES ('00000000000000000000000000000002','00000000000000000000000000000005')]]

The upgrade is attempting to add a "guest" user with a USR_UID of '00000000000000000000000000000002', however in my installation I already have a User with this UID (on a previous version I had an issue where I could not add new users and was forced to add several users "manually" and I used this UID).

Is the absence of this new "guest" user going to cause me problems or create issues for my regular user with the same UID?

What should I do?

[amosbatto]

The "guest" user is used in version 3.2.2 and later by Web Entry when an anonymous user will start new cases. See:
https://wiki.processmaker.com/3.2/Web_Entry

I imagine that you will have a conflict if you select the "Anonymous" option when defining a new web entry. Probably the best solution is to do a search and replace in your database to change the user's ID. Change 00000000000000000000000000000002 to another number in all the USR_UID fields in the database. Then, run the "processmaker upgrade" command again.

[jezmathers]

I have "replaced" all instances of the USR_ID (and APP_INIT_USER & APP_CUR_USER) in wf_workflow and was able to successfully complete the workspace upgrade (creating the "guest" user).

All is good with the user (meaning they can login, start new cases, open existing cases, etc.) except, if they try to open a case from Participated, they receive the error:

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

However, if they go to "Information" they can then access all the information associated with the case that they have permissions to (Case History, Dynaforms, Generated Documents etc.).

Seems like they is another table/field that needs to be updated, but I cant find it?!

[amosbatto]

You probably didn't change the user's UID in the process permissions. Check the OBJECT_PERMISSIONS.USR_UID field. If your user is a member of a group, then you will need to change GROUP_USER.USR_UID. That would effect process permissions if you assigned the user by a group.

Also if the user was assigned to cases with subprocesses, change the USR_UID in the SUBAPPLICATION table.

PS: I filed a bug report about the misspelled words in the text message.

[jezmathers]

I do have OBJECT_PERMISSIONS.USR_UID updated. However after further testing it appears that non of my "Operator" users can now open cases from "participated". FYI, if I change the user from an "Operator" to a "Supervisor", they can view cases from Participated.

To ensure I did not make any mistakes in the upgrade process, I rolled back my test environment to 3.2.1. I changed the users UID (that was conflicting with the new Guest user in the 3.2.2 upgrade) and tested their login. They are able to open cases from Participated without any error/problem. I then ran the upgrade (to 3.2.2), but now cannot open cases from Participated (nor can any other OPERATOR user). I am also receiving the following error message:

Notice: Undefined index: objectPermissions in /opt/processmaker/workflow/engine/methods/cases/cases_Resume.php on line 57

[amosbatto]

The problem is not caused by your upgrade to version 3.2.3. I did some testing and found that this is a bug in version 3.2.3 Community.

I did a clean install of ProcessMaker 3.2.3 Community (in Debian 9.5, PHP 5.6.37, MySQL 5.7.23) and I am able to reproduce the error when an Operator user tries to open a case listed under Home > Participated:

OperatorUsersCantOpenCasesInHome_Participated.png (87.72 KiB) Viewed 17039 times

The problem is that the code queries the LIST_PARTICIPATED_LAST table 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 3323) from:

Code: Select all

    public function userAuthorization(
        $usrUid,
        $proUid,
        $appUid,
        $rolesPermissions = [],
        $objectPermissions = [],
        $objectSupervisor = false
    ) {
		
        $arrayAccess = [];

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

To:

Code: Select all

    public function userAuthorization(
        $usrUid,
        $proUid,
        $appUid,
        $rolesPermissions = [],
        $objectPermissions = [],
        $objectSupervisor = false
    ) {
		
        $arrayAccess = [
            'rolesPermissions'  => [],
            'objectPermissions' => []
        ];

        //User has participated
        /*
        $participated = new ListParticipatedLast();
        $listParticipated = $participated->loadList($usrUid, [], null, $appUid);
        $arrayAccess['participated'] = (count($listParticipated) == 0) ? false : true;
        */
        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 workflow/engine/methods/cases/cases_Resume.php and change line 57 from:

Code: Select all

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

To:

Code: Select all

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'])) {

Now, it should work correctly in both the Community and Enterprise Editions. I filed a bug report about this, so hopefully this bug fix will be applied in version 3.3.

[amosbatto]

I filed a bug report about this at:
https://processmaker.atlassian.net/browse/TRI-3658

[jezmathers]

Amos, sorry to have to "re-open" the issue concerning the LIST_PARTICIPATED_LAST bug in the Community edition, however I have just upgrading to v3.3.3 (the bug you reported is not fixed in this edition) and your "work-around" fix to edit the Cases.php and cases_Resume.php is no longer (Fully) working!

The work-around does still take care of the error:

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

However, in the latest version, I can no longer open any of the "case Information" Links (such as "Case History" or "Generated Documents") if the user is designated as an "Operator". Users that are "Process Supervisors" can open the information links.

Any new help would be greatly appreciated! Thanks!

[amosbatto]

jezmathers,
If you apply this code fix in the file workflow/engine/methods/cases/ajaxListener.php:
viewtopic.php?f=44&t=736316&p=822667#p822667

Does it fix the problem?

[jezmathers]

Thank you for your help, unfortunately that did not fix my issue.

[amosbatto]

OK, I haven't installed PM 3.3.3 yet. Let me install it and see if I can figure it out.

The community edition is getting less testing before release.

[jezmathers]

Amos, FYI I rolled back by my install to v 3.2.3 and confirmed your bug fixed was working in that version. I then upgraded to v3.3.0 and your bug fix no longer works. The error message does go away, but cannot open any of the case information, therefore no need to upgrade to v3.3.3 if you have a v3.3.0 available....

[amosbatto]

Hi jezmathers,
I made the code change in PM 3.3.3 Community and I no longer see the problem when I go to Home > Participated. The code hasn't changed since version 3.2.3.

Can you tell me anything else about what you did?

[jezmathers]

Hi,

Just to confirm I did not make a mistake, I took my 3.2.3 version (that is working after I applied your code fix), and upgraded to v3.3.3. I then re-applied your fix to Cases.php and cases_Resume.php, and although the I do not get the error message when accessing a Participated task (for an OPERATOR user), the only link that works under "Information" is "Process Information" and "Task Information". All the other links ("Process Map", "Case History", "Message History", etc.) do not work (links appears like they should work - the menu item highlights - but when selected there is no action or error message). If I login as a SUPERISOR user I can open all the links to a Participate task.

Any other suggestions?! Thanks!

[amosbatto]

Hi Jezmathers,
I misread your post. Yes, I see the problem with the Information menu in 3.3.3. I recommend that you stay with version 3.2.3 and don't upgrade for now. None of the bugs in the Community Edition are getting fixed right now, which is why my bug fix wasn't applied.

[amosbatto]

jezmathers ,
I figured out how to fix the problem with the options in the Information menu in version 3.3.0 and later. The introduction of the new "Reassign my cases" permission broke the options in the Information menu.

The Information menu options try to verify the session in workflow/engine/methods/cases/ajaxListener.php:43 with this code:

Code: Select all

$userAuthorization = $cases->userAuthorization(
                $RBAC->aUserInfo['USER_INFO']['USR_UID'],
                $proUid,
                $appUid,
                ['PM_REASSIGNCASE', 'PM_REASSIGNCASE_SUPERVISOR'],
                ['REASSIGN_MY_CASES' => ''],
                true,
                $tasUid
            );

The problem is that ProcessMaker isn't consulting REASSIGN_MY_CASES correctly in the database.

You can get the Information menu to work by changing workflow/src/ProcessMaker/BusinessModel/Cases.php: 3411 from:

Code: Select all

        //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:

Code: Select all

        //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(); 
                }
            }
        }

However, the real problem is that Cases::getAllObjectsFrom() calls ObjectPermission::verifyObjectPermissionPerUser() and ObjectPermission::verifyObjectPermissionPerGroup() which both search for "REASSIGN_MY_CASES" in the OBJECT_PERMISSION.OP_ACTION field in the database, but "REASSIGN_MY_CASES" is stored in the OBJECT_PERMISSION.OP_OBJ_TYPE field in the database when a "Reassign my cases" permission is created.

Because ProcessMaker isn't looking "REASSIGN_MY_CASES" correctly in the database, the "Reassign my cases" permission also doesn't work correctly. I don't have an easy fix for that permission.

I filed a bug report about this: https://processmaker.atlassian.net/browse/TRI-3758

I talked to the developers and they tell me that these bugs will get fixed, so you might want to wait to upgrade.

[Skipper]

Hello,

I still have the same Problem.
I installed the BugFix and for the permission error on the case page when a user is using using a case link didn't appear anymore.
But my custom summary form can't be displayed. It still throws the error "Undefined index: SUMMARY_FORM in /opt/processmaker/workflow/engine/methods/cases/cases_Resume.php on line 45"

When I watch the Case Summary it says "You do not have permission to access to the summary form".

After that I print out the Array of $aUserCanAccess and the Subarray of $objectPermissions is empty.

So what can I do?

The User has the Permission to view the summary form. I tried it also with a form which the user can view by click on information and Dynaforms.

The Problem still exists in the Case Summary with a PM-Admin User.

Can you help me?

Kind regards
Timo