Work Done :-
1. Migration to OpenMRS 2.x The module previously ran on OpenMRS 1.11 and worked with Spring Security 3. My initial task was to migrate the module to OpenMRS 2.x and use Spring 4 and Spring Security 4. This part took a lot longer that what me and Mayank thought. Spring Security is a complex framework and it’s compatibility issues with Spring versions are many. I had to remove all the deprecated code with new code and also fix some broken part of the code. A lot had changed from OpenMRS 1.11 to 2.X So I had to redo the whole OAuth Client data model and re-write some portions of the client.
2. Fix Grant Types This was one of the most challenging portions of the summer. The code was in-place, the procedure was right. Problem? Can’t get tokens In my opinion, Spring Security, Spring Security OAuth are excellent frameworks but quite complex too. Spring uses Jackson to manage all output JSON requests. The tokens which were created and stored in the database, were not returned to the REST call response. Reason? Jackson. Jackson, Spring security oauth, Spring security and spring mvc taken altogether to do one thing created such a mess of finding the right version of everything. If I changed a version, thing X would break. Changing it back, would break Y. This cycle continued for some time, until I managed to find the right versions of everything.
3. UI Fix The previous module used UI extensively. Our initial plan was to scrap out the UI and introduce a controller to manage everything what UI did. However, the mid-term presentation came by and I had nothing other than token generation to show to the community. Then, we decided to keep the UI, make the presentation and later provide enough flexibility to the end-user to choose between REST based controller, UI or both So I fixed everything wrong in the UI and completed it for the demo during mid-term.
You can take a look at how the UI works here,
4. REST Controller After the mid-terms the point of focus was the REST Controller. Using this controller, one could create, manage, view oauth clients without the UI. Which means that any OWA, Android app, iOS app, etc would be able to manage, create oauth clients and it won’t require opening OpenMRS on a browser and handing everything. Just like almost everything in this summer, the controller didn’t go as planned Problem? I wanted to return a client object as JSON response, however Jackson (which handles JSON outputs in Spring) gave the error “property leading to cycles”. Upon research I realized that Jackson depends on getter and setter methods of a class. My client inherited properties such as getCreator() , getVoidedBy() from the BaseOpenMrsData. getCreator() returns a User, the User also has a getCreator(), so that formed an infinite loop whenever getCreator() was called by Jackson. So what I did next was that I broke this loop by creating a new JacksonMappableClient. And now everyone was happy
A demo of the REST controller can be seen here;
5. SMART Application
This was one of the main goals for the summer. Even if we managed to create the OAuth module, there was not a lot of application to it. SMART on FHIR is a perfect use-case for our module. So making a sample SMART on FHIR would give OpenMRS community a perfect use-case for our module. The application came by easily. Their were a few blockers but nothing which would consume ‘days’ of debugging.
A demo of SMART on FHIR;
Where can you find my code? I am working with Mayank on final documentation and hopefully the code will be pushed to the official repo soon. I’ll post a link here. However, if anyone is interested, you can check my own repo here