Today, I’ve submitted the last PR for GSoC here.

Wow, time flies. It’s already my final weekly blog post for GSoC 2014. So much fun I’ve had, Great journey indeed.

I had uploaded my final presentation this week, here. And eared a few “likes”, hoho. However, except for that, I didn’t do much work this week. Well… if you listen carefully in my presentation, you may find out that I had some issue with my throat. It’s inflammation, and it got worse after the day I uploaded the post. So anyway, I took a week-off resting.

Well, actually not just resting… my ubuntu was broken, again. So I took this chance upgraded all my stuff, including the tools that supports this blog.

However, it’s already in “documentation period”, and my project has less stress on that. The works will be done soon hopefully.

So, all in all, I had a sick week :/ , but the work will be done pretty.

Bon voyage!

Well the title should be “The 12th Week of GSoC”, if I went the usual way. Hahhhh, well, tomorrow will be the official soft pencil down date. It means, I need to stop coding, and working on perfecting documentations.

It’s really been a great unforgettable experience, It’s my first time working on a real-life project, and first time to work for a open-source community, specifically such a great community that with such a noble objective. “Write codes, save lives”!

Originally, I want to publish this blog later after I have done my final presentation. However it’s not done yet, and it’s close to the end of this week. I have to publish my weekly-blog.

Anyway, the presentation will be done in tomorrow for sure.

Well, summarize as usual.

Done

1. Fixed few issues, ID-48, ID-51, and working on ID-52, ID-55 now.
2. Done the specification work for the RESTful APIs with Elliott(Well, most works is done by him, I’m not experienced…)
3. Working on the final presentation.

Wow it’s almost close to the end of this years GSoC. So many exciting experiences, and new knowledge learnt.

The OAuth

Anyway, I’ve been working on the OAuth and the RESTful APIs this week. Yes, we used the OAuth 2.0 to achieve SSO service. As it is a widely-used protocol, it will be more easy for us to implement authorization logic for other OpenMRS apps.

And also we plan to build a OAuth based RESTful API system. So we can open the access to the OpenMRS ID, however, we have very very very little information to share. But maybe in the future the Dashboard will have more information, and become a central data storage system. Apps can store the user related information in Dashboard, and let others to access.

Well, that’s only my own vision about the far future.

So, summarize briefly as usual!

What I Have Done

1. Perfected the patch for ID-48, and learnt something new about the Mongoose.
2. Learnt the OAuth 2.0 a bit, and began to refactor the OAuth module with Mongoose.
3. Built the very prototype of the REST module.

ToDO

1. Complete the refactoring work of OAuth.
2. Record my final presentation.

Announcement for Dashboard 2.0

Exciting week!!!

After lots of testing and fixing, I’m proudly annoucing that the new Dashboard has been released. Check it out https://id.openmrs.org

Well, the new Newdashboard hasn’t changed so much on the outside, so you may find no much differences. Except for the email selecting part of profile page. Most the chagnges have happened in the backend. We’ve replaced the data storage to Mongo, for more possibility in the future.

However, I can’t say this upgrading is smooth. We’ve used lots of time on adapting to legacy datas. The new data model is somehow relatively easy to design and implement. But I have to change a lot for backward compatibility, and this process had spent lots of our time, about weeks.

Anyway, briefly summarize.

Done

1. Collaborate with Elliott to deploy the 2.0.
2. Fix some bugs of it.
3. Checked and discussed the RESTful APIs with Elliott.

ToDo

1. RESTful APIs

Deployment

Oh, another week of delay… Deployment is somehow exciting and painful.

In this week Elliott and I have tried to do a trial deployment on the staging server. However, we encountered lots of problems that delayed our schedule. Like duplicate emails we found earlier, and also updating other functional modules to adapt the new Dashboard.

I updated the Migrator, and added a verifier for verifing the correctness of the migration, then made PRs for globalnavbar and sso module. And left oauth and groups module for Elliott to work on, sorry for that, but I really don’t know how to test these two…

