Implementation of the Order Entry UI application in ReactJs

Development
,
81

I assume you know, but if you look in the links section of the response, this will tell you how to get the next page of results.

Did you try what Wyclif suggested, to see the total results?

Also, is this really a blocker? Can’t you make the UI work without knowing the total number of results as long as you know there are more pages?

82

@darius I still need some insights about the encounter role

83

Sorry, I had missed this question

I thought the plan for encounter type is that there would be a global property setting, which the admin has to configure before anyone can use the order entry tool.

Encounter role should be similar. There should be a GP setting which controls what encounter role is used. Yes, on one configured server it can always be the same encounter role. The simple way would be for the admin to use a Clinician role. If they want to be more sophisticated they could have an “Order Signer” role or something like that.

84

Thank you @darius. This is really helpful.

85

Thanks a lot @wyclif This solved the blocker I had.

86

Yes, I saw how to link to the next page in the response.

Wyclif’s comment solved the issue I had.

The reason why this was a blocker is because of the default limit of 50 results returned by the API. This prevented me from getting the actual total number of results if the orders were above 50. The totalCount was required for me to determine the number of pages to split the results based on the specified limit and show this on the UI.

87

@darius Still on the encounterRole issue. I seem to have noticed a sort of bug in the API endpoint needed to fetch encounter roles. It always returns an empty array when I search for role even when such role exist in the database. For example http://localhost:8081/openmrs-standalone/ws/rest/v1/encounterrole?q=Clinician returns [ ] whereas Clinician is already present. I will like to open a ticket for this (but don’t know where) and perhaps be pointed to where the code (maybe I can fix this). Thanks

88

@larrystone create a ticket in the Rest Web Services JIRA project. I will curate it for you to work on it.

89

@dkayiwa https://issues.openmrs.org/browse/RESTWS-707 Thanks

90

I have curated it in such a way that you should be able to complete it in less than an hour.

91

Thanks @dkayiwa, I am done with the task. But before raising a PR I have a question, is it okay to let my new implementation replace the existing implementation for the encounterrole endpoint? I noticed I can’t use the define my endpoint using the encounterrole name because it is already taken in v1.9. I had resorted into using encounterrolesearch but I feel I can still update the v1.9 without breaking any existing feature. Can I go ahead and do this?

92

Did you take a look at the ticket description? It has the exact classes that you need and states where to put them.

93

One alternative solution is to require that the global property value should be uuid, not the name, thus you can just fetch it instead of searching for it.

94

Yes, I have looked into it. The reason I asked the question was that declaring

 */
@Resource(name = RestConstants.VERSION_1 + "/encounterrole", supportedClass = EncounterRole.class, supportedOpenmrsVersions = {
        "1.11.*", "1.12.*", "2.0.*", "2.1.*", "2.2.*" })

on my file resulted in a duplication error indicating that the resource endpoint is already taken. So, my question is that is it okay to create a new resource type /encounterrolesearch to address this bug or should I find a way to still use the /encounterrole resource endpoint with this bug fix?

95

Can you do a pull request for review? That way i will take a look at your changes and tell what you could possibly have to change.

1 Like
96

I haven’t been following this in detail but +1 to the suggestion from @darius that the global property be a uuid… using uuids has been our general approach for settings things like this (at least over the last few years).

97