Planning the work
I’ve started the week by gathering all requirements for the task ahead.
First, I’ve used these two articles on OpenMRS Wiki:
I also had to spend some time with REST API documentation here, because not every endpoint is documented well, and in some cases, required features were already implemented but not yet documented :)
After a few hours I’ve been able to come up with the draft list of tasks that I will be tackling this summer. Here it is:
- Add REST resource with links to administration pages of installed modules
- UserResource should allow including disabled users in the response
- Add REST resource for Alert Management
- EncounterResource should allow including deleted encounters in the response
- ProviderResource should allow including retired providers in the response
- Add REST resource for Address Template Management
- Update REST API docs about “List all observations” endpoint
- Add REST API docs about Task related resources
- Add REST resource for Program Management
- Add REST resource for ConceptProposal management
- Add REST resource for ConceptStopWord management
- Add REST resource for Field Types management
- Add REST resource for Implementation ID management
- Add REST resource for Database Changes
- Add REST resource for Logged In Users
- Add REST resource for Triggered State Conversions management
- Add REST resource for Visits Behavior management
- Add REST resource for Patient Identifier Sources management
- Add REST resource for Auto-Generation Options management
- Add REST resource for Log Entries of identifier generation management
As you can see, most of them involve creating a brand new resource for our objects.
Me and my mentors decided that we’ll be adding or removing tasks from this list when needed, according to the time left.
Let’s look at the first task from the list :)
My first task
My first task - exposing the list of administration links for installed modules through REST.
Created wrapper class for the resource return value
I’ve created class
ModuleAdministrationLinks1_8 that represents one module with its administration links. It also contains
AdministrationLink inner class to encapsulate a single link with its title.
BaseDelegatingReadableResource class, because it only provides GET operations, as those objects cannot be persisted directly.
The implementation of it is fairly simple. I’m gathering all AdministrationSection extensions by calling
Then I’m casting each extension to its supper class -
AdministrationSectionExt and retrieving a map of administration links. What’s left to do is to pack this into my custom class and send it as a response :)
Every class must be tested. That’s why I’ve created a basic unit test for my new REST Resource.
My class extends
BaseDelegatingResourceTest so I didn’t have much code to write myself.
Posted a Pull Request
After implementing all of the above, I’ve posted a pull request to review:
I’ve also created a pull request with the documentation for the AdministrationLinksResource:
My second task
My second task was RESTWS-822.
It involved adding the ability to include disabled users when querying UserResource.
After investigating, it turned out that the Resource already supports such a filter, and you would only need to
includeAll=true parameter to retrieve all users, including disabled ones.
That’s why I’ve only made a pull request to update the REST API documentation:
That’s it for the week. It was a fairly productive one, mainly because I’m in the middle of preparing for my final exams at the university :)
Next week, I will try to implement a more significant task - RESTWS-823. It will involve me creating a REST resource from scratch.
Take care and stay safe!