Case cannot be closed on the QueXS Operator's interface after being set as 'complete'. The case is fed through permanently.

Hi Thomas,

What version of queXS Is being used? If it is a 2.x version, what version of LimeSurvey is being used?

Also please let me know what version of PHP and Mysql.

Does this occur on all projects? Has it only started happening recently?

Adam

Hi Adam.

The missing information:
Version queXS: 1.16.2
Version PHP: 7.2.1.
Version MySQL: 10.1.30

The problem occurs only in one Questionnaire so far.
There are other questionnaires active at the same time, but no problem with these so far.
The problem started occasionally (not in evey case) in this specific questionnaire two days ago. But since yesterday in every case this problem occured.

BR

Thomas

Hi Thomas,

Is system wide case sorting enabled? If so please stop it and start it again.

There may also be some database inconsistency. Please try updating the call_attempt table to set an end date for all records that do not have an end date.

Adam

Hello Adam,

this is Markus (Erich), you may remember me, jumping in for Thomas during his fortnight of holidays we convinced him to have at last. ;-)

Answering your first question, I do see a button to enable and begin system wide case sorting. So I understand it is just stopped and I now will enable it (again, as I assume). 6 processes to run.

But now I’m totally confused. I heard (!) Avast virus shield giving an alert but I can not identify any machine to do so. Highly surprised I recognize it is the on which holds queXS. This computer may not have active speakers, but due a stupid test I got sound indeed.

So bad news is, Avast blocked «systemsortprocess.php» because ist is infected by IDP.Generic. Occurs simple question if Thomas ever had initiated this kind of sorting.
Of course, I can not accept this alert as real. I made an exception to Avast and will observe. But this is strange; false positive by new signatures..? (Ironically, my private machine does not scan my storage drive a same queXS is placed, so I did not get any alert. More bad, that machine is at home for me sitting in office. I shall inspect it back home.)

Is ist o.k. to look forward to effects of case sorting before trying second idea you sent?

I killed running process, assuming Avast to have done some sabotage and restarted it. Now I get 7 processes to run. Restart queXS, or as best machine it holds?

BR
Markus

Apologies or the delay Markus and Thomas,

I hope that restarting the system sort process has resolved this for you.

I do not usually run queXS on Windows so do not have the issue with virus scanners.

Adam

Hi Adam.

Sorry for my late answer.

We tried a couple of things.
As Markus described, we stopped and restarted the 'System wide case sorting'.
The original problem now occures not permanently, but occasionally. Before that the problem was permanently. It seems, the submit function is working for the first 2-3 cases to close them and get to the next case, and then it occurs again.

Furthermore I looked at the 'Call attampt' table, and the 'end' date is written in every case,
unless the case is currently open of course.

We have a lot of 'lime_old_surveys' in the DB.
Deleting these old Lime surveys might improve the server performance, but could it be a cause of the problem, too?

BR

Thomas

Thanks Thomas,

I don't think the old_surveys tables will be the cause of the problem. Deleting them will improve performance though so please go ahead and delete if safe to do so.

For a case that has this problem - can you please check if there is a difference in the case, call_attempt and call tables for that case id compared to a case that does not have the problem? That might help us discover the issue.

Adam

Hi Adam.

Thanks for your suggestion!

I compared two cases.
In one case, the problem did not occur. The interviewer was able to close the case as 'Complete' in the regular way by submitting.
In the other case, I just tried myself to close the case as complete, and the problem occured again.

Looking at the 3 tables you suggested, there is a difference between the two cases obviously.
In the 'case' table, I'm still logged as the current operator in the problem case. And still the initial current outcome 22 is logged (Appointment).
In 'call_attempt', no end-date is written in the problem case.
Though in 'call', there is no difference at all between the two cases. Both carry the outome 10 as 'complete'.

It seems like 'call' is up to date, but the 'case' and 'call_attempt' are not.

I'll send you the exports of the two cases by Email directly as an xlsx file.

I hope, this can lead us further to the cause of the problem :)

BR

Thomas

Thanks Thomas,

Can you please check under "Operators" then "Modify operator skills"

Please confirm that none of your operators have "Final outcomes" selected. If they do - they will be re-assigned completed cases.

Adam

Hi Adam.

Yes, none of the operator accounts have "Final Outcomes' selected (including my operator account, with which I produced that problem case).
They only have selected 'Temporarily outcomes' and 'Setting appointments'.

BR

Thomas