powered by Jive Software

Roster changes on Shared group deletion

Wildfire 2.4.4

On deletion of a shared group the subscription status of every user in that group is checked in Roster.java (deleteSharedUser[/b]) and appropriate action is taken to cleanup. One thing is overlooked though. When deleteRosterItem[/b] is called from deleteSharedUser[/b] a presence packet is routed without checking if the item to delete is a shared group item. The result is corrupted rosters. This can be fixed by checking the flag doChecking[/b] in deleteRosterItem[/b], since this flag is used to see if the function call is a result of a shared group modification.

Another thing is the check;

// Do nothing if the existing shared group is not the sharedGroup to remove





that prevents rosteritems from being deleted on the wrong basis is present in the function deleteSharedUser(Group sharedGroup, JID deletedUser)[/b], but is missing in the function deleteSharedUser(JID deletedUser, Collection groups, Group deletedGroup)[/b]. This causes incorrect deletion of rosteritems in the cache.

I am fairly new to Wildfire, so I can be completely wrong. Please tell me if so.


Message was edited by:


Message was edited by:


Hi Rop,

without looking at the code I think that this is really possible. The database content of my testing and loadtest environment is already corrupted …

Unless the database design is not “fixed” these problems will occur.


PS: There’'s also a Wildfire Dev forum, which would be more appropriate for such questions.


Thanx for the reply. I’'ve posted it on the Dev forum.