CUNY Academic Commons

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.