O3-5316: Implement urgency-based sorting in OrderService

[RajPrakash681]

Description of what I changed

This PR updates the REST module to delegate urgency-based sorting to the core OrderService instead of implementing business logic in the REST layer.

Changes Made:

• Simplified OrderResource1_10.java: Updated doSearch() method to call the new OrderService.getOrders() method with sortBy and sortOrder parameters
• Removed business logic from REST layer: Deleted sorting methods (sortOrders(), compareByUrgency(), compareByDate(), containsField()) as they now exist in openmrs-core
• Maintained backward compatibility: Existing API behavior preserved; falls back to legacy method when no sorting parameters are provided
• Kept integration tests: The 4 REST API integration tests in OrderController1_10Test.java remain to verify proper parameter passing and API response format

Architecture Alignment:

This change follows OpenMRS best practices where:

• openmrs-core contains business logic (sorting algorithms, comparisons)
• openmrs-module-webservices.rest acts as a thin HTTP wrapper around the Java API

API Usage (unchanged):

GET /ws/rest/v1/order?patient={uuid}&sortBy=urgency,dateActivated&sort=desc

Execution Flow:

1. REST endpoint receives request with sortBy and sort parameters
2. REST layer extracts parameters and calls OrderService.getOrders(..., sortBy, sortOrder)
3. Core OrderService performs sorting (business logic in core)
4. REST wraps sorted results in JSON response
5. Frontend receives properly prioritized lab orders

Issue I worked on

See https://issues.openmrs.org/browse/O3-5316

Related Core PR: This PR depends on the core implementation being merged first:

• Core PR: https://github.com/openmrs/openmrs-core/pull/XXXX (TRUNK-XXXX)
• The core PR adds the getOrders() overload with sorting support to OrderService

Note: This PR should only be merged AFTER the core PR is merged and released.

Checklist: I completed these to help reviewers :)

• My IDE is configured to follow the code style of this project.

• I have added tests to cover my changes.

  • Integration tests in OrderController1_10Test.java verify REST API properly delegates to core
  • Tests cover urgency sorting, multi-field sorting, ascending/descending order, and backward compatibility

• I ran mvn clean package right before creating this pull request and added all formatting changes to my commit.

• All new and existing tests passed.

  • All 4 new integration tests pass
  • All existing REST module tests continue to pass
  • Verified backward compatibility with legacy sorting

• My pull request is based on the latest changes of the master branch.

Additional Context

Why This Refactoring Was Necessary:

Initial implementation placed sorting logic in the REST module, but from the feedback i received correctly identified that business logic should reside in openmrs-core, not in presentation layer modules. The REST module should act as a thin wrapper around the Java API.

Dependency Update Required:

[RajPrakash681]

@ibacher

[emphor11]

@RajPrakash681
I have one question around the urgency logic in the core implementation.
In the comparator, urgency is currently treated as:
STAT OR ON_SCHEDULED_DATE → urgent
This effectively changes the meaning of “urgency” in OrderService sorting, since the original issue
and existing API usage seem to associate urgency primarily with STAT orders.
My concern is that this introduces a business rule into the core API that may not be universally
expected by OpenMRS consumers (e.g. treating ON_SCHEDULED_DATE at the same priority as STAT).
Could you share the reasoning behind including ON_SCHEDULED_DATE here?
Would it be safer to restrict urgency sorting to STAT only, or explicitly document this behavior
as part of the OrderService contract?

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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