As part of MOD-13: Upload new releases in modulus, we need to design a UI for uploading a release to an existing module. I’ve had trouble coming up with something simple that can integrate with the Show Module page, so let’s brainstorm some ideas.
These are the required inputs to upload a new release:
The new file
Version of this release
Required version of OpenMRS
The last two can be auto-determined once MOD-3 is completed, but should still be editable as part of the upload process, in my opinion. (However users should never be uploading a module that’s versioned improperly.)
Here are some design ideas of mine:
Include a link or button next to the “Releases” table heading that says “Upload New”. Clicking that shows a small form above the table, with an area to select or drag-drop the OMOD file and two text inputs for Version and OpenMRS Version Requirement.
Similar to the idea above, but with the upload form appearing in a popover or modal over the page.
Whatever happens, I don’t think the Upload New form has enough content to merit putting it on its own page. That would interrupt the user’s idea of state and would create a pretty empty page (just a file select, two text fields, and a button)
I really want this to eventually be seamlessly integrated with the maven release deployment process. That would require a rest endpoint for pushing a new omod file, and capturing the uploader’s identification somehow in the process. I assume that should go in a new ticket, but it definitely informs this design.
We need to allow for a range of OpenMRS versions, e.g. [1.6.2-1.6.8, 1.7.0, 1.8.2-1.8.4, 1.10.0], where the module does not work with 1.7.1 or any of 1.9.x. This is possible through the required_version element in config.xml since 1.6, and should be reflected in the module repository.
I also think we should have some way of reverting to previous uploads of the same version of a module, if a new one has been uploaded recently. If someone posts reporting-0.8.2.omod twice, which one is more valid?
Also, let’s consider letting community members flag a module version as faulty or inaccurate in what versions of what modules it supports.
Yet another idea; some modules do not require others to load but still interact with them through reflection. We should allow a user to indicate other modules (and specific versions of them) that are required and/or are compatible with this one.
Yeah—I think what that means is that we shouldn’t require much more information that what can be extracted from a config.xml. As far as I can tell, as long as the maven client has stored an authorization token, we can use the same REST endpoint that Modulus-UI uses
Today, Modulus will let you post two releases with the same version number (!). I personally don’t think the same version number should be able to be used twice. This has the potential to confuse users when the same version of a module works differently, and could create a support nightmare for the same reason.
With that in mind, I don’t think releases should not be overwritable without intervention from an admin.
I agree that we don’t want multiple releases published with the same version number. However, we should allow module maintainers (or whatever we call them) to replace the upload for a given version. An upload might be corrupt, doesn’t work, etc., and we shouldn’t force someone to increase the version number just because there was a problem with the binary.
We should, however, issue some kind of warning about replacing the uploaded file for a given version, to make sure that it’s only being done when appropriate.
