We will implement this advice trapping for whether the user in question, is the user in the session -- however it raises the question about activations/deactivations peformed via other means (expiration, admin action). In other words we need it to work in all cases of activation/deactivation.
It will work in all cases, but it can only update the users session in database if the user is the one performing the action. For example this is relevant if you update the usergroups while the user is still browsing the site.
however I anticipate possible problems on this (i.e., if CB's objects need me to avoid direct table writes, but the present session is not applicable to the user who is subject to the status change, what do I do?)
The session has no effect on the storage. It's purely user browsing experience. For example lets say the user is logged in, I change his usergroups after he logs in, his session won't have the new usergroups. So any access associated with the new usergroups won't be seen by the user until they logout and back in again.
If this is done during registration or by CRON you don't need to bother with the session. It's only relevant if you change the usergroups while the user is already logged in.
krileon
