Disallow multiple core and email notifications for same item

[henrywright]

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
}

[boonebgorges]

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

[henry.wright]

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.

[boonebgorges]

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.

[henry.wright]

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.

[boonebgorges]

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