[8.x] Added ability to cancel notifications immediately prior to sending

[gbradley]

This PR makes it easier to cancel notifications immediately prior to sending, without having to register custom event listeners or create job classes.

Use case

Queued or delayed notifications make it possible that data changes between the notification being queued and its job being processed. Sometimes the up-to-date data is no longer compatible with the kind of notification being sent, for example a "DispatchConfirmation" email on an order that has since been cancelled.

Currently the primary way to prevent notifications being dispatched with stale information is to register a custom event listener, listen for the NotificationSending event, and attempt to call user-defined methods on the notification class in order to determine if the notification should be sent or not. Alternatively, a Job can be queued which synchronously dispatches a notification after the current state is checked.

This PR just simplifies this process by checking for the existance of a shouldBeSent() method on the notification and cancelling sending if the method returns anything but true.

Non-breaking changes

The NotificationSending event is still dispatched, so applications using the technique described above will not be affected.

[ankurk91]

#30070

[gbradley]

@ankurk91 Interesting, I wasn't aware job middlewares could be applied to notifications, but it makes sense. While you could apply middleware for this I would still find it cumbersome, because I'd likely have to define separate middleware classes for each notification class I wanted to work with. The approach in this PR would let me avoid that and keep the logic for each notifcation inside the relevant notification class.

[davi5e]

Just a quick question, does this PR does the same thing Laravel Relevance Ensurer does? As in the code should be interchangeable with minor tweaks?

[gbradley]

I haven’t used that package but yes, the principle is very similar. You’d need to rename your isRelevant method to shouldSend and add the second $channel parameter, but that’s about it.

…

On 16 Jul 2021, at 19:29, davi5e ***@***.***> wrote:  Just a quick question, does this PR does the same thing Laravel Relevance Ensurer does? As in the code should be interchangeable with minor tweaks? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mrpritchett]

Should the notification mock assertions like assertNotSentTo obey this method? I'm hitting a case where assertNotSentTo returns false because it's not hitting the shouldSend method.