Hi all,
We all know that the 2019 Implementers Conference is close and usually we have a hackathon session in there 
, though we missed a couple of devs at OMRS18’s hackathon 
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 
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!
OpenmrsMetataData
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 : https://issues.openmrs.org/browse/TRUNK-1748 Well I’m not sure on the community priority on this… Just saying it out there;
ProgramWorkflowService
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