The OpenMRS Initializer module is an API-only module that processes the content of the configuration folder when it is found inside OpenMRS' application data directory.
Despite the various capabilities there are for adding location tags within the locations domain, there are circumstances where it is clearer and easier to maintain to have separate initializer configuration files for locations, tags, and location tag maps. This most commonly comes into play where you may want to maintain a common set of locations, but customize exactly what tags are applied to those mappings on a given server via exclusion criteria applied at runtime.
In order to support this, we should add a new "locationtagmaps" domain. This domain will work almost exactly like the locations domain, except it will only manipulate the tags associated with a location. Like the locations domain, it will only add or remove those tags that are explicitly listed as columns in the CSV, in order to preserve the ability for some tags to be managed manually outside of initializer as needed.
Columns:
"Location" - the uuid or name of the location
"Name of Tag 1" - true / empty
"Name of Tag 2" - true / empty
...
"Name of Tag N" - true / empty
The row processor will:
Retrieve the location with the given value from the "Location" column
Iterate over all other columns, retrieve the Location Tag that matches the column name. If the value is "true", add the tag to this Location.
Update the Location by removing or adding tags to match what was found in step 2, logging the specific changes.
@mks-d / @mogoodrich / @brandones FYI. Interested in your opinions on this domain and the intended approach.
Despite the various capabilities there are for adding location tags within the locations domain, there are circumstances where it is clearer and easier to maintain to have separate initializer configuration files for locations, tags, and location tag maps. This most commonly comes into play where you may want to maintain a common set of locations, but customize exactly what tags are applied to those mappings on a given server via exclusion criteria applied at runtime.
In order to support this, we should add a new "locationtagmaps" domain. This domain will work almost exactly like the locations domain, except it will only manipulate the tags associated with a location. Like the locations domain, it will only add or remove those tags that are explicitly listed as columns in the CSV, in order to preserve the ability for some tags to be managed manually outside of initializer as needed.
Columns: "Location" - the uuid or name of the location "Name of Tag 1" - true / empty "Name of Tag 2" - true / empty ... "Name of Tag N" - true / empty
The row processor will:
@mks-d / @mogoodrich / @brandones FYI. Interested in your opinions on this domain and the intended approach.