As suggested by @suthagar23, Currently the .omod modules all have their version numbers at the end of its file name, however the current OWA modules naming don’t follow this particular pattern. I believe this is good practice and should also be implemented by the OWA modules. Going forward how can this be enforced across the development and release of all OWA modules? cc @dkayiwa @darius
3 Likes
I would personally love that. Do you have some cycles to look into our process of creating the owa zip to figure out how it can be taken care of?
Yes @dkayiwa,
I believe this can be solved by extracting the version of an OWA from it’s manifest.webapp and appending it to the end of the file name during the bundling process. I also think a PR would need to be raised against the OWA generator to ensure all newly scaffolded apps have this feature.
Do you have any other approach you think would be better suited to solve this?
I’ll work on this and update this thread accordingly.
@dkayiwa I have a raised a PR against some OWA’s namely generator-openmrs-owa PR openmrs-owa-obsadmin PR openmrs-owa-cohortbuilder PR openmrs-owa-addonmanager PR
We had this feature at one point, but then decided to remove it for two reasons:
- It created a version number in the OWA URL
- When you did a deploy with
npm(or manually) this might result in having two copies of the app with different versions
@raff, do you remember that?
The current PR doesn’t address either of these issues. If we decide as a group that these issues don’t matter, that’s fine, but that’s why we removed the feature before :).
Hi @pascal,
- Concerning the first issue, the version number is only used when bundling the OWA to a Zip file, it doesn’t affect the OWA URL to the best of my knowledge.
- Secondly, on the addon-manager app, there is a feature that detects the version of an OWA that the user wants to install and compares it with the already installed version of the OWA, this, in turn, gives an appropriate message to the user e.g
Are you sure you want to upgrade the xxx addonAre you sure you want to downgrade the xxx addonAre you sure you want to overwrite the xxx addonI believe with this feature users can be more comfortable having multiple versions of the app knowing fully well, the addon-manager would give them feedback when they try to upload new OWA’s
If you’ve confirmed that including a version number in the ZIP file name doesn’t affect the URL, that’s great! I haven’t checked recently, so maybe it’s no longer an issue.
The Addon Manager is not the only way to install OWAs as far as I know (I have not used it). What happens during development when the npm script is used, or when the OWA Management interface is used, or when a manual install is done? My guess, although I could definitely be wrong, is that these other methods together are the more commonly used install mechanism.
Noted! I’ll look into the other ways of installing OWA’s and update this thread accordingly.
Was going through this issue and basing on the solution that @jeiddiah implemented, the version number is included in the owa url. I believe this can be solved when uploading the OWA at this line in the openmrs-module-owa module, by modifying the name to remove the version number. @dkayiwa, @pascal
1 Like
I am in favor of stripping the version number from the URL, since this will allow links to stay working across OWA upgrades 
Basing on the previous conversation I have created a ticket OWA-70 to allow the generation of the url during OWA installation not to include a version number if it’s added to the packaged zip file and have put up a PR in the openmrs-module-owa repo. This would work when installation using this module, but when trying the installer in the legacyUI this does not seem to work.
Can I be directed to which other modules help in OWA installation.
Also the OWA generator should be updated, such that when a new OWA is being created it includes the version number when packaging, in the webpack.config file. @pascal, @raff, @dkayiwa