MOD-42: Syncing Users to Modulus

[elliott (Elliott Williams)]

Hi guys, I’d like your advice on this (somewhat trivial) problem:

MOD-42 is about storing ownership & authorship data with a module. The data model defines that a Module object has an owner property, which is a single User, and a maintainers property, which is a list of Users. (@jeremy, right now I’m looking at also creating an Organization entity that could own a module )

This means that a developer must log in to Modulus at least once before they can be made an owner / maintainer of a module (signing in creates their User object in the DB).

Is it okay to have this restriction? A way to work around it would be to periodically synchronize the OpenMRS ID user directory with Modulus’s user table, but I’m not sure if it’s worth the effort / configuration necessary.

What do you think?

[burke (Burke Mamlin)]

My expectation from our earlier discussion was something like this:

• owner is a string and maintainers is a list of OpenMRS IDs
• OpenMRS ID of the user uploading a module for the first time becomes a maintainer and the de facto owner.
• Any maintainer can edit owner or a unique list of other maintainers – i.e., when editing the module settings, you would see a list of “other maintainers” and you couldn’t add yourself to that list.
• If the owner string matched an OpenMRS ID, it would display as the user; otherwise, it would display as a free text string.
• Filling out the owner field could show choices that match known names & IDs of the community, but would allow for any free text value. Picking a user from the choice list would just facilitate setting the field to their OpenMRS ID.

Are you saying that Modulus can’t search the list of known OpenMRS users (names & OpenMRS IDs)?

[elliott (Elliott Williams)]

@burke

If the owner string matched an OpenMRS ID, it would display as the user; otherwise, it would display as a free text string. Filling out the owner field could show choices that match known names & IDs of the community, but would allow for any free text value. Picking a user from the choice list would just facilitate setting the field to their OpenMRS ID.

My only concern with this is that then we can’t really delegate permissions to the owner. It would be more of a cosmetic value.

However I just looked back to Authorization in Modulus and it sounds like that was the consensus we arrived at! In that case, I’ll switch what I had in my code.

Authorization in Modulus

Historically, we have had a single “owner” of any given module. While I think it’s good to identify an owner, it would be nice if more than one person could be designated to edit a module’s entry in the repository. For example, the person overseeing or doing most of the work on a module might want to designate one or more person(s) who can upload new versions or edit metadata about the module on their behalf. Is there any documentation about the planned authorization model for modulus at this…

---

@burke

Are you saying that Modulus can’t search the list of known OpenMRS users (names & OpenMRS IDs)?

Yes. Unless we write an ID Dashboard search API, or we teach Modulus to access LDAP, there’s no way to search for users who have never logged in to Modulus.

FWIW, Atlassian apps sync there user databases with Crowd to alleviate this. Syncing with LDAP periodically would be a similar approach.

[burke (Burke Mamlin)]

@elliott

Yes. Unless we write an ID Dashboard search API, or we teach Modulus to access LDAP, there’s no way to search for users who have never logged in to Modulus.

FWIW, Atlassian apps sync there user databases with Crowd to alleviate this. Syncing with LDAP periodically would be a similar approach.

It would be a nice feature to have – i.e., knowledge of all OpenMRS users names & IDs. If the ID Dashboard kept a text file with one user per line (e.g., “openmrsid,Full Name”), it could be delivered to authorized clients on request. GZip would keep the transaction reasonable in size and something like Apache’s memcache could be used to deliver the list to multiple clients at regular intervals without putting significant load on the server.

Anyway, that could be a future feature. In the meantime, owner & other maintainers can be free text fields and people can populate them without requiring a nifty “OpenMRS users” search feature.