While we remain in svn, those without full commit privileges still need a way to get module names.
[hidden email] is a limitation only if there are too few people checking it or too few people with the privilege to create a new module. I’ve never had a problem with it, but maybe if we moved it to JIRA like the ITSM
tasks, pending requests would be more noticed (or even automatable).
If/as we move to git, there is no longer any need to assign module names except to avoid duplication, in which case a simple wiki page list would suffice, as
suggested by Ben. We wouldn’t have to import the module itself into the OpenMRS repository until it was ready to be exposed to the community – although it would be nice to be able to follow work in progress to the extent the module creator is willing to expose
I still think we need some sort of central way of seeing at least most of what is out there. But I agree that "[hidden email]" is potentially a bottleneck.
Perhaps just a wiki page describing all the "rules" we have about a module id? That page could have a simple list of moduleids - descriptions so devs can see if the one they want to use is already used. Since we have svn, git, and other external locations
for modules that people can place them, its up to them to decide.
I don't think adding a uuid is really necessary. If two devs create a module with the same id, the first one will be able to upload to the module repo. They second will have to choose to host elsewhere or change their id.
Has anyone ever created a script to help rename a module id easily?
On Sat, May 12, 2012 at 11:29 AM, Mark Goodrich <[hidden email]> wrote:
To add on to that, I can get a module id of providermanagement blessed for the Provider Management module? This module adds a new object, Provider Role, which is linked to a Provider via a column it adds to the Provider table. A Provider
Role can be associated with Provider Attributes, Relationship Types (to specify different types of supported Provider/Patient relationships), and other Provider Roles (to define allowed Supervisor/Supervisee relationships between Provider Roles). The module
provides an API and UI to manage providers and provider relationships. The module is not yet complete, but I will be doing a work-in-progress demo on the Developers's Call next Thursday.