Connect Chat Error

[kclark1]

Hi guys - we've hit a weird issue:

In Dev we have a working instance of Connect Chat.   It had previously been migrated to test, but we decided to roll back use of the module until we were were comfortable with the functionality.     WE had basically set up a Chat button on Service Portal which would launch a connect chat window for a specific Chat Queue.   We turned off this widget in the meantime.

We subsequently made some changes in DEV chat_queue records (modified some names and relationships to Assignment groups - nothing which should ostensibly affect the Connect module - and then migrated the new groups and the updated Widget back to TEST.

We now find that we get odd behaviour and can't launch the queue chat.   When we trigger a chat with the queue from a user, we see the badge and "Accept" button appear for the Operator:

When the Operator clicks the Accept button, nothing happens - however in the back-end we can see that the chat_queue_entry record is being set to "Accepted" and assigned to the correct user.   For some reason though, the operator doesn't see the chat window appear on their screen.

When the Operator clicks for a second time on the Accept button, they see the following error message "the queue is currently empty":

.

We see the same behaviour when we go to the direct chat link for ANY of the chat_queue records we have in the system.

When we look at the browser Console we see a 404 error on the Connect API itself once the second click has happened (likely because the queue has been addressed):

Any thoughts?   This has us scratching our head.

[kclark1]

OK an update on this one:

We found that the behaviour was only present when we had non-admin operators executing the activities - as soon as we had admin user to admin user, the behaviour didn't occur, which indicated that it was likely a role issue.

We looked at the snc_internal role and compared its ACL relationships to DEV and discovered a discrepancy of about 300 relationships, including $chat_support, chat_queue_entry and chat_queue_entry.comments.

Introducing these ACL relationships to the snc_internal role seems to have resolved the problem.   Not entirely sure what might cause the snc_internal ACL relationships to have been left out of our TEST instance - we would have activated the Connect Plugin and migrated update sets between instances, but that seems to have resolved the problem.

Anyone have any insights into where the snc_internal chat_queue_entry ACL relationships come from so we can better understand the root cause here?

[yogesh15dd]

Hi Kevin,

I have the same issue, for me it occurs even if i log in as an admin,   which ACL's we have to modify you meant?

Thanks

Yogish Dafedar

[antonyx]

Hi Yogesh,

May I know in which version reported issue is occurring?

As far as I'm aware there is a known problem "PRB856028 - Accept button remains enabled even when end user terminates the Chat session and clicking on Accept button throws a 'The queue is currently empty' message for the support agent".

This problem has been fixed in Helsinki Patch 3 onwards. If you are on latest, release, still encountering the same issue, I would recommend opening a HI ticket.

Hope this is helpful.

Cheers,

Antony

[yogesh15dd]

Hi Antony,

I'm using kingston version.

I will open a HI ticket, thank you for providing me the problem ticket id.

Regards

Yogish Dafedar