(fix) O3-5552: Reject future transition dates in queue entry transitions

[Brijesh-0106]

Requirements

• This PR has a title that briefly describes the work done including the ticket number with conventional commit label.
• My work is based on the existing validation patterns used throughout the queue module.
• My work includes tests. I have tested and it is working fine.

Summary

The queue-entry transition endpoint accepted future dates as valid transition dates. This allowed transitions to be recorded as happening in the future, making queue metrics and wait times unreliable for clinical staff.

This PR adds a server-side validation check that rejects any transition request where the provided transitionDate is after the current server time.

Related Issue

https://openmrs.atlassian.net/browse/O3-5552

[Brijesh-0106]

Hey, @denniskigen as my frontend side PR is merged but as we discussed in 1 coffee break session that we need to put backend side validation as well so I have added backend side validation as well. So, @denniskigen Could you please take a look and merge it when you get a chance? Let me know if you need any additional context. 🙏

[mseaton]

LGTM

[denniskigen]

@mseaton should this check live in the service layer in QueueEntryServiceImpl.transitionQueueEntry() alongside existing guards (voided check, already-ended check, optimistic locking) instead?

[ibacher]

Two things:

1. Ideally this would live in the validation (i.e., in the service layer), not in the REST layer
2. Ideally, we'd have a little but of tolerance, e.g., new Date() + 1 minute or so to account for small clock drifts.

[Brijesh-0106]

Hi @denniskigen and @ibacher , thanks for the suggestions!

I’ve updated the implementation accordingly:

• Moved the validation logic to the service layer

• Added a small tolerance window (+1 minute) to handle potential clock drift

Could you please review the changes when you have a moment? If everything looks good, feel free to proceed with the merge.

Thanks again for the guidance!

[ibacher]

I'd still think this belongs with the rest of the validations, i.e., as part of the QueueEntryValidator.

[ibacher]

@Brijesh-0106 A test or two would be nice for this.

[Brijesh-0106]

@Brijesh-0106 A test or two would be nice for this.

Added two unit tests in QueueEntryServiceTest:

• shouldThrowWhenTransitionDateIsInTheFuture
• shouldAllowTransitionDateWithinOneMinuteClockDriftTolerance

mvn test -pl api -Dtest=QueueEntryServiceTest#shouldThrowWhenTransitionDateIsInTheFuture+shouldAllowTransitionDateWithinOneMinuteClockDriftTolerance

Also verified manually via API calls on a local OpenMRS instance. Both pass as expected.