Users Table Laravel Package

Product Decisions This Supports

Read this first — evidence conflict. The package self-describes in Russian as "Модуль табельного учета пользователя" (a user timesheet/attendance-accounting module), and its own install instructions use bin/console, doctrine:migrations:diff, and doctrine:migrations:migrate. That is a Symfony/Doctrine footprint, not a Laravel one. The Laravel-flavored examples in the supplied assessment notes (UsersTable::recordAttendance(), php artisan vendor:publish, Blade overrides, Eloquent scopes) do not appear in the package's own README and should be treated as unverified until an engineer confirms them against the source. Do not let those examples drive scoping.

What this legitimately informs:

• Build vs. buy, narrowly scoped. One candidate implementation for a timesheet/attendance capability (presence, absences, periods) that sits alongside an existing user entity. It is a schema + domain module, not an HR product: no evidence of scheduling, approvals, payroll export, biometric ingestion, or reporting UI.
• Roadmap sequencing. If we already run a BaksDev/Symfony service, this could shorten the "we need a timesheet table plus basic recording" milestone. If we run Laravel, adopting it means either porting the domain or running a second framework runtime — a decision that belongs in architecture, not in a feature ticket.
• Use cases worth validating. Internal ops attendance logs, contractor day-rate tracking, site/office presence records for a back-office admin tool. Explicitly not supported by the docs: multi-tenant isolation, real-time or offline sync, geolocation, audit-grade retention.
• Buy-in cost is near zero, but so is leverage. MIT license, PHP 8.4+, no commercial terms to negotiate. That makes it low-friction to trial and low-consequence to abandon — which is the strongest argument for a two-week spike rather than a commitment.

Decision this actually gates: "Do we adopt, fork, or hand-roll the timesheet schema?" The answer depends almost entirely on one unanswered question — is our target service Symfony/BaksDev or Laravel? Everything else is secondary.

When to Consider This Package

Consider it when all of these hold:

• The consuming application is BaksDev / Symfony + Doctrine (or we are willing to run that stack). This is the hard filter.
• We need structured per-user attendance records — the boring, high-value 80%: who was present, absent, or on leave, on which dates, with history queries.
• The requirement is internal, low-blast-radius: an admin-facing back-office tool where a wrong record is a correction, not a compliance incident.
• We can absorb vendor risk with a fork: 0 stars, 0 dependents, single maintainer, one release note (v7.4.3) that says nothing but the version. Assume the maintainer may vanish; budget for owning the code.
• The team has PHP 8.4+ in place and can run Doctrine migrations safely against an existing schema.

Look elsewhere when any of these are true:

• We are a Laravel shop. The docs give no Laravel service provider, config publishing, or Eloquent integration — only Symfony console and Doctrine commands. The facade/artisan snippets circulating in internal notes appear to be invented, not sourced. Treat "Laravel package" as an unvalidated claim.
• We need anything beyond record-keeping: shift scheduling, overtime rules, approval workflows, payroll/time-billing export, integrations (Slack, HRIS, biometric devices), mobile or offline capture.
• Compliance is load-bearing: GDPR retention/deletion semantics, works-council or labor-law reporting, audit trails with immutability. None of that is documented.
• Multi-tenancy or multi-entity is required — no evidence of tenant-aware migrations.
• We need a supported dependency. 0 stars / 0 dependents / single maintainer / no changelog substance is not a supply chain we can lean on for a revenue-adjacent feature.
• Documentation is our onboarding path. The README is Russian-only, ~40 lines, and covers install and a test group. Everything else is code archaeology.

Practical next step before any commitment: a one-day engineering spike that (a) confirms framework and ORM, (b) dumps the actual schema and public API surface, and (c) reports how much of the documented behavior in our internal notes is real. Kill or greenlight on that output.

How to Pitch It (Stakeholders)

To executives: "There's a small open-source module that provides the database and core logic for tracking employee attendance — the timesheet backbone behind an internal ops tool. It's MIT-licensed and free, so the cost question isn't price, it's fit: its documentation shows Symfony, not Laravel, and it's maintained by a single author with no visible user base. My recommendation is a scoped, time-boxed evaluation — about a week of engineering — to confirm it works in our stack. If it does, it saves us building the data model and migrations from scratch. If it doesn't, we've spent a week and we build the same thing ourselves with full ownership. I'm not asking to bet the roadmap on it; I'm asking to spend a week deciding."

To engineering: "Proposed for evaluation only, not adoption. Facts: MIT, PHP 8.4+, v7.4.3 released 2026-06-01, 0 stars, 0 dependents, single maintainer, Russian-only README, Symfony console and Doctrine migration commands. The internal notes floating around with a UsersTable facade, php artisan vendor:publish, and Blade overrides are not from the package's documentation — please don't scope against them. What I need from a one-day spike: confirm the framework/ORM, dump the real schema and public API, tell me whether the migrations are safe to run alongside our existing users table, and give me a rough number for what it would take to fork and own. My prior is that this is a reasonable schema to borrow and a risky dependency to adopt — if that's what you find, say so and we'll hand-roll the equivalent in a fraction of the time it'd take to work around a foreign framework."