@mahitha I did not completely understand the issue. Can you please elaborate on the steps to reproduce the issue? or can you reproduce this in the QA environment if possible?
Thanks @mahitha for letting us know the issue. Yes ideally if the address value does not exist the patient save should work fine with address code as null. Please create a jira ticket for the same.
If a patient does not have address code (null), the patient will not be able to sync back to the connect device. All new events/updates will not be synced. The device will have stale data. Is it right fix?
The idea is that the online Bahmni system should allow the end user to create patients with addresses which are not present in the address hierarchy. Currently with the offline OMOD this functionality is breaking which mean the online Bahmni user is not able to create users with different address.
If the Bahmni connect device is using address based sync strategy and patient in the device is not from the catchment area then the updated data will not be synced from the server to the device. This issue can be solved by training the end users who are using Bahmni connect and educating them to create patients based on the correct catchment area.
System should not restrict the end users to create patient with addresses outside the address hierarchy which currently works if you don’t install Bahmni connect.
Hi @rdeolal, This use case is very specific to your requirement. In such case implementation team will write their own sync strategy to full fill such use cases.
The “LocationBasedSyncStrategy” is meant to be so. Its meant for synchronising data based on catchment locations and what you are doing will break the sync strategy. For what you saying, like Suman said, you should really define your own strategy, and Bahmni provides the extensions for such strategy plugin.
Incidentally, if you didn’t know, you can configure and hierarchy levels to be strict to certain levels. You can follow here. Check the configuration element “strictAutocompleteFromLevel”, which basically says till what level the strictness should be followed. So that way, I still see possibilities of your specific context to be addressed. I clearly don’t see that at all levels you would want ‘manual’ typing (e.g. province, district, subdistricts etc). And if the higher levels still follow the coded addresses from hierarchy entries, I think you still should be able to use the location sync strategy.