Add a configuration attribute to prevent deletion of database type notifications when the notificationClosed event is triggered

[domthomas-dev]

Context

Currently, when a database type notification is displayed and the user closes it, it is automatically deleted. However, in some cases, it might be advantageous to retain these notifications even after their closure. For instance, in scenarios where the user wishes to refer back to these notifications later to review a history or trace of past events.

Proposal

I propose adding a configuration attribute for database type notifications in Laravel Filament. This attribute could specify whether a notification should be deleted or retained upon closure by the user.

Implementation Details

Adding this configuration attribute should not require major modifications to the current logic of notification handling in Laravel Filament. It can be seamlessly integrated into the existing structure of notifications.

Here's how you could integrate the keepAfterClosed attribute into the creation of a notification in Laravel Filament, using the example you provided:

use Filament\Notifications\Actions\Action;
use Filament\Notifications\Notification;
 
Notification::make()
    ->title('Saved successfully')
    ->success()
    ->body('Changes to the post have been saved.')
    ->actions([
        Action::make('markAsUnread')
            ->button()
            ->markAsUnread(),
    ])
    ->keepAfterClosed(true) // New attribute to specify notification retention
    ->send();

in notification.js

close: function () {
            this.isShown = false

            setTimeout(
                () => {
                    window.dispatchEvent(
                        new CustomEvent('notificationClosed', {
                            detail: {
                                id: notification.id,
                            },
                        }),
                    )
                    if(! notification.keepAfterClosed) {
                        window.dispatchEvent(
                            new CustomEvent('notificationShouldBeDeleted', {
                                detail: {
                                    id: notification.id,
                                },
                            }),
                        )
                    }
                },
                this.transitionDuration,
            )
        },

in DatabaseNotifications.php

#[On('notificationShouldBeDeleted')]
    public function removeNotification(string $id): void
    {
        $this->getNotificationsQuery()
            ->where('id', $id)
            ->delete();
    }

Advantages

1. Increased Flexibility: Users can choose to retain certain database notifications for future reference, enhancing their user experience.

2. Event Traceability: By retaining database notifications, users can better track important event histories within the application.

3. Customization: This feature will enable additional customization of the user experience, allowing users to configure notification behavior according to their preferences.

Discussion

What do you think? I would love to hear your thoughts and suggestions on this proposal, especially on how to optimally integrate it into Laravel Filament.

[domthomas-dev]

Of course, I can do the PR, but only if there is a chance to be merge :)

[domthomas-dev]

@danharrin
Do you have some interest or not?

[danharrin]

How are you sending that notification? Database notifications don't typically get sent as flash notifications too

[domthomas-dev]

My Domain Logic is : Send a Notification (Mail, Database, SMS what I want) and for several notification types, I can add the database via.

    {
        return ['broadcast', 'database'];

    }```
    
In Standard Laravel Notification, in the `toDatabase` method, I do simply that

```php
public function toDatabase(object $notifiable): array
    {
        return \Filament\Notifications\Notification::make('d')
            ->title('Création du modèle de produit demandé')
            ->body(sprintf(
                'Création du modèle de produit demandé pour la mission n°%s. (%s)',
                $this->mission->number,
                $this->mission->customer->name ?? 'Client inconnu'
            ))
            ->duration(3) // Notification are persistant :(
            ->actions([
                Action::make('Read')
                    ->label('Lu')
                    ->icon('heroicon-o-envelope')
                    ->markAsRead(),
                Action::make('Unread')
                    ->label('Non lu')
                    ->icon('heroicon-o-envelope-open')
                    ->markAsUnread(),
                Action::make('See')
                    ->label('Voir')
                    ->icon('heroicon-o-eye')
                    ->url(route('admin.missions.edit', $this->mission)),
            ])
            ->viewData($this->toArray($notifiable))
            ->getDatabaseMessage()
        ;
    }

[domthomas-dev]

And I send it in broadcast too.

[danharrin]

