OpenMRS ID v2.1 Platform Improvements

Welcome potential Google Summer of Code 2015 interns! I am mentoring the OpenMRS ID project this year and am opening up this thread for discussion and questions.

I will be the primary mentor, and @elliott will be backup mentor should I be unavailable for any reason.

If you have questions, ask here!

Hey, you have just updated project idea :smiley:

  • Investigate rewriting all JS files using either ES6 or Coffeescript (see js2coffee or the node module of js2coffee)

That will be interesting!

  • Support two-factor authentication for OAuth-based sign ins

Should we use SMS verfication as second factor? Or any other requirements?

1 Like

Yup :slight_smile: I did – I think it’s a good change :slight_smile:

Take a look (and add your voice!) to the design discussion on two-factor auth.

1 Like

Hi @r0bby, I’m wondering how much frontend knowledge is needed… As I’ve been focusing on backend stuff and just started to learn frontend things.

Also, I’ve already done some work for ID-89(reimplement the ldap.js) in my ID-89 branch. However, I’ve made some changes for the APIs of ldap.js.

Here is the change list I’ve logged,

##ChangeLog begin

Note that the ldap.js shouldn’t be used directly, as you shouldn’t directly contact the LDAP server, or you will break the consistency between mongo and LDAP.

Most functions’ interfaces haven’t changed, here are few changed:


  • The result it returns will not contain the objectClass field, nor the conf.user.secondaryemail.
  • All the attributes it returned will have same names, instead of odd LDAP stuff like cn, dn or what.
  • It won’t pass back an error for not finding any user. Instead, if no user is found, the userobj in cb(err, userobj) will simply be undefined. You may check it yourself.


  • It accepts a normal user object rather than a series of attributes, and it won’t automatically generate the displayName field, but leave it to the programmer, as well as the groups.

    This function is rather slow, as we need to iterate all the groups.


  • It now only supports to update the ordinary attributes, not including those ldap specific attributes like objectClass, pwdPolicySubentry.


  • changePassword is deprecated, but resetPasword is reserved. What’s more, resetPassword, now will only accept username, not email.

ChangeLog End

What do you guys think? I made these decisions all by my distinct, so some might be wrong. But in my opinion, these changes will only affect a tiny of our project. As I noted

Note that the ldap.js shouldn’t be used directly, as you shouldn’t directly contact the LDAP server, or you will break the consistency between mongo and LDAP.

So there are only a few other components used it.

@plypy There will be a lil bit of both…but mostly changes to existing views…two-factor authentication will require some kind of a way for people to type in the code…but that’s it…

Ahhh… school days are keeping me busy, I was doing all kinds of experiments. Like OS, Network, Data Science etc. It was all back-end or theory stuff that I’ve been learning, but since the Dashboard has pretty much front-end part, I’m digging it.

It just bothers me, you know, when I have some issues fixed but cannot put it into use because of no pretty interface. Like ID-86, which I have already worked out a prototype long ago. It’s really a pain in the ass.

Anyhow, do you have any recommendations, @r0bby. Currently, I’m learning jQuery from this book Learning jQuery, and some CSS/HTML knowledge from w3c school.

The application period has already opened, you’ll have my application soon.

Right now we got GCI contributions to trudge through – I’m mostly done with that – just need to make decisions but that will be done before May.

If no interface exists – make it – but this isn’t a hard to implement solution.

Can’t wait for it, you’ll be held to the same standard so knock it out of the park! :smile:

I know, it’s not hard to implement. Just manipulating those DOM stuffs according to the docs isn’t a hard thing for me, but working out a pretty looking page, you know.

Anyway, I’m learning.

Hi all! My name is Dmytro Trifonov, and I am insterested to work on this project during GSoC 2015. I start to learn it (source code) last weekend, and soon I will prepare list of my ideas and proposals. Some words about myself: I am working on different node.js projects more than 2 years, I worked with such technologies: server side - Express.js, MongoDB (mongoose module), Redis (nohm module), postgresql, mysql,; frontend - Angular.js, JQuery, require.js, Bootstrap. Also i have worked with OpenMRS system before, and have good knowledge of OpenMRS REST API and database structure.

Bonus points for wireframes :slight_smile: :heart:

I look forward to your proposal. Impress me :smile: – make me :joy_cat:

As i see, currently OpenMRS ID uses Node.JS v0.8/Express v3.x. What do you think about upgrading code for latest version of Node.JS, and Express v4.x?

Barring things didn’t break – I’m fine with this – but I’m more concerned with keeping things working. I have changes I want to make as well…let’s keep things working. A pull request upgrading code plus passing tests would make me happy. @elliott and @plypy you have any opinions?

Since we have pretty open-ended project description – barring you have good ideas – wrap it in your proposal and we’ll see how it goes.

Actually, the ID-Dashboard is fully compatible with Node 0.10.x, which was once the newest version. The reason we haven’t upgraded it is that it’s not necessary that time. And if you want to change the version, you can do it anytime. I’ve just noticed that Node has released v0.12, under which we haven’t tested the Dashboard yet. But, I think, we should not be too hasty, as our platform, like many others, relies on 3rd-party packages heavily. And the v0.12 has just been released in a month, there is a chance that it could break some packages, so let’s give it some time.

And we once tried to upgrade the Dashboard to 4.x last year, see ID-55. But that update failed because of some weird conflicts to our admin tool, i.e. formage. Nevertheless, we are planning to switch to the keystone.js and deprecate the formage, this could be pick up again. IMO, one thing at a time, let’s first migrate to keystone.js.

Anyway, you know, new things are great but sometimes they are not necessary, unless you do have very good reason to do it(old version is deprecated, and there are some must-have features in the new one). However, if you really want to upgrade it, make sure it won’t break things.


  • Could upgrade node to v0.10, but don’t be hasty to upgrade it to v0.12.
  • Should upgrade the express, but first work on keystone.js.

I agree with @plypy – go ahead and upgrade node to 0,10 – make a PR – but TEST THINGS!

Work on your proposals :slight_smile:

It seems that you have misunderstood me… By ‘fully compatible’ I mean, no code needed to rewrite. :smile: We can work on something else.

Alrighty, Good luck on your proposal.

Ahhh, I just checked my notes, and I may be too confident on this point.

The current Dashboard could pass the unit tests in 0.10, and nothing seems to be wrong on the local server, but that’s all I know. There may be, though unlikely I think, some version-related bugs. As the most recent fix ID-87 is exactly about 0.10 conflict, I might be wrong.

Anyway, you can’t be too careful.