# OpenMRS ID Platform Improvements Midterm Presentation **URL:** \ **Category:** GSoC\ **Tags:** gsoc2014\ **Created:** [June 22, 2014, 6:27pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321 "2014-06-22T18:27:03Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![plypy](https://talk.openmrs.org/user_avatar/talk.openmrs.org/plypy/32/505_2.png) [@plypy](https://talk.openmrs.org/u/plypy)\ **Post date:** [June 22, 2014, 6:27pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/1 "2014-06-22T18:27:03Z")
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](https://wiki.openmrs.org/display/projects/OpenMRS+ID+Platform+Improvements)[Issue list of ID-Dashboard](https://issues.openmrs.org/browse/ID)[Felix’s style](http://nodeguide.com/style.html)[My Blog](http://pages.plypy.com/) Talk about the new data model, - [new user data Ideas](https://talk.openmrs.org/t/new-openmrs-id-ideas/245) - [API about the free form data model design](https://talk.openmrs.org/t/api-data-model-design-discussion-free-form-data/282) ---
**Author:** ![michael](https://talk.openmrs.org/user_avatar/talk.openmrs.org/michael/32/15070_2.png) [@michael](https://talk.openmrs.org/u/michael)\ **Post date:** [June 22, 2014, 7:21pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/2 "2014-06-22T19:21:47Z")
Pinned on June 22, 2014, 7:21pm UTC ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [June 23, 2014, 9:14pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/3 "2014-06-23T21:14:33Z")
@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! ---
**Author:** ![plypy](https://talk.openmrs.org/user_avatar/talk.openmrs.org/plypy/32/505_2.png) [@plypy](https://talk.openmrs.org/u/plypy)\ **Post date:** [June 24, 2014, 4:46pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/4 "2014-06-24T16:46:46Z")
Yah, Dashboard 2.0 will come soon 😄 Questions > [@burke](#): > > How will clients of the API authenticate to it – i.e., who or what will have access to modify a user’s record? 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](https://talk.openmrs.org/t/api-data-model-design-discussion-free-form-data/282) > [@burke](#): > > 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? 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. > [@burke](#): > > Do you have thoughts on how you would control the namespace? For example, what if two different projects want to use extras.foobar.\*? 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. ---
**Author:** ![elliott](https://talk.openmrs.org/user_avatar/talk.openmrs.org/elliott/32/965_2.png) [@elliott](https://talk.openmrs.org/u/elliott)\ **Post date:** [June 25, 2014, 6:14pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/5 "2014-06-25T18:14:31Z")
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 😄) * * * > [@plypy](#): > > burke said: How will clients of the API authenticate to it – i.e., who or what will have access to modify a user’s record? > > 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 > [@plypy](#): > > burke said: 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? > > 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. This is why I suggest wholeheartedly that we _only_ support OAuth 2, which is already coded in the [ID Dashboard OAuth Module](https://github.com/elliottwilliams/openmrs-contrib-id-oauth). 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. ---
**Author:** ![michael](https://talk.openmrs.org/user_avatar/talk.openmrs.org/michael/32/15070_2.png) [@michael](https://talk.openmrs.org/u/michael)\ **Post date:** [June 30, 2014, 2:04pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/6 "2014-06-30T14:04:46Z")
Unpinned on June 30, 2014, 2:04pm UTC ---
**Author:** ![michael](https://talk.openmrs.org/user_avatar/talk.openmrs.org/michael/32/15070_2.png) [@michael](https://talk.openmrs.org/u/michael)\ **Post date:** [March 8, 2016, 3:07pm UTC](https://talk.openmrs.org/t/openmrs-id-platform-improvements-midterm-presentation/321/7 "2016-03-08T15:07:42Z")
Closed on March 8, 2016, 3:07pm UTC