New OpenMRS-ID Ideas

Hi guys.

As the assignee of OpenMRS ID Improvement, I’m redesigning the new data model.

Please share some your ideas here.

Here is some of my ideas,

  1. Create a displayEmail for public display, and then the primaryEmail will be used for system notifications, and won’t be shown to public. Just like how GitHub did.

  2. Enable user to log-in via their emails.

  3. Just ask for a username when new users sign-up their OpenMRS ID.

  4. Don’t ask for users last name and first name, instead just the display name.

Since changing the OpenMRS ID will affect us all, I sincerely hope your feedbacks.

2 Likes

I like these ideas! I’m all for making ID profiles more flexible. Just a couple of technical points:

In LDAP, we store three attributes, cn (first name) sn (last name) and displayName. However, Crowd relies on the cn and sn attributes, so I think if we do this we’d have to programmatically separate an entered name into first and last name components.

Again due to Crowd limitations ( :disappointed: ), apps using Crowd only get one email address, stored as mail on the LDAP objects. So the email address displayed and used by the wiki, JIRA, etc. probably has to be whatever address is being synced as the mail attribute.

With these limitations in mind, I think the primaryEmail should be the one synced to LDAP, therefore being the one receiving system notifications and being used by Crowd-consuming apps.

We could still keep the displayEmail, but I’m not sure where it would actually be used. Maybe in a future version of the dashboard, where you can see other users’ public profiles?


@burke, @michael, and anyone else interested in this topic, what do you think of @plypy and my ideas? It’s important to make the right decisions here so that we can build comprehensive OpenMRS ID profiles without compromising our Crowd-based apps.

1 Like

I think the name limitations are not just Crowd but also the other Atlassian applications (e.g. JIRA, Confluence) … even if it was LDAP-only. Someone could confirm this though.

I’m always cautious about displaying e-mail addresses of other users, especially for anonymous (not logged-in) users. Would displayEmail be used anywhere else or is it just a text string?

+1 for logging in via e-mail address, but we need to look at the actual data because we may have some duplicate primary e-mail addresses from our pre-Dashboard era. It’d probably be impossible to log in with that.

Keep up the good work!

What does this mean? Surely, we aren’t going to create new OpenMRS IDs form a single-field form.

It’s just an idea. What I meant is, we can give users options to decide whether they want to other to see their realname or just a nickname.

But just like I had worried about… this seems to cause compatibility problem with Crowd…

1 Like

So frustrating…

After some search, I found all you said was true… very true…

Those Atlassian app indeed just use one mail for public displaying and system notifications… So we can’t use displayEmail. Also @michael it’s only a valid email address, and no need for verification.

And those name ideas won’t work as well, due to the similar reason.

So, only login via email is workable… but anyway I think I’ll keep displayEmail for future purpose, and displayName currently will be stored as firstName + ’ ’ + lastName.

That’s it.

1 Like