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.
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:
###exports.getUser()
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.
###exports.updateuser()
It now only supports to update the ordinary attributes, not including those ldap specific attributes like objectClass, pwdPolicySubentry.
###others
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.
@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.
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.
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, socket.io; 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.
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.
Summary:
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.
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.