I've been finding some fairly serious bugs in security related to the mains cache.
get_access_level() was modified to return cached values without performing all checks for highest access level, which I think is what caused the problem but I'm not 100% sure.
I discovered the issue by adding and removing users from a custom group. When I added a user with an access level of MEMBER to a group which had an access of LEADER, the user did not get LEADER access until the bot was restarted.
After restarting the bot and removing the user from the security group, the user's access level did not return to MEMBER until the bot was restarted.
I didn't note the original line number, but somewhere around L1550 get_access_level() was returning information from the mains cache that was no longer up to date due to the group membership changes. I've removed this in the 0.4 branch and things are working as expected now.
Somewhere along the way we may have lost the code that updates the security cache when adding and removing group members, or we created a bug....
Ideally we should be returning cached information if it is available, but something seems wrong with our logic at the moment. Someone (most likely me, oh joy) needs to take a serious look at Security.php do the following:
- If there is a change that might cause a chaced access level to chance, recheck and recache.
- Make sure that /tell botname security whois player returns expected results when changing access levels for groups, adding/removing group members, chaning access levels for org ranks, etc.
- In general just update Security.php to get it up to BeBot's formatting standards (indents, brackets, etc.)