Using Initializer module with unsupported metadata types

Development
, ,
1

Hi,

We are looking into adopting the Initializer module to manage metadata in a Bahmni implementation we are working on. I have some questions about how best to handle metadata that might not be supported by the module such as:

  • Appointment specific config such as service lists (Bahmni)
  • VisitTypes
  • RelationshipTypes
  • ProgramAttribute types

So far possible workarounds seem to be:

  1. Use metadata sharing packages
  2. Custom SQL scripts (insert statements that need to be run manually on the server)

I am not a fan of using metadata sharing packages because there is no easy way to see what metadata has changed. So tracking and evaluating changes becomes problematic and manually running SQL isn’t great either.

Are there any other alternative approaches?

@mksd

2

@nthfloor are you in a position to add the capabilities to the module to handle the non-bahmni-specific metadata? That would be the ideal solution, as it would move the module’s functionality forward for all.

Mike

3

A couple of updates as Iniz is under active development right now.

  • @mseaton I will start work soon on a loader for App Framework’s app configs and extension configs. You guys might be interested in that one?

  • I will start working soon on a generic loader for all *AttributeType.

  • This will lead me to implement a couple of *Attribute specifically, starting with LocationAttribute first.

  • Iniz does load MDS packages as part of the config that it can process, see here.
    While everybody wants to avoid MDS packages, it is still a convenient workaround, at least temporarily while work on the domains that you’re interested in is in progress.

  • VisitType is I think a very easy domain to implement. I was never bothered because of MDS packages for that specific use case, but it’s an easy way to get your hand at Iniz.

  • Programs, workflows and states were just added.

  • Privileges were just added and there is a pending PR for roles.

1 Like
4

Thanks @mksd for these updates good to know. One of my other questions was if there is a roadmap or Jira board to view which features are in progress and what is upcoming, but I take it there isn’t anything publicly available?

@mseaton yes we are considering contributing to this module. But before committing I would like to schedule some time to discuss first with the team working on the module (which I’m assuming involves you @mksd?) to get a better idea of how you are doing things in the module and to see if there is capacity in our team to contribute. Would you be available sometime this week to discuss?

5

Hi @nthfloor,

Currently all Iniz tickets are in-house at Mekom.

I have been saying for a long time that I want Iniz to be transferred to the community. I guess we won’t be willing to do that before the 1.2.0 release. In the meantime I’m happy to share our in-house roadmap/tickets through whatever way that is convenient.

I suggest that we rather speak next week as my schedule is pilling up too quickly. I just invited you to join OpenMRS’ Slack channel, that’s a convenient way to find me. We could IM there ahead of a proper meeting.

6

Hi @mksd, any news on whether Iniz will be transferred to OpenMRS in the near future?

7

Hi @bistenes not yet. As we’re in the middle of our UATs we are too busy. But btw you can always include Iniz as it is as part of any project of yours, just add our Nexus to your POMs (like done here):

<repository>
  <id>mks-nexus-public</id>
  <url>https://nexus.mekomsolutions.net/repository/maven-public/</url>
  <snapshots>
    <updatePolicy>always</updatePolicy>
  </snapshots>
</repository>

Would that be an acceptable workaround in the meantime?

8

Hi Dimitri,

Yeah, I think we’re deciding to start experimenting with using Iniz in the meantime.

Thanks for your help and your continuing work on it.

Do you think the UATs will lead to major breaking changes?