Weave Code
Tomato Hr Laravel Package
tomatophp/tomato-hr
tomatophp/tomato-hr brings HR management to your TomatoPHP Laravel admin panel. Manage employee records, departments, and core staff workflows with a simple, extendable structure—a practical starting point for building custom HR features in your app.
HR management system for TomatoPHP
Frequently asked questions about Tomato Hr
- How do I install tomatophp/tomato-hr in a Laravel app?
- Installation most likely follows the standard TomatoPHP pattern: composer require tomatophp/tomato-hr, register the service provider, then run vendor:publish for the config and migrations. That path is a hypothesis based on family conventions, not a documented procedure, because the v1.0.0 release supplies only a changelog URL with no enumerated steps. Confirm the exact provider name, publish tags, and migration ordering by reading the package source in a timeboxed spike before committing to an integration.
- Does tomatophp/tomato-hr require Filament?
- TomatoPHP packages are generally UI-forward, using Filament resources or plugins to surface the domain as an admin panel rather than exposing a headless API. For an HR domain of employees, departments, and staff workflows, that pattern fits naturally if you already run Filament v3. If your app is not on Filament, adopting this package can effectively drag a Filament dependency into your stack, so settle that architectural question first. The v1.0.0 release notes do not explicitly confirm the Filament requirement, so verify it in the package composer.json.
- Which Laravel and PHP versions does tomato-hr support?
- There is no published compatibility matrix at v1.0.0, so treat any version claim as unverified. The TomatoPHP family conventionally targets Laravel 10 and 11 on PHP 8.1 or newer with Filament v3, which is the best-fit stack, but you should read the composer.json constraints to confirm. If you are on an older Laravel or PHP version, check before installing rather than after.
- What features are included in tomato-hr 1.0.0, and is payroll covered?
- The package overview describes employee records, departments, and core staff workflows, positioned as a practical starting point for custom HR features. Whether payroll is in scope is not documented, and the changelog link is not an actual changelog, so there is no feature inventory, schema overview, or scope statement to rely on. Confirm which sub-domains exist at 1.0.0 during a spike, and if payroll matters, determine whether the package computes figures or merely stores them.
- Will tomato-hr work with my existing users table and authentication?
- This is the highest-risk integration question. TomatoPHP modules frequently depend on shared siblings such as tomato-admin, tomato-settings, tomato-users, and tomato-locations for identity, authorization, and localization, which can constrain your user model and permission scheme. Determine whether the package owns the users relationship or adapts to an existing model before you install it into a bespoke app. If you already have a customized users table and policy or Gate setup, feasibility drops from high to moderate or poor.
- Are the migrations published and editable?
- TomatoPHP packages normally publish config and migrations via vendor:publish, which would make the schema editable, but that is unconfirmed for this release. The answer matters because HR data such as employment records and compensation is high-sensitivity and often long-retention, so you need control over soft deletes, audit trails, and PII handling. Check whether migrations are published or package-loaded and opaque before you build on the schema.
- Does tomato-hr expose a headless API, or is Filament the only interface?
- No headless or API surface is documented at v1.0.0. Packages in this family are typically UI-forward, with Filament serving as the primary or only interface, so an API-first architecture is unlikely out of the box. If you need programmatic access for integrations or a separate frontend, plan to build that layer yourself and account for it in your estimate.
- How should I test tomato-hr before using it in production?
- Run a timeboxed spike in a staging copy of your database, not against production data. Verify migration ordering alongside your existing tables, confirm how permissions and policies integrate, and exercise the Filament panel against your user model. Also test whether the package adapts to your existing auth or imposes its own. Because there are no published test docs, your spike is the only reliable evidence you will get before adopting.
- Is tomato-hr production-ready, given it is tagged 1.0.0?
- A 1.0.0 tag asserts semantic versioning stability, but a first release has no track record behind that assertion, so do not read it as battle-tested. The package family also carries single-maintainer or small-team risk, which is relevant for anything touching payroll-adjacent data. Ecosystem lock-in is a real concern because shared TomatoPHP dependencies can be difficult to unwind later, and exit cost is asymmetric. Price that risk in up front rather than after the integration ships.
- When should I choose tomato-hr over alternatives?
- Best fit is a Laravel 10 or 11 app on PHP 8.1+ with Filament v3, a greenfield or lightly customized admin, and a team comfortable with TomatoPHP conventions. If you are already in that ecosystem, the architectural fit and familiar HR domain make it a reasonable starting point. If you are not on Filament, or you need a documented feature matrix and a strong maintenance commitment, building employee and department resources directly on Filament or choosing a larger HR suite is likely safer. Also ask the maintainers about release cadence, the authorization model, and PII and audit posture before committing.
Weaver
How can I help you explore Laravel packages today?