(fix) O3-5306: Rejected Lab Requests Remain Active in Orders App

[abheeee03]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work is based on designs, which are linked or shown either in the Jira ticket or the description below. (See also: Styleguide)
• My work includes tests or is validated by existing tests.

Summary

This PR fixes an issue where rejected/declined lab requests were not displaying the correct status and continued to show action buttons that should be hidden for declined orders.

Problem

• Order status showing as undefined: The fulfillerStatus field was not being returned from the API because the order list endpoint was using v=default representation, which doesn't include fulfiller-related fields.
• Actions visible for declined orders: When lab technicians decline/reject an order, the following actions were still visible and active in the Orders App:
  • Add results
  • Modify order
  • Cancel order

Screenshots

fix-orders-app.mp4

Related Issue

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

[abheeee03]

@denniskigen Please review the PR when you get a moment!

[NethmiRodrigo]

@abheeee03 while this is the right approach, since (like you pointed out in the description) the fulfiller status isn’t returned by the API, this doesn’t really come into effect. That said, changing the representation to v=full would potentially be problematic to performance, so this is a conversation I suggest you start up in the ticket and we can move forward from there

[abheeee03]

@NethmiRodrigo Thanks for the guidance!

I've created a ticket here : O3-5339
I’d appreciate your guidance on the preferred approach

[NethmiRodrigo]

O3-5339

What I meant was starting up a conversation on the existing ticket, since it relates to this work and makes more sense to be included in this PR rather than without.

The OpenMRS Rest API supports custom representation, I should have clarified this. If going v=full, is not performant-wise, we would likely have to switch to custom representation. The issue is that in that case, we would need to specify the properties we need, which I’m not exactly sure is what in this case. Here is an example of a custom representation

[abheeee03]

What I meant was starting up a conversation on the existing ticket, since it relates to this work and makes more sense to be included in this PR rather than without.

Thanks for the clarification,
I’ve updated the PR to use a custom representation to include the fulfiller status