O3-2996: Add billing module to openmrs distro pom file and spa config

[ODORA0]

This PR is to introduce the Billing and StockManagement modules to the reference application. Billing requires Stock Management as a dependency.

• Added stock management backend module
• Added billing backend module
• Added stock management frontend module
• Added billing frontend module

[gracepotma]

Woohoo!! It will be great to have this included in the O3 RefApp / EMR distro.

[dkayiwa]

Did you intentionally change the patient flags and o2forms modules?

[ODORA0]

Removed, slipped somehow during conflict resolution.

[dkayiwa]

For the above, did you intend to use 2.0.2-SNAPSHOT?

[dkayiwa]

Has version 1.1.0 of the billing module been released?

[ODORA0]

Yes, this was released. We had to do this also when we were adding domains to iniz that depends on the released version of the module

[dkayiwa]

I failed to find such a release from this repository: https://github.com/openmrs/openmrs-module-billing
Or are you using another repository?

[alaboso]

@dkayiwa - I think there was a manual release on BambooCI, link

@ODORA0 - The task Build and Validate Configuration is failing because some privileges (likely) reference Roles that may not be in the Roles iniz domain. Please check

[dkayiwa]

I think there was a manual release on BambooCI, link

Could there be a reason why you set this to false? https://github.com/openmrs/openmrs-module-billing/blob/main/pom.xml#L367

For I notice that no tag was created on github https://github.com/openmrs/openmrs-module-billing/tags
And the billing module is still having 1.1.0-SNAPSHOT https://github.com/openmrs/openmrs-module-billing/blob/main/pom.xml#L8

[alaboso]

We didn't set that to false, it must have been a default value and we didn't catch it. We will fix it.

[ODORA0]

The module versions changed and the push configuration updated

[dkayiwa]

Could there be a reason why you are not using the latest snapshot version 1.2.0-SNAPSHOT of this module to take advantage of the latest changes? Just like you have done for the stockmanagement module.

[ibacher]

The build here is failing not because of anything specific to do with versions, but because the OCL package that this tries to add is broken, in the sense that it has mappings to CIEL concepts that are not themselves part of the collection. OCL collections should be complete in the sense that all referenced concepts must be included.

I notice on OCL itself there is a newer version of the collection from OCL with more concepts, which has more concepts and fewer mappings, so it may be that this is fixed by adopting a newer version of the collection.

If you review the logs in the failing Build and Validate Configuration step, you will find a detailed list of every mapping with a missing concept in the collection.

[alaboso]

The build here is failing not because of anything specific to do with versions, but because the OCL package that this tries to add is broken, in the sense that it has mappings to CIEL concepts that are not themselves part of the collection. OCL collections should be complete in the sense that all referenced concepts must be included.

I notice on OCL itself there is a newer version of the collection from OCL with more concepts, which has more concepts and fewer mappings, so it may be that this is fixed by adopting a newer version of the collection.

If you review the logs in the failing Build and Validate Configuration step, you will find a detailed list of every mapping with a missing concept in the collection.

Yes - this is correct @ibacher . so what we have done is, we have gone through the OCL package and updated all the mappings that are broken. We have also bumped initializer module, openconceptlab module and packager-plugin versions. This is to take advantage of latest developments. After all these, there's one error, it's conflicting Clinical consultation concepts. one is [DemoQueue-Service-ClinicalConsultation:Clinical Consultation] used by OCL DemoQueue package and the other is 167410:Clinical consultation] used in OCL billing package
We could use the CIEL:167410 and in both packages and I believe there shouldn't be an error.
Additionally, we will close this PR and create a new one (to simplify merging and rebasing issues) if @ODORA0 agrees that is..