- How do I install Yammi Audit Log in a Laravel application?
- Run composer require romalytar/yammi-audit-log-laravel followed by php artisan migrate. Capture starts globally from that first migration, with no traits, interfaces or per-model observers to register. The dashboard is optional and stays disabled until you run php artisan audit-log:ui enable.
- Which Laravel and PHP versions does this audit log package support?
- The package requires PHP ^8.1 and supports Laravel 9 through 13, and it runs on any database Laravel supports. CI tests it on PHP 8.1, 8.2 and 8.3 with roughly 95.5% coverage. That makes it a good fit for current Laravel monoliths and small service fleets rather than legacy 8.x projects.
- How is Yammi different from spatie/laravel-activitylog or owen-it/laravel-auditing?
- Most audit packages record what changed; Yammi also records the actor (who executed it), the origin (who triggered it) and a correlation ID that ties a whole cascade together, including work that crosses queue jobs. That answers the which-job-triggered-by-whom-wrote-this-row question the classic packages leave open. It also needs zero per-model setup, while trait-based packages require every model to opt in. If your app has no queues, the competing packages are cheaper and simpler.
- Does it capture every database change, including query builder updates and raw SQL?
- No. Capture is driven by Eloquent model events, so Query Builder update() calls, raw SQL, bulk imports and some pivot writes stay invisible unless you record them explicitly with AuditLog::record(). Keep a documented inventory of those blind spots for audit reviews, and wrap the write path so the change and the manual audit entry commit in the same transaction. It is deliberately not an event-sourcing or replay system.
- What happens if the audit log insert fails, will it break my business write?
- The package is fail-open: a failed audit insert never blocks or rolls back the underlying business write. That is the right default for availability but the wrong one for evidentiary integrity. If a requirement says no change may happen without a log, enforce it yourself by wrapping both operations in a single database transaction. The v2.2 capture-health banner and stats badge surface problems, but they are not a guarantee.
- How do I test that audit logging works in my Laravel test suite?
- Use the AuditLog::fake() testing API to assert that entries were recorded without writing to the audit table. It lets you verify expected rows, actors and correlation IDs inside normal PHPUnit or Pest tests. That removes most of the how-do-we-test-this objection before you commit to adoption.
- Does Yammi Audit Log store sensitive data like passwords, tokens or customer PII?
- Field-level diffs of row state are stored, so treat the audit table as a PII surface. Secret redaction is configuration-driven and key-based, so it catches password columns but not a customer email written into a free-text notes field. Retention defaults to 180 days, which is a sensible posture, but ownership of the retention policy is organizational. Review which columns you capture before enabling the dashboard.
- How do I enable and secure the audit log dashboard?
- Run php artisan audit-log:ui enable and the dashboard is served at /audit-log. The UI is off by default, sits behind configurable middleware and an optional Gate, and the read API refuses to register without an auth guard. Enabling it turns your app into a PII viewer for anyone who can reach the route, so scope the middleware and Gate deliberately.
- How does it attribute changes to users, jobs, commands and scheduled tasks across queues?
- Each recorded change carries an actor, an origin and a correlation ID that survives queue hops, so a cascade started by a user request and finished by three queued jobs stays traceable as one timeline. Background contexts are attributed to jobs, artisan commands and the scheduler instead of appearing anonymous. Optional async writes and a dedicated connection keep audit ingestion off your request path if volume grows.
- Is it safe to run in production when it is maintained by a single developer?
- The quality signals are decent, with around 95.5% coverage and CI across three PHP versions, but this is a young single-maintainer package with a small install base, and you would be placing it in your compliance and forensics layer. Pin a known-good version, review the release history (including the oddly future-dated 2026-06-30 release), and ask about support model, semver commitments and a handover plan. Because it is an additive side-car with no coupling to domain code, forking or removing it later is cheap.