Hi there,
We are running Openfire 4.7.1 (linux) and Spark 2.9.4 (windows).
As mentioned in Wrong chat history in group chat (SPARK-2223) history in MUC rooms/private chats is broken.
This is down to the way JIDs for MUC private chats are handled.
In a private chat opened from the contact list (roster) the conversation is between:
user1@example.net and user2@example.net
In a private chat opened from a MUC room the conversation is between:
chat_room@example.net/user1 and chat_room@example.net/user2
When chat history is saved from either kind of private chat the BareJID is used, which means the history is saved as user2@example.net for a normal private chat (correct) but is saved as chat_room@example.net from a MUC private chat. This is incorrect behaviour as this is the JID of the MUC room, not the private conversation.
The effect of this is that any time either user1 or user2 opens chat_room@example.net or any other conversation spawned from that MUC room they see all history for any chat that involved chat_room@example.net… This leads to a very messy history indeed.
My initial thought was to save the history with the full JID instead, however this then breaks normal private chat history because the history gets saved with the /resource (eg user1@example.net/user1-PC) and will never get loaded again because at the point of loading the history the /resource isn’t known.
I believe the solution is for the getParticipantJID() function in ChatRoomImpl to return an EntityJid rather than an EntityBareJid. The function should determine whether it is a MUC private chat (already doable with the privatechat boolean variable) and return participantJID (which is an EntityJid) for a MUC private chat or participantJID.asEntityBareJid() for a normal private chat.
This, however, has deep knock-on effects across the codebase which I believe actually may highlight other bugs. For example, all presence queries are done on a bare JID. I don’t see how that can work for getting the presence of members of a MUC private chat? This can actually be demonstrated in live code by opening a private chat from a MUC room. The user’s presence will always be ‘online’, regardless of their actual status. This can be seen in the image below (notice that Daniel is away in the MUC but online in the private chat).
I am going to make the change to getParticipantJID() and make the code compile without making any other significant changes - Anywhere that uses getParticipantJID() I will change to use getParticipantJID().asEntityBareJid() and mark them all with a //BUG: MUC Issue comment. I will then attempt to perform a PR (not done one before, so fingers crossed).
These changes will be made against the 2.9.4 codebase as this is the version we are running. So any backporting/forwardporting will need to be done by someone else.
Thanks,
Alex 2