fix(datasync): add Dynamic Form response tables to VALID_TABLES - #175
Conversation
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>
|
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: Pro Plus 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 |
|
2 participants
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.
📋 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.