Revise Operation Laravel Package

Getting Started

• composer require backpack/revise-operation — this pulls in venturecraft/revisionable as its engine. Check the version matrix against your Laravel/Backpack version first; revisionable is the slower-moving dependency and is usually the blocker. Aim for ^2.1.2 (see Gotchas — earlier 2.1.x releases don't validate the revision before restoring).
• Publish and run revisionable's migration: php artisan vendor:publish --provider="Venturecraft\Revisionable\RevisionableServiceProvider" then php artisan migrate. Without the revisions table the operation renders, but every save silently has nowhere to write.
• Add the trait to the model you want audited: use Venturecraft\Revisionable\RevisionableTrait; alongside CrudTrait.
• Add the operation trait to the matching CRUD controller: use Backpack\ReviseOperation\ReviseOperation;.
• Where to look first: the revisions table and the published config/revisionable.php, then vendor/backpack/revise-operation/src/ — the operation class and its views are small and readable in one sitting.
• First use case: open an entry, change a field, go back to the list, click the "Revise" line button, and confirm a row appears with old value, new value, user, and timestamp. Then hit revert and check that a new revision was created rather than the old one being deleted.

Implementation Patterns

• Register the operation only on controllers where an audit trail is meaningful; it lives alongside your List/Update/Show operations in the controller.
• Scope what's tracked per model with protected $revisionableFields = [...], plus $revisionableKeepUnversioned and $revisionableLimit. The default is every column, which is almost never what you want.
• Control access through Backpack operations: $this->crud->denyAccess('revise') per profile, or wire the revise operation name into PermissionManager. Gate the line button too, so users don't see a button that 403s.
• Causer resolution: revisionable falls back to the authenticated user. On a non-default guard or a custom admin model, set the config/user deliberately so the "who" column isn't permanently empty.
• Reverting goes through save(), so observers, casts, validation, and model events all fire. Usually desirable — you get a fresh revision row and consistent behaviour — but watch for side effects like notification emails triggered by reverted state.
• Publish the views (--tag=views) to change columns, formatting, or branding rather than forking the package; the operation is thin enough that small view edits cover most customisation needs.
• Pair with soft deletes for "restore this record" plus field history; revisionable has its own revisionableSoftDeletes handling if you need the two to cooperate.
• Plan a periodic prune. Revisions grow linearly with every save, and the revise list view isn't built for years of history on a busy record.

Gotchas and Tips

• 90% of your actual configuration lives in venturecraft/revisionable, not in this package. When something looks wrong — missing rows, wrong user, fields not tracked — debug there first.
• Pin ^2.1.2 as a floor. Prior versions restored whatever revision ID was passed without checking the revision's type or that it belonged to the record being edited; 2.1.2 adds that validation before restoring. If you're on 2.1.0/2.1.1, upgrade rather than working around it — it's a small patch with no config changes.
• 2.1.2 also pins dependency versions in the package's own composer file, so composer update is less likely to drift revisionable underneath you. That cuts both ways: you'll no longer get incidental transitive bumps, so still verify the revisionable/Laravel matrix yourself after a major Laravel upgrade.
• Never track password or hash columns; they'll be written verbatim into the revisions table.
• JSON and cast columns are stored as strings. Reverting reapplies your model casts, so formatting can round-trip differently than you expect.
• Custom primary keys (UUID/ULID) work as long as the migration's revisionable_id type matches and route-model binding resolves; check both when the revise page 404s. The 2.1.2 type/ownership check makes a mismatched key more likely to fail loudly on revert rather than silently writing the wrong data — treat a new rejection here as a signal your key configuration is off.
• The revert flow operates on field changes as displayed in the revise view, not necessarily a full "restore the whole snapshot" — verify the semantics against your own data before promising users "undo everything from that edit."
• Trait ordering on the model: RevisionableTrait registers boot hooks. If you add other booting traits later, re-test that saves still write revisions.
• This is a low-traffic, low-maintenance package. Pin the version, and if the revisionable dependency won't move to your Laravel version, spatie/laravel-activitylog plus a small custom Backpack operation is the natural replacement.
• When in doubt, query the table directly (select * from revisions where revisionable_id = ?) — the UI is thin enough that the table is the source of truth for what was actually recorded.