Repeatedly transferring a chat between workgroups in Fastpath
Description
There is a bug in Fastpath plugin for Openfire (also a related one in Smack).
from the thread:
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 <session> element of the <transfer> 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.
There is a bug in Fastpath plugin for Openfire (also a related one in Smack).
from the thread:
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 <session> element of the <transfer> 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.