Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • New Data Model Design
Skip to end of metadata
Go to start of metadata

Abstract

This page mainly covers the design of the new data models of the Dashboard under Mongoose. This new model should provide a more extendable data storage for the OpenMRS ID.

The goals for this data model is in-line with the Dashboard, that is to provide a one-site service.

For now they're only the most basic one that could cover the old data.

Will Be Updated

User

I'll simply just write some specifications here.

/// user Schema
username: <String> // not empty, unique, only contain number and characters, currently at least has a length of 2
firstName: <String> // no requirement
lastName: <String> // no requirement
displayName: <String> // no requirement,
primaryEmail: <String> // not empty, unique, valid email address, one of emailList
displayEmail: <String> // valid email address
emailList: < [String] > // array of valid email address, not empty, all members are unique
password: <String> // not empty, a hashed String
groups: < [String] > // no duplicates in the Array, items in this array must be in Groups collection. could only be edited by admin user.
locked: <Boolean> // not empty
extra: <Mixed> // any JSON form data
/// additionally all email should be in lowercase
/// and username as well
 
/// special flag used to sync with LDAP
inLDAP: <Boolean> // if false, then store it in LDAP, if true then sync the modifications
skipLDAP: <Boolean> // used to skip the sync procedure
 
createdAt: <Date> // It is only used to expire(delete) this user, if it is not verified for a long time.

Groups

This model describes user groups.

groupName: <String> // not empty, unique
description: <String> // no requirement
member: < [UserRef] > // no duplicate items
 
///
UserRef:
objId: <ObjectId> // user document id
username: <String> // username
  • No labels

4 Comments

  1. displayName and displayEmail will be determined programatically, right? I could see them implemented as getters. And what is the purpose of displayEmail vs primaryEmail?
    Will emailList also contain the primary email address?

      1. No, displayName and displayEmail will be stored in the database. They're irrelevant with firstName, lastName and emailList. Also updated firstName and lastName, now they don't need to be nonempty.
      2. displayEmail is for public display, it can be any valid email. primaryEmail are one member of emailList, we'll only use this email for notifications. You see, for now, when user reset his password, he'll receive one distinct mail per address...
      3. Answerd in 2.

      I'm referring GitHub, this is how they did for public email and public name.

      1. I like how you're doing primaryEmail as a member of emailList, you're right that the GitHub email design is a good one. But should the displayEmail be different from the primaryEmail? I believe GitHub displays the primary (aka the default) email address, and commits on GitHub use the authorship email address in the commit metadata.

        1. That's not true... GitHub won't display your primary email or other emails, if you set keep my email private. Unless you do some commits with this email, but anyway you leaved this email for others to find you. You can check this here. https://help.github.com/articles/keeping-your-email-address-private

          I've tested this few days ago, you can check this account https://github.com/lifeiscrucial, its email are foo@bar.com ... And actually I created this account via wechat@plypy.com.

          Nevertheless, that's not important. It can be easily changed technically.