Release 3.8.3 to main - #191
Merged
Merged
Conversation
…details.otherFields Mobile sends height/weight/bmi/temperature in beneficiaryDetails payload. i_beneficiarydetails_rmnch has no these columns so they were lost. FLW-API getBeneficiaryData reads from otherFields (temperatureValue key). - RMNCHBeneficiaryDetailsRmnch: @transient height/weight/bmi/temperature - BenDetailRepo: updateOtherFieldsByBenRegId query - RmnchDataSyncServiceImpl: merge anthropometry into otherFields after save Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Reads camp:vanID and camp:parkingPlaceID from Redis (written by MMU-API on van login) and stamps them onto RMNCHBeneficiaryDetailsRmnch, RMNCHBornBirthDetails, RMNCHCBACdetails, and RMNCHHouseHoldDetails when the mobile payload carries VanID=null or 0. Also writes anthropometry (height/weight/bmi/temperature) from mobile beneficiaryDetails payload into i_beneficiarydetails.otherFields so FLW-API getBeneficiaryData can return them. Gracefully skips if Redis has no camp configured. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…merge Hibernate merge() returns new managed instances that do not carry @transient field values (height/weight/bmi/temperature). Keep a reference to the original list before saveAll so the anthropometry loop reads from objects that still have the mobile payload values. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
getObject("camp:vanID", false, 0) was calling EXPIRE key 0 which
immediately deletes the key in Redis after every sync. Replaced with
getRaw() which reads the value without modifying TTL, so camp:vanID
persists across multiple syncs until MMU logout.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The Stop TB mobile app calls this RMNCH sync endpoint directly to save household details. Same issue as elsewhere: vanID stamping is skipped silently when Redis has no camp:vanID, so household records end up with vanID=NULL. When stoptb.enforce.vanid=true, sync now fails with a clear error instead.
…RMNCH records Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing.
…RMNCH records Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing.
Reads camp:vanID and camp:parkingPlaceID from Redis (written by MMU-API on van login) and stamps them onto RMNCHBeneficiaryDetailsRmnch, RMNCHBornBirthDetails, RMNCHCBACdetails, and RMNCHHouseHoldDetails when the mobile payload carries VanID=null or 0. Also writes anthropometry (height/weight/bmi/temperature) from mobile beneficiaryDetails payload into i_beneficiarydetails.otherFields so FLW-API getBeneficiaryData can return them. Gracefully skips if Redis has no camp configured. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…merge Hibernate merge() returns new managed instances that do not carry @transient field values (height/weight/bmi/temperature). Keep a reference to the original list before saveAll so the anthropometry loop reads from objects that still have the mobile payload values. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
getObject("camp:vanID", false, 0) was calling EXPIRE key 0 which
immediately deletes the key in Redis after every sync. Replaced with
getRaw() which reads the value without modifying TTL, so camp:vanID
persists across multiple syncs until MMU logout.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The Stop TB mobile app calls this RMNCH sync endpoint directly to save household details. Same issue as elsewhere: vanID stamping is skipped silently when Redis has no camp:vanID, so household records end up with vanID=NULL. When stoptb.enforce.vanid=true, sync now fails with a clear error instead.
* docs(readme): add documentation badge * chore(swagger): automate swagger sync to amrit-docs * chore(swagger): automate swagger sync to amrit-docs * chore(swagger): update github workflow for swagger json * fix(swagger): fix the stop api issue in swagger workflow * fix(swagger): removed the unnecessary initial sleep * chore(swagger): add env-driven Dev/UAT/Demo servers and update swagger workflow
…RMNCH records Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing.
…e-longitude' into vb/counselling # Conflicts: # src/main/java/com/iemr/common/identity/data/rmnch/RMNCHBeneficiaryDetailsRmnch.java # src/main/java/com/iemr/common/identity/service/rmnch/RmnchDataSyncServiceImpl.java
…RMNCH records (#167) Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing. Co-authored-by: Sehjot Singh Pannu <sehjot.singh@unthinkable.co>
A transient Redis connection blip during isTokenDenylisted() was thrown as an exception and treated as authentication failure, causing valid, unexpired JWTs to be intermittently rejected with 401 during normal API calls (e.g. beneficiary registration). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This reverts commit 03ad7fe.
…-millis gpsTimestamp createIdentity() parsed the request body with a bare new Gson(), whose default Timestamp adapter only accepts ISO8601 date strings. The new gpsTimestamp field is sent as raw epoch millis, causing JsonSyntaxException during parsing whenever GPS data is present. That exception propagated up through JwtUserIdValidationFilter's catch block and was misreported as a 401 Authorization error. InputMapper already registers a Timestamp adapter that handles epoch millis correctly; switch createIdentity() to use it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
SQL had 6 placeholders but object array had 7 elements including vanID, causing parameter index out of bounds error. Added vanID to INSERT columns. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
permPinCode was already stored correctly in i_beneficiaryaddress but was never surfaced in the RMNCH sync response, since the response DTO had no pinCode field and the address mapping never copied it across. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prints the raw request body, parsed IdentityDTO, and svc.createIdentity result so a Linux-server trace can show whether the beneficiary is actually being saved. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prints request body and response so the AMRIT sync path can be traced alongside the registerNew flow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: authenticate elasticsearch health probes against secured cluster The /health Elasticsearch client was built without credentials, so probes against a security-enabled cluster returned 401 and reported ES DOWN (forcing overall status DOWN) even though ES was healthy. Inject elasticsearch.username/ password and attach a BasicCredentialsProvider, matching ElasticsearchConfig. Auth is skipped when username is blank (ES security disabled). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: pom version --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… detailRepo.save Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DOB fix in benficiary table
…ization FLW-Mobile-App's Household.kt serializes the field as "Pincode" (capital P), but the entity had no @SerializedName so Gson's exact-case field matching against "pincode" silently dropped the value on every sync. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New address VARCHAR(500) column added to i_householddetails so household address can be captured once at HH Registration instead of being duplicated per-member on i_beneficiaryaddress. Accepts both "address" and "Address" keys during sync, following the same pattern as the earlier pincode key-case bug. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolves conflict in IdentityController.createIdentity: keeps the new Gson() parser from release-3.8.3 (matches Common-API's serializer for dob/gpsTimestamp) while retaining the [TRACE][Identity-API] debug logging added on vb/visit.
Vb/visit
* feat: write anthropometry from rmnch/syncDataToAmrit to i_beneficiarydetails.otherFields Mobile sends height/weight/bmi/temperature in beneficiaryDetails payload. i_beneficiarydetails_rmnch has no these columns so they were lost. FLW-API getBeneficiaryData reads from otherFields (temperatureValue key). - RMNCHBeneficiaryDetailsRmnch: @transient height/weight/bmi/temperature - BenDetailRepo: updateOtherFieldsByBenRegId query - RmnchDataSyncServiceImpl: merge anthropometry into otherFields after save Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: stamp vanID from Redis on all 4 RMNCH entities in syncDataToAmrit Reads camp:vanID and camp:parkingPlaceID from Redis (written by MMU-API on van login) and stamps them onto RMNCHBeneficiaryDetailsRmnch, RMNCHBornBirthDetails, RMNCHCBACdetails, and RMNCHHouseHoldDetails when the mobile payload carries VanID=null or 0. Also writes anthropometry (height/weight/bmi/temperature) from mobile beneficiaryDetails payload into i_beneficiarydetails.otherFields so FLW-API getBeneficiaryData can return them. Gracefully skips if Redis has no camp configured. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: preserve @transient anthropometry fields lost after JPA saveAll merge Hibernate merge() returns new managed instances that do not carry @transient field values (height/weight/bmi/temperature). Keep a reference to the original list before saveAll so the anthropometry loop reads from objects that still have the mobile payload values. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: prevent camp:vanID deletion on every syncDataToAmrit call getObject("camp:vanID", false, 0) was calling EXPIRE key 0 which immediately deletes the key in Redis after every sync. Replaced with getRaw() which reads the value without modifying TTL, so camp:vanID persists across multiple syncs until MMU logout. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat(stoptb): add stoptb.enforce.vanid flag to syncDataToAmrit The Stop TB mobile app calls this RMNCH sync endpoint directly to save household details. Same issue as elsewhere: vanID stamping is skipped silently when Redis has no camp:vanID, so household records end up with vanID=NULL. When stoptb.enforce.vanid=true, sync now fails with a clear error instead. * feat(STOP-148): add GPS location capture support for beneficiary and RMNCH records Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing. * feat(STOP-148): add GPS location capture support for beneficiary and RMNCH records (#167) Introduces GPS-related fields (gpsLatitude, gpsLongitude, digipin, gpsTimestamp, isGpsUnavailable, and gpsUnavailableReason) across beneficiary address and RMNCH domain models, including MBeneficiaryaddress, Address DTO, RMNCHBeneficiaryDetailsRmnch, and RMNCHHouseHoldDetails. Enhances IdentityMapper and IdentityService to map and persist GPS information between incoming DTOs and beneficiary address entities. Updates RmnchDataSyncServiceImpl to extract and synchronize GPS details from the nested i_bendemographics payload during beneficiary sync, and to parse gpsTimestamp from household details during RMNCH household data processing. Co-authored-by: Sehjot Singh Pannu <sehjot.singh@unthinkable.co> * fix(STOP-148): use InputMapper Gson for createIdentity to parse epoch-millis gpsTimestamp createIdentity() parsed the request body with a bare new Gson(), whose default Timestamp adapter only accepts ISO8601 date strings. The new gpsTimestamp field is sent as raw epoch millis, causing JsonSyntaxException during parsing whenever GPS data is present. That exception propagated up through JwtUserIdValidationFilter's catch block and was misreported as a 401 Authorization error. InputMapper already registers a Timestamp adapter that handles epoch millis correctly; switch createIdentity() to use it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(datasync): add vanID column to BenGenID import INSERT query SQL had 6 placeholders but object array had 7 elements including vanID, causing parameter index out of bounds error. Added vanID to INSERT columns. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(rmnch): surface pinCode in beneficiary details sync response permPinCode was already stored correctly in i_beneficiaryaddress but was never surfaced in the RMNCH sync response, since the response DTO had no pinCode field and the address mapping never copied it across. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(dob): stop global Timestamp adapter from nulling dob on GPS-enabled endpoints The GPS feature (STOP-148) registered a custom Gson TypeAdapter<Timestamp> globally on InputMapper's GsonBuilder to parse the new gpsTimestamp field. Because it was global, it also intercepted dob, silently returning null whenever the incoming date string didn't match one of its four hardcoded formats. - Add GpsTimestampAdapter, attached only via @JsonAdapter on the gpsTimestamp field (Address, RMNCHBeneficiaryDetailsRmnch, RMNCHHouseHoldDetails), so it can't affect any other Timestamp field. - Remove the global registerTypeAdapter(Timestamp.class, ...) from both InputMapper.java copies, restoring Gson's default Timestamp parsing for dob and everything else (matching vb/stoptb). - Revert createIdentity()'s parser back to a bare new Gson(), matching Common-API's RegisterBenificiaryServiceImpl, which also serializes the outgoing identity payload with a bare new Gson(). InputMapper's setDateFormat is incompatible with that wire format (non-zero-padded day), which is why dob was nulling specifically for beneficiaries born on the 1st-9th of a month once createIdentity switched to InputMapper's Gson. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Sehjot Singh Pannu <sehjot.singh@unthinkable.co>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…titutionName fields
…ization FLW-Mobile-App's Household.kt serializes the field as "Pincode" (capital P), but the entity had no @SerializedName so Gson's exact-case field matching against "pincode" silently dropped the value on every sync. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New address VARCHAR(500) column added to i_householddetails so household address can be captured once at HH Registration instead of being duplicated per-member on i_beneficiaryaddress. Accepts both "address" and "Address" keys during sync, following the same pattern as the earlier pincode key-case bug. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
chore(release): bump version to 3.8.3
Vb/release 3.8.3 fix merge
i_beneficiarydetails_rmnch.CreatedDate was trusting whatever the syncing device sent, with no validation. Confirmed on UAT: 48/463 rows future-dated (up to 2026-08-29, ~3 weeks ahead), 6/463 stuck at the 1970 epoch default — both classic broken-device-clock symptoms (never set, or set ahead). Add isPlausibleDeviceTimestamp() (rejects null, epoch-default, and future-dated values) and apply it in syncDataToAmrit()'s RMNCH beneficiary details block: - Existing record already has a plausible CreatedDate -> keep it; a later re-sync must never overwrite a good value with a possibly-bad one. - Existing record's value is bad but this sync's incoming value is plausible -> self-heal using the incoming value. - Neither is plausible (broken clock both times) -> fall back to server sync time as the least-wrong value instead of storing garbage. - New record with a plausible device value -> trust it as-is, since offline captures legitimately sync well after the actual event. Build verified: mvn -o clean compile, BUILD SUCCESS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(rmnch): stop garbage device timestamps from corrupting CreatedDate
…rce.vanid config - IdentityService.createIdentity(): previously had zero enforce-vanid check at all (only RmnchDataSyncServiceImpl had it) - now throws if vanID is missing and enforceVanID=true, matching the convention everywhere else - Remove inline :false default from stoptb.enforce.vanid @value in both IdentityService and RmnchDataSyncServiceImpl - every properties file must set this explicitly now, so a forgotten config fails loudly at startup instead of running fail-open - Add stoptb.enforce.vanid=false to the 1097_* profile properties (separate Maven build sharing these same classes, not a van deployment, so stays false, but must be explicit) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Added van id to tables
…ision - RMNCHBeneficiaryDetailsRmnch: mobile sends VanID=0 as a placeholder (not null) for a fresh record - the existing '== null' check never caught it, leaving the real vanID from Redis unapplied. Now checks for both null and 0. - Both RMNCHBeneficiaryDetailsRmnch and RMNCHHouseHoldDetails map their VanSerialNo column to a Java field literally named 'id' with no @SerializedName - any incoming JSON payload that happens to carry its own 'id' key collides with it during Gson deserialization, silently overwriting the intended VanSerialNo with whatever unrelated value the client sent (observed live: every row stuck at VanSerialNo=1). Added updateVanSerialNo() to both repos and call it after each saveAll(), same pattern already used for i_beneficiaryimage/i_beneficiaryaddress in IdentityService.createIdentity(). - Left RMNCHCBACdetails/RMNCHBornBirthDetails alone despite sharing the same id-collision pattern - not part of the Stop TB flow, zero rows in practice, out of scope for this fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(stoptb): fix RMNCH VanID placeholder-zero and id/VanSerialNo coll…
Redis (camp:vanID) was written once at MMU login and deleted globally, unscoped, on ANY user's logout — a Redis outage or an unrelated user's logout would silently break RMNCH sync on this camp. Each camp/van already runs its own dedicated backend instance, so which van this is never actually changes at runtime. syncDataToAmrit() now reads vanID from the new stoptb.van.id property (no inline default, every properties file must set it explicitly, same convention as stoptb.enforce.vanid) instead of an inline Redis lookup via RedisStorage. Removed the now-unused RedisStorage dependency from this class. Added stoptb.van.id=0 to the 1097 (Helpline) profile's properties files too, since RmnchDataSyncServiceImpl is shared with that build and the property now has no inline default. Scope: vanID only, parkingPlaceID is not part of this change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(stoptb): read vanID from stoptb.van.id property instead of Redis
Co-authored-by: Saurav Mishra <80103738+SauravBizbRolly@users.noreply.github.com>
Removing duplicate fields in i_beneficiaryaddress table (#186)
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 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 |
|
SauravBizbRolly
approved these changes
Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 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.