PIH is considering using Initializer for some types of configuration. Probably starting with Drugs. We would need an additional field or two for that loader. How should we go about negotiating those specs, at least until Initializer is brought into OpenMRS (which I take it from this thread is hopefully soon)?
1 Like
Hi @bistenes,
In short, no problem in regards to expanding on drugs.
Initializer to go to the community. I discussed this on the phone with @nthfloor. We will need to keep the control on the next release (1.2.0), “maybe” the following (1.3.0).
Okay, cool. Is Initializer deployed to any Maven repo? Is it possible to use it from the SDK, without checking out the git repo?
You can use our public Maven repo for now, this is a sample read-only config. Could that work for you?
Btw @bistenes, drugs are already supported. I’m curious to know already what limitations you may have faced with them?
Well, I’d thought that we had a non-coded “Concept Dosage Form” field, but then I found out it’s actually coded.
There is metadata (OpenBoxes IDs) associated with the drugs in our CSV drug lists, which are presently loaded with the Dipsensing module. But nothing actually happens with that metadata; i.e., the OpenBoxes IDs are not saved from the CSV into the database. We’d eventually want to save that as a drug reference term.
So actually, on reviewing everything, there are no changes we’d need immediately. Sorry for the bother.
Which version of OpenMRS Core are you using there?
We have stumbled upon an issue with Drugs from Core 2.x. I just haven’t had a chance to look at fixing it yet.
We’re on 2.2.0.
You will probably run into an issue but it’s on our radar and will be fixed soon. This is not supported past Core 1.12.x anymore.
We will introduce compatibility classes to workaround this problem (as well as other challenges). This requires us to completely Springify Iniz.
Both @samuel34 and I are working on it.
1 Like
Oh interesting, okay. I suppose we’ll wait until that problem is mitigated before we try to use it for drugs.
On a very tangential note, w/r/t Springification… I was musing the other day on whether it might be possible to create a standalone Initializer application that doesn’t require starting OpenMRS to run, so that one didn’t have to wait ten minutes for Liquibase, Spring, etc. to see the errors every time one made a configuration change. Is this on your radar at all? Do you think it would be feasible or worthwhile?
Sorry I completely missed your response here!
Sounds interesting, yes. In general I do my trials on a stripped down distro, so it’s not too bad, but such an option would be really cool!
Hi Dimitri, just want to check in on the status of the bug you mentioned above. Is Iniz ready to use for drugs on 2.2.x?
Great!
How’s progress toward getting Iniz into the OpenMRS Maven repo? We’re still interested in using Iniz, but probably not going to do so until it’s no longer completely externally owned.
1 Like
Hi @bistenes I think we will want some of the following items to go through before making Iniz public:
- Support for attributes types.
- Support for attributes in accordance with the supported types.
- Support for some level of configuration for Data Filter (cc @wyclif)
- Support for App Framework’s apps and extensions (TBC)
- Support for auto-loading of peripheral metadata (cc @jsibley)
- Ability to load resources on the classpath (TBC)
@bistenes and @mogoodrich what’s your timeline?
Some remarks/details:
- 4 could be of interest for PIH maybe? Although I think you do most Ref App configuration through code right?
- 6 is a loose wording to give a way to bring HFE forms and all that goes with it (JS files… etc) through an ad-hoc config. This will require some design that we haven’t gone through yet.
Don’t you want the public community to help you implement those items? 
@mksd, I’m with @dkayiwa on this. Hosting in github under the openmrs organization and managing tickets in OpenMRS JIRA do not require the module to be 100% feature complete. It also doesn’t require you to cede significant control practically speaking. I think we should do more to promote more external configuration for distributions and this would be a great way to do that.
It’s not that it’s not yet feature complete, it’s rather than under the relative heat we’re under we feel more comfortable to keep managing the commit history and release process.
But I’ll do it, I have a couple of in house tickets to migrate though, and find the time to setup the CI plan, which never works the first time I try to set it up… 
The community can help you set this up and more. All you need is share whatever needs to be done and we set the ball rolling. 
Awesome, that’s great to hear. Echoing @dkayiwa, please let us know if there are ways we can support you making this transition.