Bug - Repeatedly transferring a chat between workgroups

Openfire Openfire Support
1

Hi,

I have found a couple of bugs relating to agent session transfer. The scenario is as follows:

  1. There are 3 agents, each in different workgroups (workgroup1, workgroup2 and workgroup3)

  2. Agent 1 receives a customer chat.

  3. Agent 1 initiates a transfer to Agent 2, which works fine

  4. Agent 2 then tries to transfer the chat session onto Agent 3. This fails.

I have managed to create a patch which fixes this problem. There are actually 2 problems, one of which is in the Smack API, and one in the fastpath plugin.

Firstly, in org.jivesoftware.smackx.workgroup.packet.RoomTransfer, the JID of the originating workgroup (workgroup 1 in this example) should be set as an attribute within the element of the message. There is already code in the constructor of org.jivesoftware.xmpp.workgroup.request.TransferRequest to look for this attribute. There is also a comment which correctly states that if the workgroup attribute is missing then the transfer will only work if the workgroup that received the transfer request is the same as the workgroup that received the original customer chat request.

Because of this change, the sendRoomTransfer method in org.jivesoftware.smackx.workgroup.agent.AgentSession now requires an additional workgroup parameter, which is then passed through to RoomTransfer.

Secondly, the constructor of org.jivesoftware.xmpp.workgroup.request.TransferRequest must replace the workgroup field if the user request originated from a different workgroup. Without this change, the transferring agent does not get kicked from the room when the new agent accepts the request.

I have attached a patch with these changes, which hopefully can be incorporated. I have tested these changes based on Openfire 3.6.4 and Smack 3.1.0.

FYI, I am currently working at Sword Ciboodle - my colleague Stuart Chalmers has recently contributed a patch for a different bug.

Cheers,

Neil
smack_transfer_patch.zip (1338 Bytes)
openfire_transfer_patch.zip (495 Bytes)

2

I’ve just realised the change to AgentSession involves a change to the API. The sendRoomTransfer method could be overloaded to keep the existing signature, and this could then pass in null for the workgroup to a new sendRoomTransfer method with the extra parameter.

Cheers,

Neil

3

Can you split this patch in 2 parts for Openfire and Smack, so i can file two tickets and attache the patches? I see two diffs and one java file inside the zip. What is what? And why java file is in there?

4

I have now made 2 separate patch files, one for Smack and one for Openfire (or really the Fastpath plugin). You can ignore the java file from the original patch, I added the wrong file to the zip

Thanks,

Neil

5

Filed as OF-413, SMACK-326.

6

Many thanks!

7

Daryl says something is wrong with the Openfire patch. You can read his comment in the ticket.

8

I have reattached the diffs to the discussion, generated with the -u flag as requested. Could you reattach these to the bug tickets?

The patch was generated based on Openfire 3.6.4 and Smack 3.1.0, rather than the latest. I do have a checkout of the latest code, so if these new diffs aren’t suitable please let me know and I can reapply my changes to the files from the latest code.

9

Thanks Neil. Please keep those patches coming

10

I can see the OF patch was applied, but the SMACK one wasn’t.

I’m having an issue, I suppose maybe related to this, that I’ve commented here

Could you please explain if there is some reason why the patch shouldn’t be applied?

I’ve applied it myself to my local copy and re-built spark with the patched smack library but it doesn’t solve my problem, as it happens even before the first transfer is possible.

11

we will take a look into this. http://issues.igniterealtime.org/browse/SPARK-1339