Fix edit fields for benficiary - #196
Conversation
…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>
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>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
….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>
|



📋 Description
JIRA ID:
Please provide a summary of the change and the motivation behind it. Include relevant context and details.
✅ Type of Change
ℹ️ Additional Information
Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.