We’ve confirmed all three issues.
Buddy list emptied after the upgrade
On domains that don’t use automatic buddy-list syncing, the 26.5 database upgrade removes contacts between users on the same domain unless they were filed in a named group. This happens once, during the upgrade, which is why the contacts you re-added have stayed. It isn’t fixed in a released build yet.
Before upgrading production, stop MDaemon and make a copy of XMPPServer\xmppdb.db. Turning on “Enable buddy list syncing” before upgrading avoids the empty lists, but it doesn’t keep your users’ own contacts. With syncing on, every user sees all IM users in the domain. If you later turn syncing off, the lists will be empty. Only use it if a list of the whole domain is what you want.
Restoring the contacts (on your test server now, or on production after upgrading). The upgrade saved a copy of the database first, so the contacts can be put back:
- Download the SQLite command-line tools for Windows (“sqlite-tools-win-x64”) from https://sqlite.org/download.html and extract
sqlite3.exe, for example to C:\Temp.
- In
XMPPServer\backups (default C:\MDaemon\XMPPServer\backups), find the file named xmppdb-preschema<n>-<date>-<time>.bak from the day you upgraded. Please don’t copy this file over the live database: the upgrade step would run again and remove the contacts again.
- In Windows Services, stop MDaemon XMPP Server. Mail keeps running; instant messaging is unavailable until step 7.
- Make a safety copy of
XMPPServer\xmppdb.db, plus xmppdb.db-wal and xmppdb.db-shm if they exist.
- Save the script below as C:\Temp\restore.sql, and change the path on the
ATTACH line to your backup file.
- From a command prompt, run:
C:\Temp\sqlite3.exe "C:\MDaemon\XMPPServer\xmppdb.db" < C:\Temp\restore.sql
It prints how many contacts it’s restoring, then restores them. It’s safe to run again; a second run adds nothing.
- Start MDaemon XMPP Server again. Users see their contacts the next time MDaemon Instant Messenger signs in.
ATTACH DATABASE 'C:\MDaemon\XMPPServer\backups\xmppdb-preschema3-YYYYMMDD-HHMMSS.bak' AS bak;
SELECT COUNT(*) AS contacts_to_restore
FROM bak.RosterList r
JOIN bak.Users bu1 ON bu1.UserID = r.UserID
JOIN bak.Users bu2 ON bu2.UserID = r.RosterUserID
JOIN main.Users lu1 ON lu1.Email = bu1.Email
JOIN main.Users lu2 ON lu2.Email = bu2.Email
WHERE LOWER(SUBSTR(bu1.Email, INSTR(bu1.Email, '@') + 1)) = LOWER(SUBSTR(bu2.Email, INSTR(bu2.Email, '@') + 1))
AND r.SubscribeStatus = 'both'
AND r.RosterListID NOT IN (SELECT RosterListID FROM bak.RosterGroupList)
AND NOT EXISTS (SELECT 1 FROM main.RosterList m WHERE m.UserID = lu1.UserID AND m.RosterUserID = lu2.UserID);
BEGIN;
INSERT OR IGNORE INTO main.RosterList (UserID, RosterUserID, SubscribeStatus, AskStatus)
SELECT lu1.UserID, lu2.UserID, r.SubscribeStatus, r.AskStatus
FROM bak.RosterList r
JOIN bak.Users bu1 ON bu1.UserID = r.UserID
JOIN bak.Users bu2 ON bu2.UserID = r.RosterUserID
JOIN main.Users lu1 ON lu1.Email = bu1.Email
JOIN main.Users lu2 ON lu2.Email = bu2.Email
WHERE LOWER(SUBSTR(bu1.Email, INSTR(bu1.Email, '@') + 1)) = LOWER(SUBSTR(bu2.Email, INSTR(bu2.Email, '@') + 1))
AND r.SubscribeStatus = 'both'
AND r.RosterListID NOT IN (SELECT RosterListID FROM bak.RosterGroupList);
COMMIT;
DETACH DATABASE bak;
What to expect from the restore:
- Contacts removed on purpose since the upgrade come back. If someone deliberately removed a contact after upgrading, the restore can’t tell that apart from the upgrade’s removal, so that contact reappears and has to be removed again.
- Contacts re-added since the upgrade are kept as they are, with no duplicates.
- Accounts deleted since the upgrade are skipped, and accounts created since aren’t affected.
- Only contact lists change. The script adds the missing contacts back into the current database instead of replacing it. Chat history, chat rooms and anything else changed since the upgrade are kept.
- Restored contacts come back as approved contacts on both sides, as they were before the upgrade.
- Instant messaging is unavailable while the XMPP service is stopped, usually a few minutes. Users may need to sign back in to MDaemon Instant Messenger.
- To undo the restore, stop the XMPP service again and put back the safety copy from step 4.
We recommend running the restore on your test server first and checking a few users’ lists before doing production.
Popups for the room’s history when joining a room
This is a known issue in MDaemon Instant Messenger. A bug has been logged for the development team to review.
Leaving a room shows a join and lists the user twice
We reproduced this and logged it as a server bug. It also happens when a user’s connection drops. It’s cosmetic: the extra entry disappears when that user next leaves the room, or when the room window is closed and reopened.
English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
