Tomato Pms Module Laravel Package

Getting Started

• Require the module with composer require tomatophp/tomato-pms-module, then run the module's installer (php artisan tomato-pms:install) which publishes config, migrations, lang files and assets in the standard TomatoPHP way.
• Look first at: config/tomato-pms.php (table names, model bindings, feature toggles), src/Providers/TomatoPmsServiceProvider.php (what gets registered, published and loaded), database/migrations/ (the actual schema you'll be extending), and src/Filament/ (the resources/pages your panel exposes).
• Register the module with your panel — either through the Tomato modules/plugins registry used by tomato-admin, or by adding the module's plugin to your PanelProvider — and confirm the PMS navigation group appears.
• First use case: php artisan migrate, open the PMS resources in the panel, create one record end-to-end (project → related items) to verify policies, tenancy and media/attachment handling before wiring anything custom.
• v1.0.1 adds a generate command. Discover it with php artisan list | grep tomato-pms rather than guessing the signature, then run php artisan help <command> to see its arguments and options.

Implementation Patterns

• Scaffold-then-customise. Treat the new generate command as a starting point: generate the resource/page/model stub, commit the generated file untouched, then diff your edits against it on the next upgrade. This keeps future regenerations reviewable.
• Extend, don't fork. Subclass the module's Filament resources and models and rebind them in config/tomato-pms.php (or via the container) instead of editing vendor files. Overriding a resource's form()/table() in a subclass is the cheapest way to add company-specific fields.
• Cross-module composition. TomatoPHP modules are designed to be stacked — resolve the PMS models from your own services and attach relationships (users, teams, tasks) via traits and pivot tables rather than duplicating schema. Check sibling modules for existing contracts before creating new ones.
• Policies and tenancy. Register policies in your app's AuthServiceProvider (or let the module do it) and scope queries by tenant/team at the repository or global-scope layer if the module doesn't already do it for you.
• Config-driven behaviour in tests. Use config()->set('tomato-pms.…', …) in test setUp and RefreshDatabase against published migrations so generated resources can be feature-tested with Livewire's assertCanSeeTableRecords helpers.
• Generator as a team convention. Once the command exists, wrap it in a composer script or a small internal command that applies your house style (strict types, enum casts, policy stub) so scaffolding stays consistent across the team.

Gotchas and Tips

• Migrations double up. Package migrations are usually loadMigrationsFrom-ed; if you also publish them you can get duplicate-table errors. Decide once: publish (editable) or load-from-package (upgrade-friendly).
• Config cache staleness. After upgrading, run php artisan config:clear && php artisan optimize:clear and re-publish assets — a stale bootstrap/cache/config.php is the most common cause of "my config change does nothing".
• Generators overwrite. Verify whether the new generate command prompts before clobbering existing files, and whether a --force flag exists. Never run it blindly on a branch with uncommitted work.
• Filament version pinning. TomatoPHP modules move with Filament majors; check the module's composer.json constraints against your panel version before upgrading, and re-test resources after any Filament bump.
• Naming collisions. Generic class names (Project, Task, Comment) collide easily when stacking modules — alias imports or namespace your own models, and check for duplicate Filament resource slugs.
• Translations and RTL. Publish lang files before overriding labels; the module ships translations you'll otherwise silently lose on the next vendor:publish.
• Debugging hook. When a resource doesn't appear, check panel plugin registration first, then policy/authorisation, then the module's config toggles — in that order. php artisan about plus the module's provider boot order usually reveals the culprit.
• Upgrade ritual for v1.0.1. It's an additive minor release (new command only), so no breaking changes expected — but still run the full suite after composer update, since vendor publish tags can shift generated stubs.