Feature #19980


Better duplicate-notification prevention for bp-multiple-forum-post

Added by Boone Gorges 2 months ago.

Priority name:
Category name:
Group Forums
Target version:
Start date:
Due date:
% Done:


Estimated time:
Deployment actions:


bp-multiple-forum-post was written before BPGES started using an asynchronous queue technique for sending notifications. As a result, its mechanism for preventing duplicate notifications - which involves a runtime global - is not effective. Instead, we should prevent BPGES from entering a record into the queue table when we see that the user already has the activity item in his/her queue.

This in itself will not be enough. If you post to A and cross-post to B, you could have a situation where:
1. The item is queued with respect to group A, and bp-multiple-forum-post schedules a task to create the crossposts
2. BPGES runs its "immediate" queue and your A notification goes out. It's then deleted from the queue.
3. Later, bp-multiple-forum-post creates its crossposts. Since the A notification has been cleared from the queue, the check described above won't be found.

Modifying BPGES to keep a persistent queue seems like a bad idea - it'd mean introducing a 'status' column, and it'd mean keeping items around forever, unless we had a cleanup routine.

I guess the alternative is to keep track in some other way of users who have received notifications (or, better still, users for whom a BPGES notification has been queued) on a cross-posted item. There's no beautiful way to do this. I guess maybe a piece of postmeta that lives with the original post, which will have to be checked when bp-multiple-forum-post creates the crossposts.

Related issues

Related to CUNY Academic Commons - Bug #19971: Expected Group Forum FunctionalityNew2024-03-13

Actions #1

Updated by Boone Gorges 2 months ago

  • Related to Bug #19971: Expected Group Forum Functionality added

Also available in: Atom PDF