This is the official announcement for Order Entry UI sprint 4. In this sprint, we would be implementing feedback received from sprint 3 demo and completing the remaining functionalities using React/Redux.
@fred, could you give a bit more info? What’s the screen that you’re working on? What’s the REST call that you’re doing now?
It’s likely that the REST API does not give sorted orders yet, and you’ll need to add this. (I peeked at the code quickly and it seems like it’s also doing something inefficient if there are many inactive orders.)
It’s also the case that the “past orders” screen may need some UI rethinking, so maybe it’s worth doing that first before making the changes to the REST API… I actually don’t think that we should have “Past Prescriptions” right under the active ones, because over time there are too many of them. I think the user should actively have to click somewhere to see past orders.
To give more context. The feedback the team received suggested that past orders should be arranged according to the most recent past orders. Below is the endpoint being used to retrieve past orders:
In order to implement the suggested feedback, we need more information about the endpoint that might not be in the API documentation, such as the following:
Does the order REST API endpoint support sorting?
If yes, do I need to pass a parameter to the endpoint to enable sorting?
Also, the Past Orders tab is always closed on page load. The tab pulls down to show the past orders only when the user clicks on it.
So, the quick-fix is probably to do a sort before returning the result in the REST resource. (This is hacky but the code already there looks quite hacky.)
The better fix (which you should either do or at least add a ticket for) would be to the implement the query against the DB. (This might need to be in the REST module first, but with a plan to add it to openmrs-core…)
Have considered the first alternative you suggested, but there is a challenge with this approach. The results returned by the endpoint for each call is restricted to the limit supplied which may affect accuracy. For instance, say the total number of past orders is 100, the first call returns 10 results, then this result is sorted on the frontend. The challenge this poses is that the newly sorted result might be incorrect because it was based on the 10 results returned by the first call. When a second API call is made, we get another set of 10 results which is sorted independent of the initial 10 results.
The better fix you suggested would be helpful in this case. However, that is outside the scope of our current Order Entry UI implementation. Could we get backend support from the community to implement this?
The first step would be to add a ticket to the “Web Service REST module” for adding sorting to the Order object… the response from @darius gives a good summary of the possible options.
Feel free to tag me on the ticket and I’ll make sure it’s “ready for work” and tagged as “community-priority”. And if anyone working on the Order Entry sprint is looking to do some Java coding, feel free to pick it up, I’m available to do code reviews.
From peeking at the code I thought (because it uses the NeedsPaging helper class) that (1) it’s inefficient, but (2) you could just sort, because it’s all in memory at that point.
@fred (and others) - Is there a staging server that’s best you are using to see the latest? I will start writing up my feedback and testing this code.
