In raising this pull request, I confirm the following (please check boxes):

• [x] I have read and understood the contributors guide.
• [x] I have checked that another pull request for this purpose does not exist.
• [x] I have considered, and confirmed that this submission will be valuable to others.
• [x] I have added tests to prove that the code in this PR works.

Description

This PR for #11 .

Let me tell how it's works.

You can install new version and if your app suits next requirements:

• You have \App\User class
• You have added scopeCanBeNotifiedAboutFailedJobs method to \App\User. You're ready to use it oit of the box,

You can publish config and get next abilities:

• Change Notifiable class
• Change Notification class
• Set channels
• Set criteria method's name for notifiables

Also you can add additional notifications. For example what it you send very important email to your customer and if fails... Of course developers will get this error, but also we can setup ability to notify about this issue our sale merchant without any technical information, just to inform responsible person for client that something went wrong, so you can add to config next lines:

'App\Jobs\SendImportantEmail' => [
    'notifiable' => \App\User::class,
    'notification' => \Spatie\FailedJobMonitor\Notification::class,
    'via' => ['mail'],
    //'filter' => 'canBeNotifiedAboutFailedJobs'
],

And App\Jobs\SendImportantEmail job will fail * and App\Jobs\SendImportantEmail will be used for notification.

So I think this solution is flexible:

• You're not attached to notifiable entity
• You can easily customize notification
• You can notify not only developers but users too about some important issues without any sensitive data.

All data (exception and payload) are sening as attachment via email.

I'm ready to hear your option, @freekmurze

In raising this pull request, I confirm the following (please check boxes):

• [x] I have read and understood the contributors guide.
• [x] I have checked that another pull request for this purpose does not exist.
• [x] I have considered, and confirmed that this submission will be valuable to others.
• [x] I have not added tests to prove that the code in this PR works. E-mail tests are already there.

Description

This patch allows one to configure a custom view for the e-mail notification.

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 8.x.

Before merging, you need to:

• Checkout the l8-compatibility branch
• Review all comments for additional changes
• Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

This code is entirely untested, but I wanted to open the PR to see if there is interest in adding this functionality. It can also be implemented via a notificationFilter, but I thought maybe this should be provided out of the box.

If there is interest, I can look into adding tests and making sure it actually works :)

Backstory: Yesterday I deployed broken code and ended up sending out 400 emails to our internal engineering mailing list :)

Various queue job events such as JobProcessing, JobProcessed and JobFailed no longer contain the $data property. Should use $event->job->payload() to get the equivalent data.

Thank you for this great package. It has really nice features that are very useful for developers. I was just wondering if would it be nice to have the possibility to define more than one email address.

This may break backward compatibility because the returning type of routeNotificationForMail method has been changed. It would be nice if this feature can be part of the next major release if it's possible.

Let me know if you have any questions.

Thanks!

Using a closure in the notifications filter results in an error as they are not serializable. This pull request documents the better approach of using callables.

Resolves https://github.com/spatie/laravel-failed-job-monitor/issues/55

This PR adds a new major version, v4.0.0.

Specifically, it:

• Removes support for all PHP 7.x versions.
• Requires PHP 8.0+.
• All syntax converted to PHP 8 where possible.
• Removes unnecessary PHP docblocks per Spatie's guidelines.
• Removes Laravel v6 & v5.8 support.
• Implements spatie/laravel-package-tools.
• Updates the changelog - release date needs to be updated, currently is "unreleased".

When developing using this package, I wanted to add a new notification type. So I created a new class an extened the \Illuminate\Notifications\Notification class however I received an error stating the new class I made had to extend the Illuminate\Notifications\Notification class, which my class was doing.

A workaround is extending the Spatie\FailedJobMonitor\Notification - however, the error message does not suggest this to be the correct source of action.

This pull request resolves the issue by importing the Illuminate\Notifications\Notification and uses it in the isValidNotificationClass method.

This PR adds support for the upcoming release of laravel 8. Tests are all passing. I excluded php version 7.2 for laravel 8 since laravel itself requires php 7.3

To get the tests to work I had to set the minimum stability to dev, since laravel 8 is not released yet. This change should probably be reverted before releasing.