Hi @ssmusoke, this sounds like a plan. We will send a PR as you mentioned. There is no dependency on Bahmni for this OMOD to work.
As mentioned in previous message, the front end is dependent on the bahmni codebase. I want to separate it out of it using openmrs OWA feature. We can have it as part of the same codebase so that the UI and Backend are at one place. This might need some work. What is your opinion?
Just to point out explicitly, as this is a complete rewrite, any existing
data integrity checks/rules that you’d have in prior versions of the
dataintegrity module would be lost when moving to this new version. (And
that’s okay, right?)
@darius yes, that is correct. That is why I have also asked for a version bump from 3.0-SNAPSHOT to 4.0-SNAPSHOT which illustrates a non-compatible change. While leaving the 3.x versions on their own branch
@bharatak, I feel like you are onto something more important than it seems here. Developing features so that not only the module but its UI is shipped as ‘distribution independent’ (albeit perhaps primarily aimed at Bahmni in the case of the Data Quality Dashboard) should ideally be part of OpenMRS development guidelines.
On the OMOD side, we have made our new VDUI module as a set of UI components (Angular components) because we knew that we would port this to Bahmni eventually. However we wanted it to be Ref App friendly for starters. So right now we have got a few GSP pages and fragments that just wrap those components to get it all going where it has to within the Ref App.
But since we have Angular components, we would be really interested to see how this has to be organised (perhaps using OWA as you said) so that we get as close as possible to a situation where the module can be installed on either the Ref App or Bahmni and just functions in both.
We would be more than happy to contribute, perhaps document in the wiki as it goes… etc.
Personally, I think that the distros should be able to accommodate new apps and that way we benefit mutually from the community.
There could be some sort of cross cutting concerns like Authentication and authorization that needs to be taken care. I think sometimes they are very specific to the distros. Things on server side can be managed inside the OMOD (using Context.isAuthenticated() or @Authorized annotation etc). But on client side it becomes difficult across distros.
Its also a good idea to have components (like angular directives or react components) instead of apps and distros provide some sort of container for hosting these components with a simple glue might help for more reusables to be developed.
Regarding your questions around standard guidelines from OpenMRS, I am not sure about it. I see OWA as one way. I’ll leave it to senior openmrs contributors to answer that question.
@sdeepak Thanks for turning this around so quickly - I have merged the PR. @bharatak is there any documentation to provide examples of rules that can be built? I would like this to support those including our team to write rules using this module
@bharatak The documentation is for setting up the module, what I was looking for are how to write some rules - missing obs data, invalid obs data etc - simple examples to get one started. For example if a patient is 5 years old and pregnant, or a 7 year old male on IUD family planning, a pregnant male etc
Dmitri, you are right to highlight this is one of the most important issues facing openmrs at this point.
Setting a good precedent for how developers for didistributions like Bahmni can create functionality that will work in other user interfaces could make or break our ability to collaborate in the future. Since you are actively interested in both the reference application and Bahmni, perhaps you can dedicate some brain cycles to suggesting how shared components can be written, and to reviewing what Bharat and his team put out.
It is clear that the Platform is calling for the ability to plug any UI onto the OpenMRS backend, and it feels that both the Ref App and Bahmni should comply to this new paradigm as much as possible.
In other words, we should have some sort of big picture MVC pattern where the Ref App and Bahmni are just two different views and it would be awesome if we could ever swap the views…
I could definitely think through this a lot more yes when comes the time to migrate VDUI into Bahmni. This is not exactly current yet though…
The only thing I knew, was that ensuring that a UI made of Angular components would eventually make it easier to move things around (simply based on the UI Commons model basically.)