- What does mykholy/mavvix-safe-actions actually do?
- It is a Laravel package that adds a reusable, fail-closed action pattern for Filament 5 bulk actions, wrapping business logic in verified selections, expiring preflights, authorization checks and transactional execution. The goal is to keep admin workflows consistent and safe so a denied or invalid request never partially applies changes. It is intentionally scoped to bounded, database-only Eloquent actions on a single database connection.
- How do I install mavvix-safe-actions in a Laravel app?
- Install with composer require mykholy/mavvix-safe-actions:^1.0, then publish the package migrations and run php artisan migrate. If Packagist indexing is not yet available, use the documented VCS repository installation path instead. Always review the generated migrations in a non-production environment before promoting them to staging and production.
- Which Laravel, PHP and Filament versions are supported?
- The package targets Laravel applications running Filament 5 admin panels, and the exact Laravel and PHP constraints are declared in its Composer requirements. Because the constraints are authoritative, verify them against your application's Laravel and PHP versions before adopting. Also confirm your Filament 5 panel configuration matches the package's documented assumptions.
- How does the package enforce fail-closed authorization and selection?
- Selections are verified and a preflight step is issued with an expiry before the action body executes, and authorization is evaluated as part of that flow so the default outcome on any failure is denial rather than partial execution. If a check fails or a preflight expires, the action does not proceed to mutate data. The practical risk is misconfiguration: if your policies or gates are too permissive, the package will faithfully allow what your authorization layer allows, so review policy definitions carefully.
- Does it support multi-tenant apps and multiple database connections?
- The package is tenant-aware but deliberately scoped to a single database connection, so all critical state changes must occur inside one transaction boundary on that connection. That fits many internal admin and tenancy setups, but it is not a fit for architectures where actions must span several connections or cross-database writes. Validate that the one-connection scope matches your tenancy and database architecture before converting existing actions.
- What happens if a bulk action sends emails, dispatches jobs, calls APIs or writes files?
- Only database work on the single supported connection is covered by the transaction boundary, so external side effects are not transactionally reversible. If your action triggers notifications, queued jobs, payments or third-party API writes, a rollback will not undo those effects. Keep such side effects outside the transactional action, or dispatch them only after the transaction commits successfully.
- Does mavvix-safe-actions provide audit logs or action traces?
- The documented scope centres on verified selections, expiring preflights, authorization and transactional execution rather than a built-in audit trail. If you need an action history, plan to add your own logging or model event listeners around the action boundary. Confirm current behaviour against the package README before promising auditability to stakeholders.
- How long do the transactions run and what is the locking profile?
- Transaction duration depends entirely on the work you put inside your action body, so keep that body as short and database-focused as possible. Long-running actions hold locks for longer and increase contention in realistic admin usage. The package has not been load-qualified in production-like conditions, so run a staging pilot with representative data volumes and measure before wider rollout.
- How do I test actions built with this package?
- Because the pattern separates validation, authorization and execution, you can assert authorization denials, expired preflights and rollback behaviour as distinct test cases. Write tests that confirm nothing is persisted when a check fails, and tests that confirm the full commit path on success. Use a database transaction or refresh strategy in your test suite so each case starts from a known state.
- Is v1.0.1 a breaking change from v1.0.0, and is it production ready?
- v1.0.1 is a distribution and documentation patch over v1.0.0 with no changes to runtime PHP classes, selection behaviour, authorization logic, schema or public method signatures, so existing v1.0.0 integration assumptions still hold. On production readiness, the package has a documented first-party security review but no independent security sign-off, no human screen-reader certification and no production-like load qualification, so judge whether that meets your internal risk threshold or requires independent review first. Pin to ^1.0 and track releases for future security or runtime changes.