Are you sure you are talking fastpath webchat? it uses anonymous logins. if not you need your own thread as this is dealing with fastpath and fastpath webchat. You will confuse the issue. If you are only using spark or xmpp clients then you are not actually using fastpath. You are using MUC or group chat by connecting to a workgroup directly. Some of the fastpath features will work but it is not the same by any stretch.
It is not the web chat, but it is fastpath. It is configured via the fastpath plugin’s tab. It uses the workgroup service. The chats are initiated by sending a message to the workgroup (jid is @workgroup.), at which point the workgroup robot asks if you want to join the queue. If there are any questions in the “form ui” configuration, then the bot asks you those questions. At the end of the questions, you’re told your position in the queue. When it’s time for you to be connected to a workgroup agent, the agent is notified via toaster-style notification in the lower-right corner. The MUC is created and then the requestor is asked if he wants to join the chat. The agent is shown a UI that is not like a normal MUC session that includes a notes section and a “end session” button. After the chat is over and if it is so configured, the requestor is asked by the bot if he would like to receive a transcript of the chat by email. Also, the chat transcript is stored in the database and can be retrieved via the fastpath tab of the admin console.
Like I said you are using parts of fastpath, but not the whole thing. You are confusing the issue. True fastpath is via a web interface, and requires anonymous logins allowed. What you are doing is not part of the intended design.
I don’t think I’m confusing the issue. The problem about which I was talking (regarding the username variable bug) affects both web and XMPP interfaces. I thought I was offering some useful advice.
If its intended design was a web interface, then what is the point of the XMPP bot?
I am really not going to debate this further. This thread has been hyjacked from the original issue. No fastpath was not intended for spark to spark calls. The XMPP bot is for transfers to other agents or to pull other agents into a fastpath chat. The intended use for fastpath is to allow anonymous users to have a live helpdesk style chat with a designated workgroup of agents. Why do yoou think there are all the other parameters in the plugin for the web interface. You may of course use it however you like, but any issue you have could be from improper use, and there would be no way to prove otherwise. If you look back at the original question it is clear the individual is trying to use the fastpath webchat plugin not a client application. That is why I sadi you are confusing the issue.
Todd, thank you for your recomendation.
I solved my problem following your instructions plus a little luck I think.
My problem was lying on the sefl generated certificates (I don’t know exactly why).
Here we have the main domain which has it’s own certificates, and the openfire server was located on another domain. After reviewing all the points you mentioned a couple of issues start to happen.
I ask the network admon to relocate the openfire server, and (sorry to say this) after reinstalling (luckly I have my backup ready) it works just as the guide said.
Thanks a lot.
Max.
Glad to hear it. Could you mark this thread as closed then and award points as you see fit.