[Maldayne]

Hi all.

I had a user contact me about a case that they knew existed (13358), however they couldn't find it via advanced search either. I tried myself but also could not find it.

I checked the DB with the following MYSQL commands and results

Code: Select all

SELECT a.APP_UID, a.APP_NUMBER, a.APP_STATUS FROM APPLICATION a 
    WHERE a.APP_NUMBER = '13358'

Result : attached image1

Code: Select all

SELECT APP_STATUS, APP_UID FROM APPLICATION WHERE APP_UID="6716822795b6d797d2217c3001905728";

Result : attached image2

Code: Select all

SELECT a.APP_UID, a.DEL_INDEX, a.DEL_PREVIOUS, a.DEL_LAST_INDEX, a.PRO_UID, a.TAS_UID, a.USR_UID, a.DEL_TYPE, a.DEL_THREAD, a.DEL_THREAD_STATUS, a.DEL_FINISH_DATE FROM APP_DELEGATION a WHERE a.APP_UID="6716822795b6d797d2217c3001905728";

Result : attached image3

This case was a victim of a synchronous bug (mentioned in these forums) where it will make two tasks pop up instead of just one despite being synchronous (we are using Processmaker3.1.3 Community). I believe it is the same as the issue mentioned here :
viewtopic.php?t=710184
The system administrator has yet to upgrade to the new PM community edition due to some environment issues he is dealing with currently.

In any case we have gotten by with many cases despite this issue, but never has a case disappeared from the advanced search. While this case is technically completed, the users often refer back to these cases to review work done and documents uploaded. Is there a way to repair this case so that it shows again in advanced search?

If I use the 'Jump To' under the review case option I can jump into the case '13358' that I can't find under advanced search. The 'Jump To' can be used as a workaround, but I wish to find out why this case is not showing in advanced search despite existing.

Things I have noted or done:

• Checked that the user does indeed exist and is still active.
  • Set all tasks in the DB table APP_DELEGATION for the case as 'CLOSED' along with a none null finish date.
    • run the 'Cases List Cache Builder' and 'Clear Cache'.
      • have not attempted to reassign the supposed open case via the 'Jump To' workaround in case of issues it may cause.
        
        Any ideas/help would be appreciated as I would like to be better informed the next time an issue like this arises

[amosbatto]

I don 't know why the case isn't appearing under Advanced Search.
Can you do this database query:
SELECT * FROM APP_CACHE_VIEW WHERE APP_UID='XXXXXXXXXXXXXXXXXXXXX';
(where XXXXXXXXXXXXXXXXXXXXXX is the ID of the case)

And then paste the results as plain text (or as spreadsheet) so that I can see the data.
The only solution for the bug with duplicate cases in the case list with synchronous subprocesses is to upgrade.

[Maldayne]

Hi Amosbatto.

I apologies for the delay and thank you for the response.

I ran the query as requested :

Code: Select all

SELECT * FROM APP_CACHE_VIEW WHERE APP_UID='6716822795b6d797d2217c3001905728'

And I have attached to csv's to this reply. One for excel viewing and one plain text.

I don't see anything particularly odd here myself other than the 'OPEN' task.

[amosbatto]

I wonder if the duplicate task (DEL_INDEX of 19 and 20) is causing a problem, because the case is still listed in the APP_DELAY table.
Can you check if there is an entry for this case in the APP_DELAY table? If so, post its record.

You are going to have to upgrade to solve the problem with duplicate subprocess cases, but I don't recommend upgrading beyond version 3.2.1:
https://www.pmusers.com/index.php/Bugs_ ... _upgrading

[Maldayne]

I ran the following code after taking a look at the APP_DELAY table

Code: Select all

SELECT * FROM APP_DELAY WHERE APP_UID='6716822795b6d797d2217c3001905728'

unfortunately no entries where found.

Thank you for the upgrade recommendation Amosbatto.
Our intention is to upgrade as I have seen on these forums that it would solve the duplicate subprocess cases issue, and we have also noted the issues beyond 3.2.1 mentioned by you in other forum comments. Having it verified here makes us more confident of the changes.

[Maldayne]

Something odd has happened, a user has noted the task has suddenly become searchable through the user interface again. I am unsure as to what may have bumped it but have sent an email to ask the users if they had done anything that may have caused this. I feel this is an artifact of the subprocess duplicate bug.

best solution I feel would be to have the users complete the case with the preexisting data once I have received their response on the email.

[richvle]

Hi Maldayne. Did you ever figure out the cause/solution for this? I am in the middle of troubleshooting it as well right now.

Something odd has happened, a user has noted the task has suddenly become searchable through the user interface again. I am unsure as to what may have bumped it but have sent an email to ask the users if they had done anything that may have caused this. I feel this is an artifact of the subprocess duplicate bug.

best solution I feel would be to have the users complete the case with the preexisting data once I have received their response on the email.

[Maldayne]

Hi Maldayne. Did you ever figure out the cause/solution for this? I am in the middle of troubleshooting it as well right now.

Something odd has happened, a user has noted the task has suddenly become searchable through the user interface again. I am unsure as to what may have bumped it but have sent an email to ask the users if they had done anything that may have caused this. I feel this is an artifact of the subprocess duplicate bug.

best solution I feel would be to have the users complete the case with the preexisting data once I have received their response on the email.

Hi,
unfortunately I never found the cause or solution to this and it has not occurred again so I can't even investigate the issue further on my side.

All of the users involved said they didn't do anything that they can remember on their sides which I find quite odd. My closest guess (though unlikely as I should have found it) is perhaps there was a part of the sub-process that was stalled somewhere and a user happened to find it and complete it. Perhaps see if there are any threads that are lying by users that are not being processed and follow the data from there?

Sorry I can't be of more help.