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 point? I’d be happy to write up some user stories in JIRA for this if it would help.


I agree. My idea is to have “maintainers” of a module—all of whom have equal ability to edit it and upload new versions.

In Modulus, we’ll have a user table containing a row for each user, and a table defining relationships between users and modules. (This will all be configured automatically by grails :smile:). The previous owners of each of the current modules will be assigned as that module’s sole maintainer.

In the UI, a module maintainer or a system admin should be able to add/remove maintainers from the edit view. I’m thinking of using something like to build a text field that can contain a list of users.

A maintainer can add and remove other maintainers, but not himself—this is to avoid orphaned modules, which require admin action to un-orphan.

A standard user would just be able to see the maintainers of a module they’re looking at. @michael and I were thinking about linking to each user’s OpenMRS Wiki profile from there.

No, not yet! User stories for any interactions we come up with would be great. The tentative plan is for Michael, myself, and anyone who wants to join us to design & document authorization on the technical level.

However, I think authorization will be pretty simple—all “write” methods of the API (POSTs, PUTs, DELETEs) will require an authenticated session. We’re planning on using OpenID Connect/OAuth with OpenMRS ID for authentication—and I’d like to look at to see how out-of-the-box we can set up auth to be.

This sounds good, but I think you still want to enforce a single “owner” for a module – i.e., one of the maintainers needs to be identified as the owner, so there’s someone ultimately responsible for overseeing the module. You could accomplish this with a single-select “owner” option that would let you choose from the list of current maintainers. Then there could be up to two maintainers that cannot be removed (yourself and, if it were someone else, the owner).

Makes sense, but what added functionality do you think comes from of having a single owner above everyone else? To be the only user who can delete the module (or some other destructive action)?

Since I’m guessing that most modules will have between 1 and 3 maintainers, I’m having trouble understanding why we need an “owner of owners” in the mix.

It’s fine to have 1-to-n maintainers of a module as far as authority within modulus goes – i.e., all maintainers are created equal; however, one of the maintainers needs to step up into the role of module “owner” for social (not technical) reasons. In other words, the module repository should be able to identify a module owner as an individual.

In truth, it’s probably best to vet this with the developer community. For example:

[quote]In our new module repository, we have the chance to update how modules are maintained and owned. How do you feel about the following options?

  1. Status Quo – a single module owner responsible for any changes to a module (edits, uploading new versions, deleting)

  2. Owner + 1-to-n Maintainers – a single module owner responsible for assigning maintainers & deleting. Maintainers can make edits and upload new versions – i.e., like Google doc editing.

  3. 1-to-n Maintains – any number of maintainers can edit, delete, or assign/revoke other maintainers.

Or is there a 4th option that we haven’t considered? [/quote] Maybe make that into a topic and then copy the question to the dev list with a link to the topic within for people to comment. Does this thing do polls? :smile:

1 Like

To be clear, scenario 3 (1-to-n) is what was supported in modrepo by @bwolfe and is what will will be initially supported in Modulus. I’m not saying that’s right, but it’s the starting point from where we’re beginning. Scenario 1 above was never allowed.

Yes. Discourse can run polls but it’s still poorly documented. See:

So, I think I will start coding for scenario 3 (1-to-n). We can agree on that to start, and adding if we decide to switch to scenario 2 we can just build on top of this code.

I’ll send an email to the dev list shortly, linking them to this discussion.

The few comments so far from the dev list say we should have the option to indicate an owner (link to user or text field for organizations), but operate with a list of privileged users for maintenance.

Yes option three was the model in the legacy modrepo. I think there was a text field for the “owner” too that was pulled from the omod. It did nothing for auth purposes, was just a point of contact for downloaders.