Weave Code
Tartarus Laravel Package
lara-zeus/tartarus
Tartarus is a Laravel package from Lara Zeus for adding access control to your application. It offers a clean, configurable setup that fits Laravel’s authorization conventions and keeps role and permission management straightforward.
Lara Zeus Tartarus is a Laravel package that adds a practical trash/recycle-bin workflow for Eloquent records. It helps you archive deleted data safely, restore it when needed, and purge it on your terms—without building custom soft-delete logic.
- Seamless Eloquent integration for archiving and restoring models
- Configurable retention and pruning for stale records
- Safe permanent deletion with explicit controls
- Laravel-native configuration, migrations, and APIs
Frequently asked questions about Tartarus
- What does lara-zeus/tartarus actually do?
- Tartarus adds a trash or recycle-bin workflow on top of Laravel's SoftDeletes trait, so deleted Eloquent records can be reviewed, restored, or permanently purged instead of disappearing immediately. It is an administration-surface package rather than infrastructure: it does not change how your models persist data, it just gives you configurable tools for archiving and restoring them. Lara Zeus packages are generally Filament-oriented, so the bin UI is typically surfaced through a Filament admin panel. If you only need the data layer, Laravel's built-in SoftDeletes already does that part.
- How do I install lara-zeus/tartarus in a Laravel application?
- Install it with Composer, then publish the package config and migrations and run migrate, following the same publish-and-migrate pattern as other Lara Zeus packages. After that, attach the package trait to one soft-deletable model, delete a record from tinker, and confirm it appears in the bin and restores cleanly. Treat that sequence as a half-day go/no-go gate before wiring it into a real feature. Read the published config end to end, because it is the honest API surface for retention, model discovery, and pruning.
- Do I need Filament to use lara-zeus/tartarus?
- The documented shape of the package is a Filament-native recycle bin over soft-deleted Eloquent records, so the value it adds is mostly realised inside a Filament admin panel. If your support or admin surface is already Filament-based, this package is family-coherent with shared conventions and upgrade cadence. If it is not, adopting Tartarus is really part of a much larger decision to adopt Filament, and should be framed that way up front rather than discovered mid-sprint. Without Filament you may be better served by writing a thin controller and views over Laravel's own SoftDeletes.
- Which Laravel and PHP versions does lara-zeus/tartarus support?
- Version support is defined by the constraints in the package composer.json and by its Filament dependency line, so check those files rather than assuming. The genuine coupling is to Filament's major version and to Laravel's soft-delete semantics, both of which move over time. Because the package is small and has few dependents, an upgrade to a new Laravel or Filament major may lag until someone fixes it. Pin your versions and run the restore and force-delete paths in CI after every framework upgrade.
- Does Tartarus keep its own table or rely on Laravel's deleted_at column?
- This is the single fact that determines your whole integration strategy, and you should confirm it by reading the source rather than the README. If the package leans on deleted_at, restoring is a column flip and your existing global scopes still apply. If it maintains its own archive table, you are dealing with a data copy, which changes query behaviour, index usage, and how you handle relations. Check for raw DB::table calls and any withoutGlobalScopes usage while you are in there.
- How does retention and pruning of old trashed records work in Tartarus?
- Retention window and pruning behaviour are configured in the published config file, which is where the real knobs live. That means you can decide how long stale records remain recoverable before they are permanently removed, and schedule the pruning to match your data-retention policy. Confirm the pruning runs as a scheduled command or job you can hook into, and test it against realistic volumes before enabling it in production. For regulated or financial data, align the retention window with your compliance obligations rather than the package default.
- What happens if a unique constraint collides when restoring a Tartarus record?
- Restoring a soft-deleted record only clears deleted_at, so a unique index can still fail if another row has since claimed the same value. A common example is deleting a user with [email protected], having someone re-register with that address, and then trying to restore the original. The package cannot resolve this for you, so you need a per-model policy: block the restore with a clear notification, merge the records, or suffix the conflicting value. Handle it explicitly in your restore action rather than letting a database exception surface to the admin user.
- Is force delete safe to use in production with Tartarus?
- Force delete is the most dangerous button in an admin panel, so treat it as a privileged domain operation rather than a convenience action. Gate it behind an authorization policy, require a type-to-confirm modal, and log who purged what and when. For financial or regulated records, consider making permanent deletion unavailable in production or requiring a second approver. Also review relation and cascade behaviour before shipping, since a purge can silently orphan or remove dependent rows.
- Does lara-zeus/tartarus respect tenant scoping in a multi-tenant app?
- Repository metadata mentions multi-tenancy, but that appears to be stale: the documentation describes a Filament recycle bin over soft deletes, which is an entirely different product with a different risk profile. Confirm by reading src/ before it enters a planning document; if tenancy is your actual requirement, look at stancl/tenancy or spatie/laravel-multitenancy instead. If your app is multi-tenant and you still adopt Tartarus, grep the source for withoutGlobalScopes, withoutGlobalScope, and raw DB::table calls, because admin tooling often bypasses global scopes. A support user restoring a record outside their tenant boundary is the highest-severity risk in the whole evaluation.
- Is lara-zeus/tartarus actively maintained, and what are the alternatives?
- The package is small with very few dependents, and recent changelog entries look like dependency bumps and compatibility fixes rather than hardening, which means your test suite will be the first to hit the edge cases. That is not disqualifying for a thin admin helper, but budget time for reading the source and writing coverage around restore and force delete. The main alternatives are Laravel's native SoftDeletes plus a hand-rolled admin screen, or Filament's own soft-delete and restore table actions if you are already on Filament. If you need tenancy rather than a recycle bin, use stancl/tenancy or spatie/laravel-multitenancy.
Weaver
How can I help you explore Laravel packages today?