Auditable Log Laravel Package

Getting Started

Confirm the premise before you install anything. This package is a Nova resource tool that renders the audits table written by owen-it/laravel-auditing. It has no migrations, no config file, and no runtime logging of its own. If Nova isn't installed and Laravel Auditing isn't already writing rows, there is nothing for this tool to display.

Step 1 — prove audits are being captured. Set up Laravel Auditing on one model and verify rows land:

use OwenIt\Auditing\Contracts\Auditable;
use OwenIt\Auditing\Auditable as AuditableTrait;

class Invoice extends Model implements Auditable
{
    use AuditableTrait;
}

Edit an invoice record, then query the table directly (select * from audits where auditable_type like '%Invoice%') and inspect old_values, new_values, user_id, and event. If that query returns nothing meaningful, stop — you'll otherwise spend an hour debugging the Vue layer for a data problem.

Step 2 — install the tool. Nova comes from a private Composer repo, so auth.json or COMPOSER_AUTH must be provisioned in your shell and in CI before you try:

composer require devpartners/auditable-log

Step 3 — register it as a Nova tool in app/Nova/NovaServiceProvider.php:

public function tools()
{
    return [
        new \Devpartners\AuditableLog\AuditableLog(),
    ];
}

Step 4 — attach it to a resource detail view (this is what actually renders the panel):

public function fields(Request $request)
{
    return [
        // ... existing fields
        \Devpartners\AuditableLog\AuditableLog::make(),
    ];
}

Where to look first when the panel is blank: the resource detail view in the browser, then the Vue console and the network request the tool makes, then the audits rows for that exact auditable_type/auditable_id. Nothing useful will appear in storage/logs/laravel.log.

First use case: a half-day spike on a single low-risk internal model — Invoice, Ticket, Customer — on a throwaway branch. Success criteria: the panel renders on your Nova major, old/new values are legible, and user attribution is correct. Exit cost is one line removed plus composer remove, so the spike is nearly free.

Implementation Patterns

Attach per-resource, not globally. tools() only makes the tool available to Nova; the fields() attachment is your opt-in switch. Put it on resources where "who changed this and what did they change?" is a recurring support question — not on every model in the app.

Use fieldsForDetail() if you want a clean index view. Attaching in fields() can surface the tool in contexts you didn't intend. Scoping it to the detail view keeps index tables uncluttered:

public function fieldsForDetail(Request $request)
{
    return [
        // ...
        \Devpartners\AuditableLog\AuditableLog::make(),
    ];
}

Gate visibility through the Nova policy. The tool is read-only and inherits the resource's authorization; it adds none of its own. Express audience rules in the policy and pair with canSee():

public function view(User $user, Invoice $invoice): bool
{
    return $user->hasAnyRole(['admin', 'support', 'compliance']);
}

\Devpartners\AuditableLog\AuditableLog::make()
    ->canSee(fn (Request $request) => $request->user()->can('view', $request->resource)),

Complement it with a dedicated Audit Nova resource. The tool answers "what happened to this record." A separate Nova resource over OwenIt\Auditing\Models\Audit answers "who touched anything this week." Make the index filterable on event, auditable_type, user_id, and created_at. Together they cover the two real investigation paths; individually they don't.

Strip secrets at capture time, not display time. Whatever is stored is faithfully rendered to anyone with resource access:

// model
protected $auditExclude = ['password', 'remember_token', 'api_secret'];

// config/audit.php
'events'  => ['created', 'updated', 'deleted'],
'exclude' => ['created_at', 'updated_at', 'deleted_at'],

Also audit rows written before your exclusion rules existed — they're still in the table and still visible.

Pin Nova and this package as a unit.

"require": {
    "laravel/nova": "4.32.*",
    "devpartners/auditable-log": "2.0.2"
}

No carets here. The coupling is to Nova's tool registration contract and front-end component API; a loose constraint can silently resolve against a new Nova major and break the panel.

Fork for custom presentation. Need a compact inline changelog instead of the full panel? Fork the Vue component and register your own variant. It's a thin presentation layer with no data ownership, so forking is cheap — fork v2.0.2 specifically so you inherit the Nova 4 styling rather than the 2022 build.

Gotchas and Tips

"Aligns with Nova 4" is a styling claim, not a compatibility guarantee. v2.0.2 is a cosmetic refresh with no signal of testing against specific Nova releases. Treat first install as go/no-go: if Composer resolution forces a downgrade of Nova or owen-it/laravel-auditing, that's your answer.

CI fails before anything else at the Composer stage. Missing COMPOSER_AUTH looks like a package conflict but isn't. Verify credentials first when resolution errors appear in the pipeline.

Debugging is Vue-side. Blank or broken panel means: check compiled assets, the browser console, the network response for the tool's data fetch, and whether npm run dev/npm run build actually picked up the component after your last Nova update. The Laravel log is silent on all of this.

An unindexed audits table will degrade detail pages. Without a composite index on (auditable_type, auditable_id), a frequently-edited record makes the detail page slow or memory-hungry as history grows. Add the index, and test against realistic audit volume — not an empty dev table. Confirm whether the panel paginates at all before exposing it on high-churn models.

Coverage ≠ what you see. The panel confidently displays whatever Laravel Auditing captured. A model without the Auditable trait, or events excluded in config, produces a clean-looking but incomplete log — worse than no log if anyone treats it as authoritative during an incident review or compliance check.

The README's framing overstates what it is. The description markets it as an audit trail with automatic Eloquent tracking and configurable models; the code is a Nova display tool. Correct that mental model before someone scopes work off the tagline.

It is not an audit platform. No retention policy, no immutability/WORM storage, no alerting, no export, no advanced search, no certification. Regulated requirements need to be solved well beyond "show the log."

Extending means forking; there is no extension point. No published config, no hooks, no override surface. Given 51 stars, zero dependents, and a sparse release history since 2022, plan for "fork and own": budget one to two days a year in steady state, materially more around any Nova major upgrade. Tie a review to every Nova upgrade so drift is caught early.