Implement Backend Support for Downsync Process - #179
Open
vanitha1822 wants to merge 43 commits into
Open
Conversation
After MMU user selects their service point/van via getUserVanSpDetails, write camp:vanID and camp:parkingPlaceID to Redis with 30-day TTL. FLW-API and TM-API read these keys to stamp correct vanID on all Stop TB records, enabling MMU DataSync to push data to central. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…l data sync Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…_opd to VALID_TABLES Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…zation Central RoleAuthenticationFilter reads Jwttoken header, not Authorization. Sending as Authorization caused 401 on all central data sync calls. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add /dataSync to skip list in JwtUserIdValidationFilter - Add /dataSync/** to permitAll in SecurityConfig - Revert RestTemplateUtil to send Authorization header for datasync Restores release-3.4.2 behavior for datasync path while keeping WASA security for all other endpoints. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Consistent with release-3.4.2 behavior. Security maintained by @RequestMapping(headers="Authorization") requirement and skip/permitAll configuration for /dataSync/** endpoints. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… records on central
Stop TB tables use vanID (camelCase) while standard AMRIT tables use VanID (PascalCase).
HashMap lookup was case-sensitive causing cleanRecord.get("VanID") to return null for
Stop TB tables, resulting in duplicate check always returning 0 and every sync run
inserting a new record instead of updating the existing one.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Identity-API's saveGeneratedBenIDToLocalServer expects a plain JSON array, not a wrapped object with vanID and benIDList fields. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…to Identity-API Central response does not include vanID in each record. Added loop to inject vanID from the original request into each element of the array. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…BLES These tables were registered in m_synctabledetail but rejected by central's sync endpoint because DataSyncRepositoryCentral's VALID_TABLES whitelist didn't include them, causing "Invalid identifiers provided" errors on every sync attempt. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Merged 3.8.2 from branch
…ALID_TABLES Central's isValidTableName() silently rejects any table not in this allowlist before it ever tries to build SQL against it - a defense against SQL injection via unparameterizable table/column identifiers. Full gap analysis against the van-side m_synctabledetail registration found 5 tables that were registered to push (or about to be) but would still get rejected on arrival at central: - tb_diagnostic_order, tb_diagnostic_result, tb_diagnostic_document: the diagnostic-device (X-ray/TrueNat) integration tables added to FLW-API after this allowlist was last updated. FLW-API already stamps VanID/VanSerialNo correctly on all three. - i_beneficiarydetails_rmnch, i_bornbirthdeatils: never added despite being core Stop TB beneficiary tables. tb_diagnostic_provider_token deliberately excluded - local EMRLite auth/session state, not beneficiary data, shouldn't sync to central. tb_stoptb_visit and i_householddetails were already present from an earlier fix; this closes out the rest of the gap. Companion van-side fix (not in this repo): register the same 7 tables in m_synctabledetail (SyncTableGroupID=11, Stop TB) so the van side actually attempts to push them - see stoptb_sync_tables.sql in ADMIN-UI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(datasync): add missing Stop TB diagnostic/beneficiary tables to V…
t_form_response, t_section_response, t_question_response hold actual per-beneficiary submitted counselling/contact-tracing answers and need to sync to central, same as every other beneficiary-data table. They were never registered here since the Dynamic Form module (V87) postdates this allowlist's last update - identical gap to the diagnostic-device tables fixed earlier. The 7 form-definition/structure tables (t_dynamic_form, t_form_version, t_form_section, t_question_option, t_question_validation, t_option_condition, t_section_question) are deliberately NOT registered - they're seeded once at app startup, not per-van transactional data. Companion fixes (not in this repo): FLW-API now stamps VanSerialNo on all 3 response tables (was previously only stamping VanID), and the van side needs these 3 tables registered in m_synctabledetail. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix(datasync): add Dynamic Form response tables to VALID_TABLES
FLW-API/TM-API/Identity-API no longer read vanID from Redis — they now read stoptb.van.id from properties instead. This write was the source side of that removed mechanism; now dead code with nothing left to consume it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
chore(stoptb): remove camp:vanID/parkingPlaceID Redis write on MMU login
|
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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| + " AS LastModDate, LastDownSyncDate FROM " + schema + "." + table | ||
| + " WHERE CentralID = ? AND VanID = ? "; | ||
|
|
||
| List<Map<String, Object>> resultSet = jdbcTemplate.queryForList(query, centralID, vanID); |
vishwab1
approved these changes
Sep 3, 2026
drtechie
reviewed
Sep 3, 2026
drtechie
left a comment
drtechie
left a comment
Member
There was a problem hiding this comment.
Mostly seems fine. there are some Sonarcube comments
Member
|
Please fix the security comments |
…_downsync # Conflicts: # pom.xml
Member
Author
vishwab1
approved these changes
Sep 8, 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
6 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:
AMM-2421
✅ Type of Change