OpenELIS Global now has a module system: a way to add complete features (backend and frontend) to OpenELIS without changing the core code or waiting for a core release. It is merged into develop in PR #4954 and tracked in the module system epic (OGC-1577).
Why
Many implementations need features that matter to one site, one country or one program. Until now these went into the core, or into a fork that drifted with every release. Modules let that work live in its own repository, on its own release cycle, while the core stays the same for everyone.
What a module is
A module is one JAR file. A site installs it by copying the JAR into the modules folder and restarting OpenELIS. A module can bring:
- Its own database tables, through its own Liquibase changelogs
- Its own REST API, under
/rest/modules/<id>/ - Its own permissions, which show up in Role Management
- Its own menu entries and pages, rendered inside the normal OpenELIS UI
- Content inside core pages, through extension slots. For example, a card on the home dashboard, or an action in the patient header.
- Settings, reactions to core events, and report providers
A module reuses the core. It calls the core’s services (patients, samples, users and more) and renders the core’s own UI components, so its pages look and behave like the rest of OpenELIS. It never modifies core tables or core pages.
There are two kinds of module:
| Kind | What it can do |
|---|---|
| module | A full feature: tables, API, pages and menus |
| provider | Only plugs into a core extension point, such as a report |
See it working
The Specimen Follow-up example module uses every feature above. It adds:
- a follow-up tracker with its own table and pages
- a menu under Order
- two permissions
- a dashboard card
Start a new module by copying it.
Developing a module
From a checkout of the core, one command builds the module, installs it, and serves its pages with hot reload:
scripts/dev-stack up --setup light --module ../my-module
Rerun the same command after a Java or database change. See running a module from its source.
The module author guide walks through everything step by step:
- the Maven project and the manifest
- tables, the REST API, permissions and menus
- pages and extension slots
- tests and CI
- a full reference and a troubleshooting table
Deploying a module
On an openelis-docker installation, copy the module JAR into configs/modules/ and restart the webapp. Admin > Modules then shows every installed module and its state. See deploy and operate.
Extension points: growing what modules can do
Modules plug into the core at defined places:
- Frontend slots: today
home.dashboard.cardsandpatient.header.actions - Backend extension points: today
report
New ones are added to the core by a pull request, and the guide explains how:
If your module needs a place in the core that does not exist yet, that is the conversation to start here.
What’s next
- Operations tooling, as sites need it: richer admin reports, more extension points, and pre-deployment checks
- A first module owned by an implementation: a real site workflow built as a module and validated by that site
Get involved
- Read the module author guide and try the example module.
- Developers can find all the links on the For Developers page.
- Tell us in this thread which feature you would build as a module, and which slots or extension points it would need.
We’ve shared a post on LinkedIn introducing the new OpenELIS Module System!
[
this is super dope!