Lara Alert Laravel Package

Getting Started

1. Install the package with Composer and run any required publish/migration steps:

   composer require vendor/package
   php artisan vendor:publish --tag=package-config
   php artisan migrate
   

2. Add the Alertable trait to each model that should own alerts:

   use Vendor\Package\Concerns\Alertable;
   
   class Post extends Model
   {
       use Alertable;
   }
   

3. Start with the new deletion workflow from release 1.0.2: create or retrieve an alert, then remove it through the trait method rather than deleting the record directly.

   $post->deleteAlert($alert); // confirm exact signature in the trait
   

Look first at the Alertable trait source and the package README for the existing create/list methods. The new deleteAlert method is the main addition in 1.0.2.

Implementation Patterns

• Use the trait on domain models that logically own alerts, such as Post, Order, or User, rather than centralizing all alert behavior on a single model.
• Keep alert deletion behind authorization:

  public function destroyAlert(Post $post, Alert $alert)
  {
      abort_unless($alert->alertable_id === $post->id, 403);
  
      $post->deleteAlert($alert);
  
      return back()->with('status', 'Alert deleted.');
  }
  

• Wrap multi-step alert operations in transactions when deletion is part of a larger workflow:

  DB::transaction(function () use ($post, $alert) {
      $post->deleteAlert($alert);
      // related cleanup
  });
  

• Prefer the trait method over direct Alert::destroy() or query-builder deletes so package behavior, events, and future logic remain centralized.
• Add feature tests around the new method:

  $post->deleteAlert($alert);
  
  $this->assertDatabaseMissing('alerts', [
      'id' => $alert->id,
  ]);
  

• If your UI exposes an alert “dismiss” or “delete” button, route it through a controller action that resolves the owning model, checks ownership, then calls deleteAlert.

Gotchas and Tips

• Verify the exact deleteAlert signature in the trait before depending on it. It may accept an alert model, an ID, or another package-specific value.
• The trait method is unlikely to enforce authorization by itself. Always verify that the current user can delete the alert and that the alert belongs to the expected model.
• Confirm whether deleteAlert hard-deletes, soft-deletes, or dispatches events. If the alert model uses SoftDeletes, adjust assertions and UI expectations accordingly.
• Direct database deletion bypasses the new trait method and may skip package-level behavior. Use deleteAlert for normal application flows.
• Check foreign-key behavior when deleting the owning model. If alerts should disappear with their parent, ensure cascading deletes or model observers are configured.
• If the package supports a custom alert model or table name, publish and review the config rather than assuming defaults.
• For debugging, inspect the trait method and run the deletion inside a test or DB::listen callback to see the actual query and event flow.
• This is a patch release adding a convenience method. Treat it as non-breaking for existing code, but update Composer and rerun your alert-related tests after upgrading.