Weave Code
Triagem Bundle Laravel Package
novosga/triagem-bundle
Symfony bundle from Novo SGA that adds triage capabilities to service-desk workflows, helping classify and prioritize attendance requests so they can be routed to the appropriate services and queues.
NovoSGA v2 triagem module.
Frequently asked questions about Triagem Bundle
- Is novosga/triagem-bundle a Laravel package?
- No. It is a Symfony bundle from the Novo SGA queue and triage ecosystem, and it ships Symfony DI extension classes and a bundle configuration tree rather than Laravel package discovery, facades, or publishable config files. In a Laravel app you cannot rely on auto-discovery; you would need to register its services manually or build an anti-corruption layer. Treat it as a domain library first, not a Laravel plugin.
- How do I install novosga/triagem-bundle in a Laravel application?
- Run composer require novosga/triagem-bundle, but expect manual wiring: register the underlying services in a Laravel service provider, map the bundle configuration keys into config files by hand, and do not assume Laravel's container can resolve Symfony compiler passes. Validate the new Appointment max-delay setting explicitly. The assessment recommends a spike in a non-production branch before committing.
- Which Laravel versions does this package support?
- Laravel version support is not the right axis, because the package is Symfony-targeted and its constraints track Symfony and PHP, not Laravel. The 2.3.0 release aligns with Symfony 7.4 LTS and PHPUnit 11, which implies PHP 8.2 or newer, but you should verify composer.json rather than infer. Any Laravel version running on a compatible PHP version could host it only after custom service wiring.
- What PHP version does novosga/triagem-bundle require?
- Symfony 7.4 and PHPUnit 11 both imply PHP 8.2 or newer, but the authoritative answer is in composer.json. Verify the runtime PHP constraint before planning adoption, especially if your Laravel estate still runs PHP 8.1. Do not infer the floor from the changelog alone.
- What does the Appointment max delay configuration setting do?
- Appointment max delay is a new configuration setting in 2.3.0, but the release notes do not describe its default, unit, or boundary behavior. The highest-impact unknown is whether the default preserves prior behavior with no delay enforcement or silently begins rejecting appointments. Set it explicitly and test zero, null, and boundary values in a spike. Also check whether the feature implies schema or migration changes.
- Is the timezone fix a breaking change that requires a data audit?
- The timezone fix makes scheduled appointment parsing use the unit timezone, which means records created before 2.3.0 may have been persisted or interpreted under the wrong timezone. That is a silent data-integrity issue, not a cosmetic bug, so plan a data audit and possible backfill rather than a simple version bump. Include DST boundary cases in your validation.
- Does version 2.3.0 still support Symfony 6.4 LTS or 7.1 through 7.3?
- The Symfony constraint moved from 7.1 to 7.4 LTS, so 2.3.0 is a semver minor that acts as a compatibility boundary in practice. Consumers pinned to Symfony 6.4 LTS or 7.0 through 7.3 are locked out of this release. Confirm whether the constraint is ^7.4 or a wider range before assuming your host is supported.
- Can I use the triage domain model without a full Symfony kernel?
- There is no documented supported path for consuming the domain services outside a full Symfony kernel, but the assessment suggests treating the package as a bounded-context domain library and instantiating services with a plain PSR container where possible. That approach is plausible, not guaranteed, because the bundle's service wiring may carry Symfony-specific dependencies. Spike standalone instantiation before designing around it.
- What are the CI matrix and testing coverage for timezone and DST boundaries?
- The provided assessment does not publish the CI matrix, so you should confirm which PHP and Symfony versions are actually tested, including whether timezone and DST boundaries have coverage. The timezone fix makes that coverage especially important. Ask the maintainer or inspect the repository's CI configuration rather than assuming.
- How actively maintained is it, and should I use a Laravel-native alternative?
- The project has a single primary maintainer and a small contributor surface, which is normal for small open source but a real bus-factor consideration for anything operationally load-bearing. For a Laravel-native requirement, evaluate packages that ship Laravel service providers and facades, or budget for a bridge and ongoing maintenance yourself. If your host is Symfony-based or you only need the domain model, the fit is stronger.
Weaver
How can I help you explore Laravel packages today?