Send notifications only to users who can view content

Created on 14 September 2021, about 4 years ago
Updated 13 February 2023, over 2 years ago

Problem/Motivation

There is an issue Notification emails should not send to blocked users which does make sense because we don't want blocked user to see the content, but what if we are using some modules to restrict user access to content, based on something else than Role or Status? For example Permissions by Term module?

Proposed resolution

Attaching a patch with small fix, which checks 'view' access on entity before add user account to the list of notification recipients.
With this patch we may not need to use the patch from #3078110 issue, since blocked users don't have 'view' access anyway.

Feature request
Status

Needs review

Version

3.0

Component

Code

Created by

🇺🇦Ukraine tarasich Kyiv

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇷🇸Serbia savel

    Rerolled against the latest dev.

  • Status changed to RTBC over 2 years ago
  • 🇺🇦Ukraine ysamoylenko

    Hello @savel,

    Thank you for the patch.

    It looks good to me.

    Happy to RTBC!

  • First commit to issue fork.
  • 🇮🇳India urvashi_vora Madhya Pradesh, India

    Reviewed and tested the patch, works well for me as well.

    LGTM, RTBC++

    Committing the changes for helping the maintainer.

  • @urvashi_vora opened merge request.
  • Status changed to Fixed almost 2 years ago
  • 🇧🇾Belarus dewalt

    Looks like the maintainer solved this issue in this commit 2 mount ago and left you without credits(

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

  • Status changed to Fixed about 2 months ago
  • 🇦🇺Australia alex.skrypnyk Melbourne

    This code was added in 3.6 to check for the anonymous access to the content before adding the email address to the senders list:

    $anonymous_access = $entity->access('view', User::getAnonymousUser());
    

    But this does not make sense: if the transition was into the draft state, this check will always return FALSE. This makes this module only usable for transitions to a published state when your recipient is an email who is not a user of the website.

    Such logic change is weird to say the least.

    A workaround is to implement a hook and replicate the old behaviour.

Production build 0.71.5 2024