Move the metadata that must not be changed into the base content package

[dkayiwa]

Reworked after @ibacher's review. The first pass used the wrong test — "needed to run O3" — and moved out more than it should have. Now narrowed to must be set this way. 43 files → 28.

The test used

Does an O3 app or module resolve this by uuid, code or name, such that an implementation changing it breaks the feature rather than customising it?

Not "is it needed to run O3" — as @ibacher points out, most of the demo package is strictly necessary too, so that question discriminates nothing. Awkwardly, the README sentence my first pass quoted states the right test; I quoted it and then applied a different one.

What moves here

	why
encounter types, encounter roles	O3 apps and the emrapi mappings resolve these by uuid
Privilege Level: Full/High, the Application: … roles, module privileges	O3 checks these by name
emrapi metadata source + the fixed term mappings	emr.admissionEncounterType, emr.visitNoteEncounterType, emr.clinicianEncounterRole, …
dispositions + the ADT concepts	emrapi/ward resolve them by concept code (CIEL:168619 lives only in IPD-DEMO, which comes along)
the vital sign concepts + Vital signs set	esm-patient-vitals-app resolves them by uuid
CDU, CLF, CIELAllergySet, DeathCause, DrugDispense, StockManagementConcepts, VitalSignCodes	the dictionaries the above resolve against

What stays in the demo package after the rework

Everything an implementation may reasonably want its own version of, even where O3 needs something there: the identifier types with their idgen source and autogeneration option (sites use their own schemes), visit types, order frequencies, relationship and person attribute types, visit attribute types, procedure types, the vitals/BMI reference ranges (clinical policy), print and ID-sticker defaults, misc concepts, metadata sets, attachments.allowedFileExtensions — plus locations, programs, forms, queues, appointment services and all the catalogs, as before.

metadatatermmappings is split, not moved: emr.primaryIdentifierType and emr.extraPatientIdentifierTypes follow the identifier types they point at, because the mapping must exist but its value is the implementation's choice. That also keeps the invariant that this package references nothing defined only in the demo package — re-verified by sweeping every uuid and CIEL code after the rework.

The one thing I'm knowingly stretching

The Unknown Location tagging. Locations are the canonical implementation-owned thing, so strictly it doesn't belong here. But O3's login page only offers locations tagged Login Location, and with the demo package left out there is nothing to log in to — so this tags the one location that isn't a site's choice, the Unknown Location openmrs-core creates in every database. No facility invented, no uuid created.

Reject this bit if you'd rather. I think it points at a real gap: a bootstrap package (one placeholder location, one identifier source, one visit type) would be the honest home for it, and would let no-demo boot without parking modifiable content here. Evidence it's a real gap and not hypothetical: openmrs/openmrs-distro-referenceapplication@b60dce9 added a no-demo profile last December, and I built and booted it — base 1.4.0 has no location tagged Login Location, so that image cannot complete login and nobody had noticed.

Separately and regardless of how this lands: with no location tagged Queue Location, /home resolves to the Service Queues dashboard and @openmrs/esm-service-queues-app 11.1.0 throws Cannot read properties of undefined (reading 'id') — the first screen after login is an error page. Reproduced, and fixed by the tag.

Verification

• Nothing lost: 100 config files across the two packages before, 103 after, the three extra being the intentional splits (Vital signs, the two core global properties, the tagged Unknown Location). Row/property unions checked file by file.

• Both packages build and pass validate-content-package.

• Booted this package on its own (no demo package, no referencedemodata) and drove the O3 login in a browser. Login completes on Unknown Location, and all eight routes render without errors — /home, appointments, wards, patient lists, laboratory, registration, patient search, system administration.

• But base-alone is not a usable EMR, and this PR does not claim otherwise. Measured on that same instance: visittype is empty, idgen/identifiersource is empty, and the only identifier types are core's own two. So you cannot start a visit, and O3's registration has no source to generate a primary identifier from — a patient can only be created by supplying an identifier by hand through the API. Concepts total 378.

  That is the correct outcome of the boundary, not a regression: visit types and identifier schemes are things a site defines. It is also precisely the argument for the bootstrap package below — an earlier revision of this PR made base-alone fully usable, but only by parking implementation-modifiable metadata here, which is the mistake @ibacher caught.

• Regenerating a demo database from the pair still gives 50 patients, all with encounters, 5821 obs, 278 visits, 11 locations, 7 forms, 4 programs, 0 Site N, and Privilege Level: Full grants identical to the demo-free database (308 = 308).

Notes for reviewers

Filenames are otherwise unchanged on purpose, so several files here are still named *-core_demo.csv. @ibacher suggests fixing the naming rather than the placement — I agree the naming misled me, and I'd happily do a rename pass, but as a separate PR so a 28-file move isn't buried in it.

Existing installs re-import the moved files once: build-distro lays config out as openmrs_config/<domain>/<package>/<file> and names checksums <domain>/<package>_<file>.checksum, so changing the owning package changes both. Idempotent — declarative CSV/XML keyed by uuid.

Merge before openmrs-content-referenceapplication-demo#81.

No O3- ticket yet — happy to retitle.

🤖 Generated with Claude Code

https://claude.ai/code/session_015Rb27z8QxDsmWEkt7Cs3s7