OMRS19 Hackathon Ideas

Hi all,

We all know that the 2019 Implementers Conference is close and usually we have a hackathon session in there :wink: , though we missed a couple of devs at OMRS18’s hackathon :frowning: at Nairobi.

Well this isn’t the official thread for discussing the hackathon for OMRS19; I just had an idea and felt safe to drop here, why not :smile:

Of late I have been interacting with the Program, ProgramWorkflow and the ProgramWorkflowState domains which are catered for by the ProgramWorkflowService at the service layer. There a number of issues I realized with the current implementation of those OpenmrsMetataData objects. These are issues that many devs are actually aware of!


These domains inherit from BaseOpenMRSMetadata but never persist those super properties: see @mogoodrich’s pointers here .

This limits us to majorly identifying these objects by the associated concept. The challenge with this design is that the same concept maybe used as the identifying object in more than one instance ie. it’s possible to have two states associating with the same concept. How this could be an issue? look into : App Framework: AF-59 Extensions to support a "requiredStates" property

Well there is a ticket to cover this : Well I’m not sure on the community priority on this… Just saying it out there;


This service also needs more work and expansion. I don’t need to first loop through all programs to look for a specific state or workflow. Well there is away with the current implementation but can be better.

As a work around on this, I was forced to come-up with a proxy service class with utility methods as helper methods.

I was wondering if this was something that could be pulled off while at the hackathon?

~ Samuel

1 Like

@samuel34 , more issues here

1 Like

@samuel34 this issue was proposed to be worked on in a previous hackathon and up to now its not resolved yet its priority is “must”. I suggest we reconsider it for this year’s hackathon. Otherwise thank you for organizing.

1 Like