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

if(!item.getSharedGroups().contains(deletedGroup)){

return;

}

/code

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.

Thanx

Message was edited by:

robbie

Message was edited by:

robbie

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.

LG

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

LG,

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

Greets,

Rob