If an administrator accidentally adds a blocked user to a group an active group notifications subscription is created for the blocked user. This blocked user then begins to receive content not intended for them.
Steps:
1. block a user.
2. Add that user to a group
3. Go the the users subscriptions and notice an active group subscription has been added for that group.

This can occur when similar usernames are created for users, for example Sam Smith and Sally Smith might have usernames like ssmith and ssmith1. An admin may accidentally add the wrong name to the group.

Perhaps this can be solved by preventing subscriptions from being created when the user's status is blocked/inactive or by preventing a blocked user from being added to a group.

Comments

Grayside’s picture

This can be checked in og_notifications_og() by not updating the notifications if the user is blocked, but that seems kind of aggressive. It makes more sense to me that we do not corrupt or preempt data just because a user is blocked.

Instead, the notifications module itself should have some kind of logic around not sending events to unsubscribed users. If that requires some additional behaviors on OG's side, so be it.

My reasoning is that if a user is allowed to be subscribed to a group while blocked, but all the data related to that subscription isn't properly created, you will create a corrupt group subscription. We could proceed to screen blocked users from getting notification subscriptions, but that would only work if we had some mechanism (automatic or UI) around getting a user connected with their proper subscriptions.

Blocking a user doesn't always mean banning. It could be an accident. It could also be for preparing accounts that are not yet granted access to the system.

Grayside’s picture