Continuing the discussion from Installing modules:
Just a question why doesn’t the OpenMRS platform include core + legacyui + webservices rest for easier kickstarting since this seems to be the most common question here
The rest webservices module is already part of the platform. As for the legacyui module, almost everyone that has downloaded the 2.x platform, of late, ended up installing this module. I therefore agree with you on this because the platform is running page is not what most expected to see. It just confused them. We could just let whoever does not want the legacyui module to uninstall it.
1 Like
I have an alternate suggestion: we should include a “Manage Modules OWA” out of the box, which lets people easily install the Legacy UI through a graphical interface.
This would simplify what people need to do (e.g. it skips the “find your modules folder” step) but it maintains the vision that “OpenMRS Platform” is just a back-end platform.
Sounds like a fair compromise! 
I disagree, from a developer perspective yes but from an implementor perspective why add the extra step just to remain pure? Shouldn’t the purpose or packaging to make life easier for end users?
Good, want to create a ticket for it? 
OpenMRS Platform is a headless back-end that distros can be built on top of. OpenMRS Reference Application is a distro that is functional out of the box (as are Bahmni, UgandaEMR, etc.)
If we want something that provides the legacyui out of the box, I could imagine also having an “OpenMRS Legacy” distro that includes legacyui, xforms, and htmlformentry. But “platform” isn’t actually supposed to be for end-users, as such. (Perhaps we need to improve documentation so that people aren’t downloading the platform when the actually want a full distro…)
Done: PLAT-25. But I took it a little further (see below).
Our goal is to provide all of the administrative functions available in the legacy UI via OWA apps bundled with the platform. Part of the problem with bundling the current Legacy UI module in the Platform is that it’s not just legacy administrative functions, but also the legacy (original) “Reference Application.” I wouldn’t mind bringing the legacy administration functions into the Platform as a stop-gap, but I am not excited about distributing the legacy reference application within the Platform (specifically, JSP-based patient dashboard, cohort builder, reporting, and appointments).
I would love to prioritize designing & building an admin landing page for the Platform (PLAT-29) and then ensuring at least module administration (PLAT-25), OWA administration (PLAT-27), and the already-built concept management (PLAT-28) are included. This page could link to legacy admin functions – i.e., legacy UI minus reference application functions – until we have migrated each of these functions to OWA apps.
I created this Epic for the Platform:
Migrate adminstration functions to Platform (PLAT-12)
- Administration landing page for Platform (PLAT-29)
- Modules (PLAT-25) (including modules and module properties)
- OWA management (PLAT-27) (including OWA app management, OWA settings)
- Bundling the concept management OWA app (PLAT-28)
- Observations (PLAT-20)
- Patients (PLAT-14) (including patient, merging, identifier types & sources, configuration)
- Privileges & Roles (PLAT-13)
- Visits (PLAT-16) (including visit types, visit attribute types, configuration)
- Encounters (PLAT-17) (including encounter, types, and roles)
- Locations (PLAT-19) (including locations, location types that were implemented as “location tags”, location attribute types, address templates)
- Maintenance (PLAT-26) (including configuration, system info, database change log, active user monitor, …)
- Providers (PLAT-18) (including providers and provider attribute types)
- Persons (PLAT-15) (including persons, relationship types, person attribute types)
- Scheduler (PLAT-21)
- Forms (PLAT-23) (including forms, fields, field types, merging fields)
- Programs (PLAT-22) (including programs and states)
- HL7 (PLAT-24) (including HL7 sources, queued messages, held messages, errors, archives)
Each of these could be a sprint (or part of sprint)…
“[Admin Function Here] Platform Migration Sprint”
- Ensure REST endpoints exist & are working to support administration functions.
- Build OWA app
- Bundle with Platform
@burke Thank you for getting the EPICs up. A question - how does this impact the current AdminUI module - does this mean that it will be deprecated in favor of the OWAs?
The AdminUI module is built on the GSP-based UI framework, which we’d like to evolve away from (unfortunately, we don’t say this more clearly on our radar). The GSP-based UI framework was created in response to trying to address shortcomings of JSP-based development in the legacy UI. In the interim, web-based development evolved and there are now better commodity approaches to web application development (i.e., JS clients against RESTful API). In short, we’d like to evolve away from an “OpenMRS way of development” and toward embracing an approach that applies “standard/commodity development tools & approaches” to use the Platform. Currently, OWA apps is the clearest path to applying “standard” web development to the Platform.
It’s a good point, though. The AdminUI’s Configure Metadata page is an alternative approach for an administration landing page (compared to the Reference Application’s System Administration page).
From a UX perspective I vote strongly that we separate “Configure Metadata” (e.g. Encounter Types) vs “Data Management” (e.g. Encounters), i.e. we follow the newer approach from the refapp, not the older approach from the legacy UI admin page.
Otherwise I agree with everything Burke wrote in his post. And really we need to get the community working on building OWA-packaged screens for the required admin functions, so that all the modern distros can use these.
We (@jteich, @dkayiwa, @wyclif, and myself) discussed this on today’s design forum. I think we came to a reasonable compromise given:
- Pragmatism. Bundle legacyui because that’s what most people are using now anyway.
- Messaging. Avoid implying the legacyui is preferred while we are telling people to move away from it.
- Investment. Avoid putting energy in separating admin functions from reference application features in legacyui, since that’s not where we want to be investing effort.
Proposal
Bundle the legacyui module with it disabled by default and refactor the Platform landing page to add wording like
"New development is moving towards OWA apps or building custom client-side apps against the REST API. If, however, you would like to enable the Legacy User Interface you can do so by clicking here.
Clicking on the link would prompt for admin credentials and enable the legacyui module.
This approach would make it easy for people to enable the legacyui while still making it clear that it is not the preferred approach to new development.
We discussed this as well. I agree we don’t want everyone to share a single admin page. I’d rather organize apps & their features around user roles (i.e., workflow) than divide up features strictly based on our data model (metadata vs. data). For example, while not showing Identifier Type management to everyone who needs to manage patient identifiers makes sense, I could easily see someone who to manages Forms or HL7 to prefer doing so in a single place rather than hopping between separate data & metadata apps). I also want to be careful about creating seemingly “arbitrary” separations (to someone who hasn’t memorized the data model) that force users to guess which app they should use. Perhaps your approach will work if we include convenient links (e.g., a system administrator viewing visits & encounters in the “Visit/Encounter Management” app would see additional links to jump straight to the configuration of Encounter Types even if clicking the link took her into a “Configuration” app).