Issue with MUC Admin Role Not Persisting After Restart (Openfire 5.0.2)

Openfire
1

We recently upgraded our Openfire deployment to version 5.0.2, and we have observed a critical issue related to MUC affiliation persistence.

Issue Summary

When we change a user’s role in a group chat from member → admin, the role is applied correctly and works as expected until the Openfire service is restarted.
However, after restarting Openfire, all admin roles disappear.

What we verified

  • The admin affiliation does not get written into the ofMucAffiliation table.

  • Roles such as owner (10) and outcast (40) do persist correctly.

  • The issue appears to affect only admin (20) affiliation.

  • The admin role seems to exist only in memory, because the Openfire REST API returns the correct admin affiliation before restarting the service.

What we need help with

  • Is this a known issue in Openfire 5.0.2?

  • Is the admin affiliation supposed to be persisted in the ofMucAffiliation table?

  • If yes, what could prevent admin entries from being saved?

  • Are there any configuration flags, caches, plugins, or patches that affect persistence of admin roles?

  • What is the recommended fix or workaround to ensure that admin roles persist after restart?

This issue is impacting us significantly as we manage a very large number of group chats, each having one or more admins. A restart wipes all MUC admin roles.

Any guidance or solution would be greatly appreciated.

2

I can confirm this issue. On a clean installation of Openfire 5.1.0-alpha, owner and outcast affiliations persist correctly, but admin affiliations are never written to ofMucAffiliation, and therefore disappear after a restart. This aligns with your observations on 5.0.2.

Members are not stored in ofMucAffiliation by design, but admins should be, so the absence of admin entries strongly suggests a persistence bug in the MUC affiliation handling code.

I’ve opened a ticket to track this problem: OF-3148.

3

This issue occurs because the in-memory affiliation is updated before the previous (“old”) affiliation is evaluated. As a result, the persistence logic incorrectly assumes an UPDATE should be executed instead of an INSERT. Since no existing row matches, the UPDATE affects zero rows and the new admin affiliation is never written to ofMucAffiliation.

A temporary work-around is to assign any other persistent affiliation first (e.g., owner or outcast), allow it to persist, and then change the user’s affiliation to admin. Because a row now exists in ofMucAffiliation, the second change is correctly saved as an update and will survive restarts.

4

Thanks @guus for the temporary workaround for this issue.

5

This problem has been fixed in Openfire 5.0.3.