We are getting exception when we are having with obsGroup & both are filled.
Exception: obsDatetime: Cannot be empty or null
As per our exploration so far, when encounterDiagnosis tries to save encounter it does not check & update each observation’s obsDateTime. But it is done while encounter is saved through FormEntrySession.
Please guide us know if this needs to be fixed or are we missing something?
This issue looks similar to below issue which seems to be fixed.
The <encounterDiagnoses/> tag with openmrs-core 2.2 and above saves diagnoses associated with a given encounter as diagnoses rather than obs. This is currently possible in its handler by first saving the encounter in the middle of handling submissions of the involved tags. Saving an encounter requires some preliminary validations which should be specifically done by the FormEntrySession as shared by @rrameshbtech.
Because of this, it’d be better to save diagnoses in an CustomFormSubmissionAction for the associated <encounterDiagnoses/> handler. I’d think and suppose that EncounterDiagnosesElement extends CustomFormSubmissionAction and registers a <postSubmissionAction/> handler referencing itself. This would help avoid re-validating and re-saving the encounter with respect to the involved HTML-form-entry widgets/tags.
@ruhanga I didn’t look into this too deeply, but conceptually this makes sense to me!
Generally, data should be committed as part of a “form submission action”. So it would make sense to for EncounterDiagnosesElement to register a custom form submission action to support this during that stage in the form submission.
(Actually, if EncounterDiagnosesElement lives in the HFE entry module it would also be find to add submission action directly for FormSubmissionActions, but I don’t think it does… in the original design, FormSubmissionActions weren’t easily extensible, and the CustomFormSubmissionAction was a quick attempt to make it possible to extend… if we ever refactor I would think we could move much of the content of FormSubmissionActions into separate “FormSubmissionActions” so in essence most actions would be “Custom”… but anyway, that’s a tangent… )