OpenMRS ID Platform Improvements Midterm Presentation

Hi everyone I’m Wiehwa Cheung, here is my middleterm presentation. You can also see the links of resources on the bottom. This demo briefly walks through,

  • Something what I have done
    • Improving the code style
    • Rebuilding the data model
  • A rough vision to the future API of OpenMRS-ID

Project wiki page Issue list of ID-Dashboard Felix’s style My Blog

Talk about the new data model,


@plypy, great presentation! Your English was very easy to understand and your presentation very easy to follow. Well done!

I would encourage you, working with @elliott, to identify the absolute bare minimum functionality needed to replace the existing OpenMRS ID and focus on getting that done and deployed before adding any additional functionality. For example, get ldapjs and current data provided by LDAP + MySQL working in MongoDB and replace OpenMRS ID with this before you begin working on any new API functionality. If you reach the end of GSoC with your project 99.9% done and not yet deployed, there is a chance it will never make it to production. Ideally, you would spend the end of the summer working on enhancements to code that you had already deployed.

Some unrelated questions…

  • How will clients of the API authenticate to it – i.e., who or what will have access to modify a user’s record?
  • If you have authority to make changes to the user’s entry, will you be on the honor code – i.e., clients are expected to only make changes to their own settings, but could technically change anything? Or will there be some scoping of authority so, for example, Atlas could only make changes to properties within extras.atlas?
  • Do you have thoughts on how you would control the namespace? For example, what if two different projects want to use extras.foobar.*?

Nice work! Looking forward to hearing more as GSoC progresses!

1 Like

Yah, Dashboard 2.0 will come soon :smile:


It’s not decided yet, maybe use http authenticate. And @elliott suggested we can use OAuth to restrict the privileges of Clients. You can see this discussion

Basically yes, I think, a client could only editing its own data. Each Client will only know its own existence. Maybe they can read others data? I’m not sure for this. But it seems to be a bad idea.

Though, we don’t have much client… the chance of duplicating is there. So I’ll make sure each scope has a unique identifier, by setting unique indexes. And maybe auto generate unique identifiers.

Things related with RESTful API is still in discussion and design, and I havn’t done any tests. Thus, things may change.

I agree not to worry about API things just yet. Still ahead on our roadmap is rolling out the new data model, ensuring backwards-compatibility with LDAP and migrating data from LDAP to Mongo. It’s important we get these things done ASAP so that we can get something out the door, and we can focus on the API next!

(Great presentation, as well! English was not a problem :smile:)

This is why I suggest wholeheartedly that we only support OAuth 2, which is already coded in the ID Dashboard OAuth Module. This means a couple things:

  • OpenMRS ID Admins control access to the API. Only sources we trust can authenticate and read/write ID data. We control what applications get client credentials required to use the API.
  • Authentication will be exclusively carried out via authorization tokens that are granted by the Dashboard. A token can be granted only with access to specific areas, so there’s no need for the honor system. Clients can only change their own settings, unless they ask for access to other data and the user approves of this access.