And after we tested the migrator separately on our own machine. Things should be fine now, we think… However, you know, another issue poped out. Last time, due to the famous heartbleed bug of OpenSSL, our people made a global password reset for all acount. Specifically, setting all accounts password as empty, as OpenLDAP won’t authenticate a user with empty password. And that is definitely a thing that I have never thought about :/

Not only this, when I was checking this issue, I found that I used wrong password hashing algo, SHA rather than SSHA. And this is because of the different slapd.conf between production server and dev machine.

So we created ID-45 and ID-46.

Anyhow, Summarize!!

What I Have Done

1. Updated Migrator.
2. Collaborated with Elliott to do a trial deployment of Dashboard 2.0 and solved lots of problems.

What I Will Do

1. Finish the deployment.
2. Learn RESTful APIs

That’s it!

Briefly.

What I Have Done

1. Updated lots of dependecies, mainly about our main frame express. Now it’s using 3.0.
2. Adopted formage as our admin panel for data.
3. Tested 2-way sync via Syncrepl.
4. Discussed about duplications with old accounts.

Summarizing!!! So, keep it brief.

What I Have Done

1. Finished the sync work with OpenLDAP.
2. Built a dynamic migrating solution for temparay usage.
3. Built a simple migration script for migrating data from OpenLDAP to Mongo*, Here is the repo

What I Will Do

Deploy the Dashboard 2.0!.

That’s it.

Finally, after weeks of exploring and attempting, the new dashboard is nearly in place.

The main purpose of Dashboard 2.0 is to provide a extendable user model for OpenMRS ID, so we used MongoDB as the backend database. Hence we can add some free-form data to database, as discussed and explained in these talks. My Midterm presentation Disscussion

Concern for LDAP

While gaining the new features, we can’t leave the older behind. So for backward compatibility, we have to reserve a LDAP server, so those Atlassian Crowd based apps could be happy as usual.

My original plan was to create a LDAP layer on top of the new user data model via ldapjs. However, after some attempts, I found that its not feasible, or more accurately, efficient. So I turned to the sync plan. Specificly, we’ll remain the OpenLDAP server and sync with it. Although this sync is one-directional, that is, we can only sync the changes from MongoDB side to LDAP.

For data migration, currently I don’t have a good idea, because I don’t know much about the production. So for quickly putting Dashboard 2.0 into production and test, I choosed a dynamic migration approach. In detail, I’ve bound a query of LDAP to one query method of Mongo, when I don’t find any record in Mongo I’ll query in LDAP, and if there is one in LDAP, I’ll copy that in Mongo.

New Procedure for Signup

I’ll demonstrate this in one diagram, see.

Something about Data Model

Our user related data models are very simple. We only have user and groups schema.

Except from those basic attributes, 2 things need to be mention exclusively.

The user.extra

it’s in Mixed type. So you may treat it as a normal json object.

In future, we’ll use that to store all kinds of other things other clients put into via our API. See this in detail, Disscussion

The relation between Groups and Users

One user may be member of different groups, and each group has different users, so it’s a “many to many” relation.

To manage relationship in Mongo*, just store the ObjectId of one doc into another, so you can easily reference each other

But considering the number of groups will be small anyway, so for the sake of simplicity, I’ve just stored the group names in user docs.

And to easily get all the members of one group, each group will have a userList array containing usernames and ObjectIds. Having usernames known, we don’t have to really query for users in most cases.

However, Mongo* don’t have built-in mechanism to query the array belong to one document. But again, considering we won’t have too much users :|, I’ll just do a plain O(n) one by one search. No need to use any data structrue and algorthim, hahahahhhhhhh…

That should be it.

Time to summarize again.

Well, I havn’t done many things this week… Because it’s the last week of this semester as well. I’ve been preparing my last final, and celebrating with my classmates after it.

Anyway, here is the usual list.

What I Have Done

1. Basically finished all the integration work.
2. Created a prototype of the new /profile page. And here is the mockup.
3. Fixed few trivial bugs.

What I Will Do

1. Make up all the validation work.
2. Start to work on ldapjs.

That’s it.