O3-5682: Ship Visit Queue Number visit attribute type

[UjjawalPrabhat]

Summary

Adds a Liquibase changeset that inserts the visitQueueNumber VisitAttributeType (UUID c0c579b0-8e59-401d-8a4a-976a0b183519) on module install/upgrade. Idempotent via sqlCheck precondition.

Why?

The queue screen (/spa/home/service-queues/screen) is blank in default installs because the Call→serve flow depends on a "Visit Queue Number" visit attribute that nothing in the module ever creates. The frontend has long had a visitQueueNumberAttributeUuid config knob that was meant to be overridden by each distribution, but in practice the Reference Application and most installs ran on the null default — so generateVisitQueueNumber silently no-ops, visits never get a ticket number, and the assignticket POST silently 200s with nothing stored. Shipping the VAT in the module itself gives every install a working default; distributions that want their own UUID can still override via config.

Related Issue

O3-5682

[jwnasambu]

@UjjawalPrabhat Kindly I want to believe with the current changes the screen remains blank because it expects a results array but the API returns a raw Map.

2. Don't we need to add a patientName field to the assignments model?

3. Kindly for safety use a ConcurrentHashMap for the in memory storage to prevent server crashes during simultaneous polling and updates.

Thanks.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[UjjawalPrabhat]

Kindly I want to believe with the current changes the screen remains blank because it expects a results array but the API returns a raw Map.

I had some concerns before going on with this one:

• Breaking API change. Anything consuming GET /queueutil/active-tickets today (frontend, integration tests, third-party clients) gets the raw Map<String, TicketAssignment>. Switching to {results: [...]} breaks that contract silently.
• Inconsistent with the rest of the controller. The other utility endpoints in Legacy1xRestController (/queue-entry-number, /queueutil/metrics-by-service) also return custom shapes — the {results: [...]} envelope is for BaseDelegatingResource-backed domain resources, not ad-hoc utility endpoints. Changing only this one makes it the odd one out.
• Doesn't necessarily fixes O3-5682. Screen renders correctly with the current shape once the VAT exists — verified locally. Probably belongs in a separate "make queueutil endpoints OMRS-conventional" ticket if there's appetite for that refactor.

Happy to defer if you feel strongly.

2. Don't we need to add a patientName field to the assignments model?

it wasn't present before and even if we need it, should it be included in this PR?

3. Kindly for safety use a ConcurrentHashMap for the in memory storage to prevent server crashes during simultaneous polling and updates.

done.

[jwnasambu]

@UjjawalPrabhat Kindly doesn't the PR title need to reference the ticket ID? https://openmrs.atlassian.net/wiki/spaces/docs/pages/25477199/Pull+Request+Tips

[UjjawalPrabhat]

@UjjawalPrabhat Kindly doesn't the PR title need to reference the ticket ID?

Isn't O3-5682 the ticketID?

[NethmiRodrigo]

Ah, we don’t usually insert things like this into the database because these are things that the implementers need to configure. Instead, we use content packages. If this is a visit attribute type, then it should go into a configuration file like this one - https://github.com/openmrs/openmrs-content-referenceapplication-demo/blob/main/configuration/backend_configuration/attributetypes/attribute_types-core_demo.csv. These get processed by the initializer and saved to the database