Skip to content

fix(healthcare): prevent false "Not Saved" state in Diagnostic Report after Frappe update#1042

Open
md-umair-21 wants to merge 1 commit into
earthians:developfrom
md-umair-21:dig-rep
Open

fix(healthcare): prevent false "Not Saved" state in Diagnostic Report after Frappe update#1042
md-umair-21 wants to merge 1 commit into
earthians:developfrom
md-umair-21:dig-rep

Conversation

@md-umair-21

@md-umair-21 md-umair-21 commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Issue:-
After upgrading to the latest Frappe/ERPNext version, opening an already approved Diagnostic Report was showing the form in an unsaved state even though no user changes had been made.

Testing

  1. Opening an approved Diagnostic Report after the Frappe/ERPNext update
  2. Confirming the form no longer shows a false "Not Saved" indicator on load
  3. Verifying that actual user edits still mark the form as unsaved
image

This was causing confusion because:

  • the report status was already approved
  • no visible data was changed by the user
  • the form header still showed "Not Saved"

Root Cause:-
The Diagnostic Report observation widget renders result fields using a custom FieldGroup-based UI.
In newer Frappe versions, field initialization/default hydration during render can trigger the custom result field change handler. That handler was directly calling frm.dirty(), which marked the document as unsaved during initial render instead of only during actual user edits.

As a result, simply loading the Diagnostic Report UI could incorrectly set the form to a dirty state.

Fix
After upgrading to newer Frappe/ERPNext versions, the Observation Widget's result field change event could be triggered during field initialization and value hydration. Since the handler directly called frm.dirty(), approved Diagnostic Reports were incorrectly marked as Not Saved immediately after loading.

This fix adds a render-time guard to ignore change events fired during field initialization. As a result:

  • Initial observation value hydration no longer marks the form as unsaved.
  • Actual user modifications continue to mark the form dirty as expected.
  • The behavior remains consistent and compatible across newer Frappe version

Files Changed

  • healthcare/public/js/observation_widget.js

Notes
After pulling this change, run:
bench build --app healthcare

@coderabbitai

coderabbitai Bot commented Jun 22, 2026

Copy link
Copy Markdown

Walkthrough

In observation_widget.js, the init_field_group function gains a rendering guard mechanism. A per-field boolean map (_is_rendering_result_field) is introduced and the current observation's entry is set to true before the result field is created. The result field's change callback checks this flag and returns early if it is set, suppressing form state updates during programmatic value rendering. After field group initialization, a setTimeout(..., 0) asynchronously resets the flag, restoring normal change-handler behavior for subsequent user edits.

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: fixing a false 'Not Saved' state in Diagnostic Report after Frappe update, which aligns with the primary objective of the changeset.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The PR description clearly explains the issue (false 'Not Saved' state), root cause (change handler triggered during initialization), and the fix (render-time guard). It directly relates to the changeset in observation_widget.js.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant