Laravel Nova Email On Event Laravel Package

Getting Started

This package is designed for Nova-driven, event-triggered email rules: an admin defines “when X happens, email Y,” and the package listens for that event and sends the mail. It is archived and has no dependents, so treat it as a small, inspectable codebase rather than an actively maintained dependency.

Minimal setup:

composer require michielgerritsen/laravel-nova-email-on-event
php artisan vendor:publish --tag=email-on-event-config
php artisan vendor:publish --tag=email-on-event-migrations
php artisan migrate

Then:

1. Check composer.json / README.md in vendor/michielgerritsen/laravel-nova-email-on-event for the service provider name, config keys, and Nova tool registration.
2. Confirm Nova version compatibility before installing. If the package targets Nova 3 and you are on Nova 4/5, expect to fork or patch.
3. Register the Nova tool/provider if it is not auto-discovered.
4. Open the Nova sidebar entry the package adds, usually an “Email on Event” resource/tool.
5. Configure your first rule against a safe event.

First use case: notify an internal operations address when an order is created.

• Event: App\Events\OrderCreated or the model event equivalent the package expects.
• Recipients: a fixed ops address for the first test.
• Mail driver: log locally so you can inspect content without sending real mail.
• Test by creating an order in php artisan tinker or through the app.

Because the package is archived, pin it to a specific commit in composer.json and review the source before relying on it in production.

Implementation Patterns

Use domain events rather than raw model events for business rules. Model events such as created are convenient, but they fire for imports, seeders, tests, and admin edits. Dispatch an explicit event from the place where the business action actually completes:

event(new OrderPlaced($order));

Then map that event to an email rule. This keeps the package’s configuration stable even if model lifecycle behavior changes.

Keep the Nova rule as configuration, not business logic. The package is best used for recipient/subject/template configuration. Put branching logic in your event class or a listener:

if ($order->total > 1000) {
    event(new HighValueOrderPlaced($order));
}

Create separate rules for separate recipient groups instead of embedding conditional recipients in one template.

Pass a serializable payload. If the package interpolates model attributes into emails, make sure the event exposes what the rule needs. Prefer passing IDs or a small DTO/array rather than a large Eloquent graph. If the email is queued, the payload must survive serialization.

Queue the actual mail. Event-triggered email in a web request is a latency and reliability risk. Check whether the package’s mailable implements ShouldQueue or whether the config exposes a queue name. If not, wrap the dispatch point:

Mail::to($recipients)->queue(new OrderPlacedMail($order));

or fork the package’s send path to queue. Ensure a worker is running and failed_jobs is monitored.

Separate environments by config. Use environment-specific recipients and disable rules outside production:

// config/email-on-event.php
'recipients' => env('EMAIL_ON_EVENT_RECIPIENTS', '[email protected]'),
'enabled'    => env('EMAIL_ON_EVENT_ENABLED', false),

Then test with MAIL_MAILER=log and a local Nova rule before enabling production recipients.

Test with fakes and direct event dispatch.

Mail::fake();

event(new OrderPlaced($order));

Mail::assertQueued(OrderPlacedMail::class, function ($mail) use ($order) {
    return $mail->order->is($order);
});

Also test the Nova CRUD layer separately: create a rule in a feature test, dispatch the event, assert the mail. If the package uses dynamic event names from the database, assert the rule resolution logic explicitly.

Integration tip: use observers/subscribers to dispatch a consistent event. If several parts of the app create orders, centralize the event dispatch so the package does not miss paths:

class OrderObserver
{
    public function created(Order $order): void
    {
        event(new OrderPlaced($order));
    }
}

Be careful not to double-dispatch if the package also listens directly to model events.

Gotchas and Tips

• Archived status is the main risk. No dependents, 23 stars, and archived means no upstream fixes. Audit the send path, recipient handling, and event matching before production. Fork it, pin the commit, and own the code.
• Nova version compatibility. Check the package’s composer.json constraints. Nova major upgrades often break tools/resources. If you are on a newer Nova, expect to patch service provider registration, tool metadata, or field APIs.
• Synchronous sends can break requests. If mail is sent inline during an event, a slow SMTP server can delay or fail the originating action. Queue mail and consider afterCommit() so emails are not sent for rolled-back transactions.
• Event payload availability. If the email template references relationships, those may be unavailable or stale in a queued job. Eager-load before dispatch or pass scalar values.
• Deleted models. A deleted event fires when the model may no longer be retrievable. Capture attributes before deletion if the email needs them.
• Duplicate emails. Model events can fire multiple times due to updates, imports, or retries. Use explicit domain events or idempotency guards. Check failed_jobs and retry behavior.
• Recipient handling and privacy. Verify whether recipients are in to, cc, or bcc. For distribution lists, use bcc to avoid exposing addresses. Validate admin-entered addresses; do not let arbitrary Nova users configure recipients without authorization.
• Config caching. If you publish config, run php artisan config:clear during development. In production, remember php artisan config:cache after changes.
• Debugging path. Use MAIL_MAILER=log, tail storage/logs/laravel.log, inspect failed_jobs, and use Telescope if available. Add temporary logging around the package’s event listener to confirm the event name and payload it receives.
• Event naming quirks. The package may expect a fully qualified class name, a Laravel event string, or a model event convention. Confirm from source rather than guessing; a mismatch results in silent no-sends.
• Extension points. Prefer overriding published views/mailables and config over editing vendor code. If you fork, keep the package namespace and add a small adapter layer so you can replace it later.
• Migration and rollback. Inspect published migrations before running them. Since the package is unmaintained, ensure the schema is compatible with your database and rollback path.
• Authorization in Nova. Confirm which Nova users can create or edit email rules. A rule that sends customer data to an arbitrary address is a data exfiltration path. Gate the resource/tool with policies.