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 ( ), 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.
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.