If you want, override the DatabaseNotifications Livewire component to use your own, and then overwrite the method that controls what happens when you delete the notification?

[domthomas-dev]

That's a lot of overwrite for not much

[joseph-d]

I agree that additional control over what happens when a notification in a small modal is closed or auto-closes would be helpful.

I have a similar use case to @domthomas-dev whereby I'm using a Laravel Notifications class to send both database and broadcast notifications to Filament.

It's not just when the notification is specifically closed by the user (using the 'x') but also even when the small modal closes by itself, the deletion still seems to happen.

I feel that it's both useful for the user to be notified with a modal when a database notification is sent to them (especially when it's sent from the action of another user, using Reverb/Echo) and also for a record of a notification to be kept in the database in case the user didn't notice it or wasn't looking when it was sent which, again, can happen quite easily using Reverb/Echo.

The code performing the deletion seems to be in the DatabaseNotifications component:

    #[On('notificationClosed')]
    public function removeNotification(string $id): void
    {
        $this->getNotificationsQuery()
            ->where('id', $id)
            ->delete();
    }

This code is invoked under 3 very different conditions:

1. When a the 'x' is clicked on a notification on the slide-out notifications panel
2. When the 'x' is clicked on a notification modal
3. When the notification modal closes by itself after its set time

The 1st condition makes perfect sense to me, the second 2 not so much.

I understand that overriding the component is an option, but as @domthomas-dev noted, it's quite a lot of code to overwrite just for this one thing.

If there are valid use cases for deleting the notification after it's been closed from the small modal (or, as mentioned, even after it closes itself!) then I think the being able to pass an option to change the behaviour would be helpful.

But, otherwise, would you be open to the creation of a new method which treats the dismissal of a notification in a small modal differently than pressing the 'x' next to a notification in the slide-out modal list of notifications where deletion is more likely to be expected?

[joseph-d]

Here's a solution I came up with today, trying to solve the issue of database notifications deleting immediately after their corresponding broadcast notifications close.

First of all I created a Custom Channel:

<?php

namespace App\Channels;

use Illuminate\Notifications\Notification;
use Filament\Notifications\Notification as FilamentNotification;

class FilamentBroadcastChannel
{
    public function send($notifiable, Notification $notification)
    {
        if (method_exists($notification, 'toFilament')) {
            $data = $notification->toFilament();

            // Create the Filament notification
            $filamentNotification = FilamentNotification::make()
                ->title($data['title'])
                ->body($data['body']);

            // Apply the notification type if set (e.g., success, warning)
            if (isset($data['type']) && method_exists($filamentNotification, $data['type'])) {
                $filamentNotification->{$data['type']}();
            }

            // Send the broadcast notification without linking to the database notification
            $filamentNotification->broadcast($notifiable);

            // Send the database notification
            $filamentNotification->sendToDatabase($notifiable);

        }
    }
}

By calling broadcast() and sendToDatabase() individually like this it seems that they are no longer directly associated with each other, so when the broadcast modal closes, it doesn't affect the notification in the database. So the user won't miss it if the notification appeared and disappeared when they weren't looking.

Then, in the Laravel Notification class:

<?php

namespace App\Notifications;

use App\Channels\FilamentBroadcastChannel;
use App\Mail\ApprovedMail;
use App\Models\User;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Notifications\Notification;

class JobApprovedNotification extends Notification implements ShouldQueue
{
    use Queueable;


    /**
     * Get the notification's delivery channels.
     *
     * @return array<int, string>
     */
    public function via(User $notifiable): array
    {
        return [
            'mail', // if you need it
            FilamentBroadcastChannel::class,
        ];
    }

    /**
     * Get the mail representation of the notification.
     */
    public function toMail(User $notifiable): Mailable
    {
        return (new ApprovedMail())
            ->to($notifiable->email);
    }

    /**
     * Get the array representation of the notification for Filament.
     */
    public function toFilament(): array
    {
        return [
            'title' => 'Title of notification',
            'body' => 'Body of notification',
            'type' => 'success',
        ];
    }
}