Panel Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a queue/service-desk back office. novosga/panel-bundle is the administrative/attendant panel layer of the NovoSGA ecosystem — the surface where units/branches, services, priority rules, attendants and roles are configured, and where tickets and attendance are monitored. The decision it informs is whether to ship an operator console ourselves or adopt an existing domain model.
• Roadmap scoping for an "operations console" epic. Any roadmap item involving walk-in ticketing, triage, priority weighting, counter assignment, or per-unit reporting is a candidate for reusing this instead of funding weeks of CRUD and RBAC work.
• Feasibility answers for sales/leadership. It makes "can we support multiple branches, multiple queues and role-scoped agents next quarter?" a configuration question rather than a headcount commitment.
• Use cases it directly enables: ticket issuance and triage, attendant/counter workspaces, supervisor dashboards, service catalogue administration, per-unit access control, and a modular dashboard with extension points for widgets and panel sections.
• Architecture constraints to decide early, not late. Despite being PHP with a Composer install path, this is a Symfony bundle, not a Laravel package — no service provider, no vendor:publish, no Blade, no facades. In a Laravel codebase, adopting it is a service integration decision: run it alongside as its own container/process and talk to it over HTTP, or accept the cost of a second framework runtime. That trade-off belongs in the decision memo, not the implementation ticket.

When to Consider This Package

Consider it when:

• You need a working back-office for queue/ticket operations and the NovoSGA domain model (tickets, services, priorities, attendance, units) matches your business process closely enough that configuration beats custom modelling.
• You are willing to operate the panel as a separate service with its own Composer root and its own release cadence — the recommended shape for a Laravel shop — rather than embedding it.
• You need multi-unit, multi-service, role-differentiated administration: tedious to build, rarely differentiating, and a poor use of product engineering time.
• You can absorb owning the upgrade path: pin an exact tag, keep template overrides in a small version-pinned overlay, and budget a review each release.

Look elsewhere when:

• You are Laravel-first and need the admin UI to share your Eloquent models, auth guards and policies directly. A Filament/Livewire panel over your existing schema will be cheaper to own and far easier to hire for.
• Your requirements are genuinely simple (one queue, a handful of services) — the cross-runtime integration overhead exceeds the value.
• You need vendor-backed support, a published security policy, or a formal LTS/deprecation commitment. Community-maintained, MIT, no dependents, zero stars: assume you are on your own.
• You cannot verify what v2.3.0 actually changed. The release notes are a bare link to the commit history — no itemised features, fixes, breaking changes or migration notes. For a minor bump that is probably non-breaking, but "probably" is not an upgrade plan. Treat the release as unverified until someone reads the diff: constructor signatures, container aliases, config keys, Twig/theme overrides (where panel bundles break silently), and new Doctrine migrations.

Decision hygiene either way: run a time-boxed spike — stand the panel up in its own Composer root against the NovoSGA schema, log in as an attendant, and confirm your app can create a ticket that appears in the panel. That single end-to-end seam is the real integration risk; everything else is packaging.

How to Pitch It (Stakeholders)

For executives (one paragraph):

We are evaluating NovoSGA's admin panel bundle as the back office for our queue and service-desk operations. It gives us a working operator console — ticketing, triage, priority handling, multi-branch and role-based administration, and a modular dashboard — instead of building that ourselves, which is the low-differentiation, high-maintenance part of the product. Two caveats shape the recommendation. First, it comes from the Symfony ecosystem, so in our Laravel stack it runs as a companion service rather than a drop-in library, which means a modest ongoing operational cost. Second, support is community-based, and the v2.3.0 release shipped without an itemised changelog, so we cannot yet say precisely what changed. Recommendation: fund a short, time-boxed spike to validate fit against our service model and prove the ticket-creation integration end to end — a fit decision, not a commitment to adopt on the strength of release notes alone.

For engineering (the framing they need):

v2.3.0 is a minor bump with no published release notes beyond a changelog link — your first task is reading the diff, not upgrading. Specifically: (1) diff the public API for signature and service-definition changes; (2) diff the template/theme layer, since panel bundles are usually customised at the view level and that is exactly where minor bumps break silently; (3) check for new Doctrine migrations and required config keys; (4) confirm the PHP and symfony/* / novosga/core-bundle constraints before touching any composer.json. Do not install this into the Laravel app — Laravel pins its own Symfony components and the bundle pins its own; separate Composer roots solve that permanently. The integration shape is "run alongside, talk over an HTTP boundary": a small NovosgaClient behind an interface with configured base URI, timeout and retry, so it can be faked in tests and never called straight from controllers. Sync attendant records from Laravel out to NovoSGA's usuario table (scheduled job or user-created listener) rather than duplicating auth; scope cookies and X-Forwarded-* headers deliberately, or cross-app auth will fail silently. For queue data inside Laravel, poll into local read-model tables — never join across to their schema. Debug in Symfony's profiler and var/log/dev.log, not storage/logs/laravel.log. Assume we own this dependency: pin the exact tag, keep the override surface small and documented, and answer the data-ownership question — who owns tickets, us or the panel? — before writing code.