Weave Code
Triage Bundle Laravel Package
novosga/triage-bundle
Symfony bundle that adds triage workflows to Novo SGA: configure service queues and priority rules, screen incoming attendances, and route tickets to the right desk. Integrates entities, forms, and admin screens for PHP/Symfony applications.
NovoSGA v2 triagem module.
Frequently asked questions about Triage Bundle
- Can I use novosga/triage-bundle in a Laravel app?
- Not directly. It is a Symfony bundle with no Laravel service provider, facades, or publishable configuration, so in-process registration in a Laravel app is not supported. The lower-risk approach is to run it inside its native Symfony 7.x context and call it from Laravel over a thin HTTP or queue contract. Reimplementing its triage and delay semantics natively in Laravel is possible but creates divergence you will have to maintain.
- Does novosga/triage-bundle ship a Laravel service provider or facade?
- No. The package contains no Laravel service provider, no facade, and no Laravel-native test harness. It is a domain module for the Novosga queue-management ecosystem built on Symfony full-stack. Any Laravel integration you see would be custom glue code you own, not something the package provides.
- How do I install novosga/triage-bundle?
- Install it with Composer in a Symfony application, then register the bundle in your Symfony kernel as you would any other bundle. You need PHP 8.2 or newer and a Symfony 7.x host. Pin an explicit version such as v2.3.0 rather than floating on a caret constraint so upgrades stay deliberate.
- Which Symfony and PHP versions does novosga/triage-bundle v2.3 require?
- Version 2.3.0 moves the bundle onto the Symfony 7.1 to 7.4 LTS line and requires PHP 8.2 or newer. That release also removes lingering compatibility with Symfony 6.x consumers. If your host is still on Symfony 6.4 LTS or PHP 8.1, you cannot take this version without a framework uplift first.
- What is the appointment max delay setting in the triage bundle?
- It is a new configuration surface added in v2.3.0 that governs scheduling and delay tolerance for appointments. It is an additive feature, so it should default to the previous behavior, but that default needs to be verified in your environment before rollout. Read the relevant pull request diff and confirm the effective default against v2.2.1 behavior.
- Why did appointment times change after upgrading the triage bundle?
- A timezone fix in v2.3.0 makes the bundle use the unit timezone when parsing scheduled appointment datetimes. For units whose timezone differs from the server default, appointments that were previously mis-parsed may now render at different times. Treat this as a behavior change and add regression coverage, at minimum one unit per distinct production timezone.
- How do I connect a Laravel application to NovoSGA triage workflows?
- Do not attempt in-process bundle registration inside Laravel. Run the bundle in its native Symfony 7.x service and expose a narrow HTTP or queue contract for the operations Laravel actually needs, such as creating appointments and reading priority rules. This preserves the upstream upgrade path and keeps the bundle's assumptions intact.
- Is novosga/triage-bundle actively maintained and safe for production?
- It shows maintenance-positive signals, including PHPStan 2, PHPUnit 11, and PHPCS 4 tooling, plus a real test suite and an uplift to Symfony 7.4 LTS. The governance picture is thinner: a single maintainer authored every change in the release, PR volume is low, and there is no vendor SLA, evident security policy, or LTS commitment for the bundle. Pin versions, review diffs, and own the upstream relationship explicitly.
- How do I test novosga/triage-bundle and my integration with it?
- Test the bundle inside a Symfony 7.x harness rather than inside Laravel, since it has no Laravel test scaffolding. Add a timezone matrix test covering every distinct unit timezone in production, and assert the max-delay default reproduces your pre-upgrade behavior. For a Laravel caller, add contract tests against the HTTP or queue boundary so schema and semantics changes surface early.
- What should I check before upgrading from v2.2.1 to v2.3.0?
- Pin to v2.3.0 and read the diffs for the timezone fix and the appointment max-delay feature specifically. Land Symfony 7.4 LTS and PHP 8.2 or newer on the host before or alongside the bump, and resolve the deprecation notices in the same change window. Then run behavioral verification, including the timezone matrix, before promoting to production.
Weaver
How can I help you explore Laravel packages today?