Skip to:

Opened 11 years ago

Closed 10 years ago

#5297 closed defect (bug) (fixed)

Disallow multiple core and email notifications for same item

Reported by: henrywright's profile henrywright Owned by: boonebgorges's profile boonebgorges
Milestone: 2.0 Priority: normal
Severity: normal Version:
Component: Toolbar & Notifications Keywords:


Although this is way too late to think about for 1.9, is it worth disallowing multiple core and email notifications for the same item? For example, Member X might decide to continually at-mention Member G in a blog post which would result in multiple core and email notifications being sent to Member G.

Perhaps a check to see if a read or unread notification already exists would stop this from happening?

$notifications = BP_Notifications_Notification::get( array(
    'user_id' => $mentioned_user_id,
    'item_id' => $item_id,
    'secondary_item_id' => $mentioner_id,
    'component_action'  => 'new_at_mention'
) );
if ( ! $notifications ) {
    // send an email or add a core notification

Change History (5)

#1 @boonebgorges
11 years ago

  • Milestone changed from Awaiting Review to 2.0

Smart thinking. This didn't really come up in the past, because notifications were deleted after being viewed anyway.

#2 @henry.wright
11 years ago

Is there a check list available which contains all the things notifications can be issued for. e.g.

  • private messages
  • at-mentions in comments
  • at-mentions in posts
  • new friendship requests

... and so on?

I was hoping to go through each one to see where the logic I proposed above may be needed.

#3 @boonebgorges
11 years ago

I don't think there's a list readily available, but you could compile one by searching our codebase for uses of bp_notifications_add_notification().

Another consideration is to put a check directly into bp_notifications_add_notification(). I don't know how others feel about that, but I'd think that (at least in the majority of cases) there's no reason ever to allow for duplicate entries in the notifications table. So we could make our API function idempotent by default, with perhaps a flag allow_duplicate that could be passed to bypass this block.

#4 @henry.wright
11 years ago

I think your suggestion to put a check directly into bp_notifications_add_notification() is far better than making changes across the codebase:

  1. It will eliminate the problem of duplicate notifications wherever they are generated from in BP core.
  2. It'll eliminate the problem for any plugins that may using the bp_notifications_add_notification() function.

The flag is a great idea as it will let bp_notifications_add_notification() retain it's flexibility if duplicate notifications are ever needed.

#5 @boonebgorges
10 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 8100:

Disable duplicate notification creation by default, and introduce 'allow_duplicate' param for override

Generally, it's undesirable to have duplicate notifications for a given
user-item-secondary_item-component-action combination (as when, say, someone
mentions you many times in a single message thread). This changeset introduces
duplicate protection, which can be overridden by passing the 'allow_duplicate'
param to bp_notifications_add_notification().

Fixes #5297

Note: See TracTickets for help on using tickets.