I blocked user "H". As expected, "H" can no longer log in. However, "H" still receives email notifications. I expect blocked users like "H" should not receive email notifications. This is especially problematic because "H" was following a private group with content hidden from non-members. Not only is "H" seeing content he should not see, but also "H" can't log in and stop following the private group even if he wanted to -- unless I unblock him.


WebSinPat’s picture

i came across this issue report quite by accident and will check and see if i can reproduce this behavior. I have not yet tested it or noticed it one way or another myself, but would not want this behavior on my site either.

One thing that comes to mind @behoppe333 is whether it makes a difference if the account is blocked with that account's content still visible vs blocked with that account's content unpublished? (this setting is what was causing my problem with blocked users comments still showing up. googling it is how i found your bug report. No idea if it also controls other functionality like flags/notifications or not.)
it's a pretty basic concept but i had not had reason to use it yet, so here's the helpful little article i found: http://www.drupalgardens.com/documentation/blocking-or-canceling-users

WebSinPat’s picture

Hi @behoppe333,
I think this can be solved as I suggested above.
- block the user NOT by blocking them but by "cancelling" their account (on the admin/people page, using the dropdown selector)
- then given the options of which type of cancellation make sure to select "Disable the account and unpublish its content."
- then you can view the user's email notification settings page and it should show they are no longer following any content
- and a new post in the group they did follow does not send them email.

Hope this helps.

I think the underlying problem here that leads to confusion is that the nomenclature of "blocking" a user is ambiguous and the default is not necessarily what I or the average site admin would expect.
I might suggest something like the following
- change "blocked" to "blocked from logging in" because that seems to be the only restriction that a simple "blocked" does
- add a user status category "cancelled" to help distinguish
- add "cancel account" option other places like the user edit page under "status" user/XYZ/edit to help make it clearer

of course, i think those are core issues I'd guess, so not sure how to get them addressed.

behoppe333’s picture

Thanks, @WebSinPat. Very helpful. I will try that.

Leeteq’s picture

Version: 7.x-3.3 » 7.x-3.x-dev
Issue summary: View changes

Reference: #1912520: Email notifications should enforce node access restrictions
What is the status on this issue with the latest release?

WebSinPat’s picture

@behoppe333, did the process i suggested in #1 and #2 work for you? If so, i think we can close this as "works as designed", and re-close the issue referenced by @Leeteq in #4.

And I went ahead and opened a core issue #2164185: Request more clarification on difference between blocking and cancelling user account in case that is the correct thing to do and helps for the future.

tleavitt’s picture

Coworker of @behoppe333 here -

There does seem to be a use case for blocking users; simply cancelling a user would allow them to re-register with the same details. (Correct me if that's wrong.) And if a user is blocked from logging in, they can't choose to unsubscribe.

Here's an alternate solution (a separate module named messages_omitblocked) - the module with the issue is message_subscribe.

* @file
* A module that prevents users from receiving e-mail notifications when they are blocked.

* Implements hook_message_subscribe_get_subscribers_alter() to filter out blocked users
function messages_omitblocked_message_subscribe_get_subscribers_alter(&$uids, $values) {
  foreach($uids as $key => $value) {
    //Check to see if this user is Active or Blocked
    $account = user_load($key);
    //Clear $uids subscript if the user is Blocked
    if($account->status == 0) {
Leeteq’s picture

Hm, I dont know why #1912520: Email notifications should enforce node access restrictions was linked to this issue at all, seems unrelated and fixed, so I just set it back to fixed status.

This issue here though, seems to need more considerations.

IMO, the notifications module should check to make sure it does NOT send email notifications for accounts that are blocked.

Related, but unsure if it is already handled:

- NOT when just blocking a user (then email notifications should just stop as noted above), but when actually removing a role from any user, be it a blocked account or an active account, then there should be a trigger from that part of Drupal Core that would be caught by modules such as email notifications, to automatically check and remove relevant subscriptions. Not sure if that is already happening, so just mentioning it here for comments.

Leeteq’s picture

(PS. Blocking of a user account can be temporary, and even a mistake, so subscriptions should be allowed to work again once an account is unblocked, as long as the user is still part of the same groups/roles.)

WebSinPat’s picture

Yes I agree with all the considerations being raised here about the desired/expected behavior of blocking a user.


There does seem to be a use case for blocking users; simply cancelling a user would allow them to re-register with the same details.

yes definitely.
But it seems like the correct behavior can be achieved by selecting the option

  • Disable the account and unpublish its content

And that disables the user from following content and email notifications, while keeping the user info on the site so that the same user cannot create a new account.

Does this not work in your situation?
I haven't looked at the message_subscribe code but so it does seem like there is some checking of user status somewhere in the notification tree, but that's not just on status==0/1 but maybe on whatever permission is unset when you "unpublish its content"?

And still with the confusing wording between blocking, disabling, canceling, and deleting accounts....

@Leeteq, I have not done any testing with un/setting roles or re-enabling an account after it was temporarily "Disable the account and unpublish its content". If you get a chance to test those permutations, i'd be interested to know what you find.

tleavitt’s picture

I guess a lot of it does depend on the situation. Maybe we'd want to unpublish the newly-blocked user's content, maybe not. Still, disallowing access by simply changing status from "blocked" to "active" seems the most intuitive.

A side effect of "disable the account and unpublish its content" seems to be that the user is unsubscribed from everything. I think it makes sense, like Leeteq said, that "subscriptions should be allowed to work again once an account is unblocked, as long as the user is still part of the same groups/roles" - assuming that this means that if the user is reactivated, their old subscriptions are still in effect.

ezra-g’s picture

Title: Blocked user still receives email notifications » Don't send commons_notify mails to blocked users
Issue tags: +commons 7.x-3.9 radar

My expectation is that Commons would be protected against sending emails about content whose visibility is restricted to certain users (eg, content in a private group protected by og node access) now that SA-CONTRIB-2014-001 - Entity API - Access Bypass is in place. However, I agree that we'd also want to send general email notifications from the Commons Notify module for content that's unprotected. I think a solution similar to the one in #6 could be appropriate, though we'd want to be careful to avoid unnecessary user loads.

Adding to the 3.9 radar.

ezra-g’s picture

Status: Active » Needs review

I believe we've arrived at a solution to this issue through a patch to the Message Subscribe module. It would be great if folks could review the patch at #2184567: By default, don't notify blocked users and report back on whether this resolves the issue for them.

japerry’s picture

Priority: Normal » Major
japerry’s picture

Status: Needs review » Fixed

Added the patch from message subscribe to the drupal-org make file, and it fixes this problem.

  • Commit 60af712 on 7.x-3.x by japerry:
    Issue #2092441 by japerry, RoySegall: By default, don't notify blocked...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.