Thanks for reporting this. With just this information, the issue is somewhat elusive. I’ve tried to do some debugging, but didn’t really get anywhere.
I figured that being able to review the current state of the privacy lists (which hold the block list) would be a good tool to analyze this issue.
I’ve created issues OF-2108 and OF-2109 to have the current state of the privacy lists added to the admin console. I’ve also created a basic implementation, which can be found in https://github.com/igniterealtime/Openfire/pull/1733
All this does not resolve your issue, but hopefully these tools can help to further diagnose what’s going on.
Niiice! Thanks, Guus, that’s going to be really helpful in debugging this!
It will me on my list to solve that blocking issue in 1-2 weeks and I’ll get back to you if I find anything.
FYI: the new admin console pages that let an admin look at the privacy list configuration of users was included in Openfire 4.6.0, that got released last week.
Way ahead of you, Guus
I already cherry picked your changes in my fork and gave it a try.
Now I’m relatively certain that clustering and caching are NOT the issue. The values were always consistent between the nodes. I suspect there’s a more conventional bug in IQBlockingHandler.
It seems to put incorrect values in the privacy list. I started playing around with blocking different users and saw some strange things in your new admin panel:
I started out with two blocked users.
I blocked a third one
In the admin panel I saw still two blocked users. The new one replaced one of the others
I unblocked one
The list became empty
I blocked one of the first users again. Suddenly the original two blocked users appeared in the list
I saw some logic about reordering the items and creating new default lists in IQBlockingHandler. Maybe the problem is there. I’ll debug it tomorrow.
Anyway, your new admin panel helped out a ton!!! Thanks for implementing that so fast!
