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:
In a private chat opened from a MUC room the conversation is between:
When chat history is saved from either kind of private chat the BareJID is used, which means the history is saved as
firstname.lastname@example.org for a normal private chat (correct) but is saved as
email@example.com 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
firstname.lastname@example.org or any other conversation spawned from that MUC room they see all history for any chat that involved
email@example.com… 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
firstname.lastname@example.org/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.