Weave Code
Tomato Hr Module Laravel Package
tomatophp/tomato-hr-module
An HR management module for Tomato PHP and Laravel that adds HR tools to your admin panel, helping you manage employees, departments, and related records. Integrates with the Tomato ecosystem and Filament for a ready-to-use HR workflow.
HR management system for TomatoPHP
Frequently asked questions about Tomato Hr Module
- What does tomatophp/tomato-hr-module actually do?
- It is a vertical HR domain module for the TomatoPHP ecosystem, shipping Filament resources, migrations, models, policies, and seeders for HR primitives such as employees, departments, job titles, attendance, and leave requests. It is a presentation-and-schema layer for a TomatoPHP or Filament admin panel, not a standalone HR library. Most of its value comes from running inside that admin surface.
- How do I install tomato-hr-module in a Laravel app?
- Run composer require tomatophp/tomato-hr-module, register the service provider, publish the config and migrations with php artisan vendor:publish, then run php artisan migrate. After that, seed the module's permission set, create or assign a user, and load the module routes in your panel. In a clean Laravel plus Filament app this is roughly a one-day proof of concept.
- Which Laravel and PHP versions does tomato-hr-module support?
- The documented strong fit is Laravel 10 or 11 with PHP 8.1+ and Filament 3.x. Always confirm this against the composer.json constraints at the tag you install, because the module pins its TomatoPHP siblings loosely by default. If you are on Laravel 9, PHP 8.0, or Filament 2.x, treat it as unsupported until you verify.
- Do I need Filament and the TomatoPHP admin panel to use this module?
- Yes, effectively. The module is bound to tomato-admin and Filament conventions, uses tomato-utils helpers, and typically relies on tomato-settings for configuration and tomato-roles for ACL. In a bespoke Blade or Livewire admin, or an API-first Laravel backend with no admin surface, you would inherit migrations and models wrapped in a rendering framework you do not run. That makes it a poor fit outside the TomatoPHP stack.
- Does tomato-hr-module create its own users table or reference my existing User model?
- This is one of the open questions to resolve before installing. The module ships migrations for employees and departments, but whether it owns the users relationship or references an existing model through config is not clearly documented. Inspect the published migrations and config first, because HR schema reconciliation with your existing users, org structure, and payroll data is where the real effort sits.
- How does authorization work in tomato-hr-module?
- Authorization typically rides on spatie/laravel-permission combined with the TomatoPHP roles module, and the package seeds a permission set for its resources. Whether access is enforceable per resource via Laravel policies or only through route middleware is not verified in the current release notes. Confirm this before exposing employee records to non-admin roles.
- Is there an API or JSON endpoint, or is tomato-hr-module Filament-only?
- There is no documented API or JSON surface; the module is designed around Filament admin screens. If you need mobile apps, integrations, or a headless frontend, plan to build your own controllers and resources on top of the module's models. An API-first architecture is explicitly a weak fit for this package.
- Is tomato-hr-module v1.0.0 stable, and what changed from the pre-1.0 tags?
- Treat 1.0.0 as a label rather than a compatibility guarantee. The release note is a single changelog URL with no entries, so there is no migration guide and no stated breaking changes. Review the commit history for renamed tables, columns, or Filament resource paths before upgrading an existing install.
- Can I use tomato-hr-module for multi-tenant SaaS or GDPR-sensitive employee data?
- The module does not natively model tenancy, so per-tenant schema or data isolation must be wrapped around it yourself. HR records are high-integrity, personally identifiable, and frequently audited, so check whether soft deletes and audit columns ship by default or must be bolted on. For anything employee-facing, the single-maintainer bus factor and ecosystem coupling are procurement questions, not just technical ones.
- What happens if I customize the published migrations, and how do I keep up with upstream?
- The module uses publishable migrations and config-driven table and route prefixes, so copying and editing migrations creates a fork you own forever. Upstream changes then become manual merges, and a patch release in any TomatoPHP sibling such as tomato-admin, tomato-utils, or tomato-roles can break the module. Pin your dependency versions and keep a diff of your schema changes against upstream.
Weaver
How can I help you explore Laravel packages today?