Skip to content

Fix edit fields for benficiary - #196

Merged
vanitha1822 merged 5 commits into
release-3.9.0from
vb/release-3.9.0-fix
Sep 11, 2026
Merged

vanitha1822 merged 5 commits into
release-3.9.0from
vb/release-3.9.0-fix

Conversation

@vishwab1

Copy link
Copy Markdown
Member

📋 Description

JIRA ID:

Please provide a summary of the change and the motivation behind it. Include relevant context and details.


✅ Type of Change

  • 🐞 Bug fix (non-breaking change which resolves an issue)
  • New feature (non-breaking change which adds functionality)
  • 🔥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 🛠 Refactor (change that is neither a fix nor a new feature)
  • ⚙️ Config change (configuration file or build script updates)
  • 📚 Documentation (updates to docs or readme)
  • 🧪 Tests (adding new or updating existing tests)
  • 🎨 UI/UX (changes that affect the user interface)
  • 🚀 Performance (improves performance)
  • 🧹 Chore (miscellaneous changes that don't modify src or test files)

ℹ️ Additional Information

Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.

vishwab1 and others added 4 commits September 11, 2026 12:11
…edit (STOP-444)

RmnchDataSyncServiceImpl's edit-sync path (syncDataToAmrit) only ever wrote
a fixed 13-field whitelist to i_beneficiarydetails when updating an existing
beneficiary (name/dob/gender/maritalstatus/family fields). occupation,
community, religion, pincode, and phone number were silently dropped on
every edit, regardless of what the app actually sent.

Root cause: these fields are either sent nested inside i_bendemographics
(only ever read for GPS before this fix), in a benPhoneMaps[] array, or
under lowercase JSON keys (e.g. "villageid") that don't case-match the
Java field names (e.g. villageId) under Gson's default case-sensitive
binding. Traced and verified against real captured edit payloads, not
assumed field names.

Changes:
- RMNCHBeneficiaryDetailsRmnch: add occupation/occupationId/phoneNo fields
  (previously had no field to bind these into at all).
- RMNCHMBenMappingRepo: add getByBenRegId(), needed to resolve a
  beneficiary's address/contact rows for the edit.
- RmnchDataSyncServiceImpl:
  - extract occupation/community/pinCode/blockID from i_bendemographics,
    phoneNo from benPhoneMaps[0], and villageid/villagename directly
    (case-mismatch workaround) during the existing GPS-extraction pass
  - set community/occupation/religion onto the updated detail entity
  - new updateAddressAndContactOnEdit(): resolves the beneficiary's
    address/contact rows via i_beneficiarymapping and updates pinCode,
    block (via the already-correctly-bound facilitySelection), district,
    village, and phone -- only for fields the incoming payload actually
    sent, so an edit that only changes name/occupation can't blank out
    address data it didn't include

Deliberately NOT fixed here: economicStatus. The app sends it, but no
persisted column for it exists on the beneficiary record in this schema --
it appears to belong on the household record (i_householddetails.type_bpl_apl)
instead. Persisting it onto the beneficiary would be guessing at the wrong
data model without confirmation.

Verified live end-to-end against a real edit (benRegId 45387): occupation,
community, pincode, block, village, and phone all confirmed landing
correctly in the database.

Household edit has a separate, more severe bug (full-object overwrite
silently wipes street/colony/village on any edit) -- out of scope for this
commit, tracked separately.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pom.xml still said 3.8.3 on this branch (cut from release-3.9.0) --
version string was never bumped when the branch was created.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pull in latest upstream (33abfc8 - fix: edit in ES (#193)) before pushing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as the earlier occupation/community fix, found while
investigating two more fields reported not updating: "type of residential
area" and "socioeconomic status".

Both economicStatus/economicStatusId and residentialArea/residentialAreaId
are real columns on i_beneficiarydetails -- confirmed 100% NULL across
every row in the table, including freshly created ones, meaning no code
path (create or edit) had ever written to them. The app already sends both
values every sync, nested inside i_bendemographics.

residentialArea/residentialAreaId were initially (incorrectly) placed on
RMNCHMBeneficiaryaddress in an earlier pass of this fix -- caught and
corrected by cross-checking against FLW-API's own RMNCHMBeneficiarydetail,
which already declares both fields on i_beneficiarydetails. That mistake
never shipped; caught before this branch was ever restarted with it.

Every field touched across both fix commits (community, occupation,
religion, economicStatus, residentialArea, pinCode, block, district,
village, phone) has now been cross-verified against FLW-API's
independently-built entity model for the same tables, not just assumed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 11, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 19da50b0-b5ab-40cb-ad33-1cf02405f11a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

….9.0-fix

PR #195 (the occupation/community/religion/pincode/phone fix) was already
merged into release-3.9.0 directly, likely as a squash, losing the common
ancestor with this branch. Resulting conflicts were both trivial -- this
branch's economicStatus/residentialArea additions sitting next to lines
origin no longer recognizes as related -- resolved by keeping both sides'
actual changes (nothing here overwrites or removes anything from #195).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@vanitha1822
vanitha1822 merged commit acbd7a6 into release-3.9.0 Sep 11, 2026
4 checks passed
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.

2 participants