powered by Jive Software

MUC does not send affiliation changes to occupants


has anybody else experienced this?

I have a room with X members. Every member has affiliation “owner”. Because every member should have the possibility to remove itself from the room (besides enjoying other “owner” privileges).

When an owner removes himself from a room he does so by revoking membership for himself as described in http://xmpp.org/extensions/xep-0045.html#revokemember

This works fine, but the occupants don’t get any notification about it.

(as shown in Example 127 and 128).

I’ve debugged with Smack debugger and also set breakpoint in the void membershipRevoked(String participant) method, but nothing is sent/received.

A bug?

I’ve debugged Openfire and saw this:

LocalMUCRoom#changeOccupantAffiliation is called with newAffiliation=“none” and newRole=“none”

Then first the affiliation is updated.

Then the role is updated, which throws a NotAllowedException:

// A moderator cannot be kicked from a room

if (MUCRole.Role.moderator == role && MUCRole.Role.none == newRole) {

throw new NotAllowedException();


So I think there are two issues here:

First, the order should be changed: First update the role, then the affiliation. (This order is actually done in #occupantUpdated)

Second, the setRole() should check if the current affiliation is “owner” or “admin”, because he is allowed to kick moderators.


“moderator” to “none”: Exit room or be kicked by an admin or owner

To you have any opinions/concerns about this change? If not, I’d like to apply it.

Do you know, if there is anything to be considered for the cluster task?

CacheFactory.doClusterTask(new UpdateOccupant(this, role));

It seems my problem is related to or even duplicated by OF-241.

There’s even another related issue (OF-747).

After debugging some code I realized that the “actor” is not really checked, when updating the role/affiliation of an occupant. Instead the previous affiliation/role of the occupant is checked, which might throw an NotAllowedException (commented with “this should never happen… in theory…”, lol) and also commented with some TODOs to check the actor’s affiliation/role.

I’ve committed a suggested fix (which is still commented out).

Can somebody review it? I fear it could break something…

https://github.com/igniterealtime/Openfire/commit/7e6a1bf5c4df77a598cf06631b061a 095ccf832a

I’d like to move forward then and fix my problem (and probably then also OF-241 and OF-747)