Filament Todo Laravel Package

Getting Started

Treat the steps below as the expected path for a Filament v3 plugin, not as verified instructions — the supplied materials contain no README, so confirm each one against vendor/shibomb/filament-todo/ before you commit.

1. Check compatibility first. Open vendor/shibomb/filament-todo/composer.json (or the GitHub composer.json) and confirm the filament/filament and php constraints. Last release was 2023-10-04, which predates Filament 4, so assume ^3.0 until proven otherwise. If your panel is on Filament 4, stop here and plan to fork.

2. Install:

   composer require shibomb/filament-todo
   

3. Locate the plugin class. Look in vendor/shibomb/filament-todo/src/ for something like FilamentTodoPlugin or TodoPlugin, plus a Providers/ directory. That class name is what you register; do not guess it from the package name.

4. Register it on the panel (typically app/Providers/Filament/AdminPanelProvider.php):

   ->plugin(TodoPlugin::make())
   

   Filament 3 also supports ->plugins([...]). Register it on the admin/internal panel only — this is a back-office tool, not something to expose to end users.

5. Publish and migrate. Confirm the publishable tags before running anything:

   php artisan vendor:publish --provider="Shibomb\FilamentTodo\FilamentTodoServiceProvider"
   php artisan vendor:publish   # or list tags interactively
   php artisan migrate
   

   A resource with create/edit/delete implies a todos table; if migrations ship inside the vendor directory instead of a publishable stub, migrate will still pick them up — do not publish and keep vendor migrations, or you will get duplicate-table errors.

6. Clear the Filament caches and load /admin:

   php artisan filament:optimize-clear   # or filament:cache-components --clear
   php artisan view:clear && php artisan config:clear
   

First use case: the intended workflow is a single shared list of small follow-ups ("chase invoice", "renew cert") that would otherwise get lost between project trackers. Create one, verify the list view shows status/completion, then decide whether the defaults are enough before building anything around them.

Implementation Patterns

Use it as a stub, not a platform. The package gives you a resource and a table. Real teams need ownership, due dates, and links to domain records. The clean pattern is to extend rather than edit vendor code: subclass the resource, override form() / table(), and register your subclass while excluding the vendor resource from auto-discovery (Filament resolves resources by scanning app/Filament/Resources plus registered paths — check how the plugin registers its resource and override that path).

Scope to the current user. If there is no user_id column, add one via your own migration and override getEloquentQuery() to filter on auth()->id(). Without this, a "todo manager" on a shared admin panel becomes a shared whiteboard and people stop using it.

Multi-tenancy. Filament panels with ->tenant() will not magically scope the todo table. Add a tenant foreign key in your migration and constrain the query. If you skip this, todos leak across tenants — the single most damaging failure mode for a plugin like this.

Dashboard visibility. The whole point is not losing follow-ups. Add a TableWidget on the dashboard reading the same model with ->query(Todo::whereNull('completed_at')). That widget is what makes the package used; the resource page alone is a graveyard.

Authorization. Ship a policy for the todo model and register it. Filament respects policies on resources; without one, every panel user can delete everyone's items. canAccess() on the resource and ->visible() on the nav item are your levers if you want it admin-only.

Navigation placement. Set navigationGroup, navigationLabel, and navigationSort in your resource subclass (or via config, if the plugin exposes one) so it sits next to the Dashboard rather than at the bottom of the sidebar.

Enrich, don't fork, for fields. Common additions — due_at, priority, assignee_id, notes — are all additive migrations plus form/table schema in your subclass. Keep vendor views untouched; publish them only if you must restyle.

Don't build workflow on it. No queues, no events, no notifications are described. If you want reminders, write your own scheduled command and notification against the model rather than expecting the package to grow that.

Gotchas and Tips

• Effectively unmaintained. Three stars, zero dependents, last release October 2023. Budget for it being a one-off. Pin the exact version in composer.json and read the source before adopting; treat every upgrade as a manual review.
• The real cost/benefit question. A Filament resource with a migration, model, and form is roughly 100 lines. If you need tenancy, assignment, due dates, or policies — i.e. most of the above — writing it yourself may be cheaper than vendoring a 3-star dependency you will end up subclassing anyway. Adopt this package only if the out-of-the-box schema happens to match your needs.
• Publish tags are unknown. Run php artisan vendor:publish interactively rather than copying tag names from a blog post. Wrong --tag values fail silently in some Laravel versions.
• Published views and ja translations are a fork. v3.0.1 is explicitly "Layout & ja translations", so upstream churn lands exactly on the files you are most likely to have published. Diff your overrides on every update, or you will silently mask fixes.
• Missing translation keys render raw. If you publish lang/ partially or your locale is neither en nor ja, expect literal keys like filament-todo::todo.status.pending in the UI. Verify config('app.fallback_locale') and test in your actual locale.
• Cache staleness after deploy. Filament caches component/resource discovery. New or renamed resources that "don't appear" are almost always a component cache issue: php artisan filament:optimize-clear (or filament:cache-components --clear), then view:clear and config:clear.
• Duplicate migrations if you both publish and leave vendor migrations registered. Check php artisan migrate:status after the first run and remove one path.
• Debugging checklist when the nav item is missing: is the plugin registered on this panel provider; does php artisan route:list | grep -i todo show routes; does the policy's viewAny return true for your user; is the resource path registered.
• Extension points, in order of safety: (1) your own migrations, (2) resource subclass overriding form/table/query, (3) a policy, (4) published views, (5) editing vendor files — never the last one.
• Have an exit plan. Because the package is small and unmaintained, keep your customizations in app/ (subclass, migrations, widgets) so that ripping the dependency out later means deleting a composer require line and moving one resource class, not untangling patched vendor views.