Fix/family creation failure in Family Grouping module
Overview
This MR fixes the issue where creating a new family in the Family Grouping module fails after clicking the Create Family button. The UI previously showed the error message "Failed to create family" without successfully creating the family record.
The fix ensures that the family creation request is properly sent to the backend and handled correctly, allowing users to successfully create families.
What does this MR do and why?
Previously, when a volunteer attempted to create a family by entering the Book Number and selecting a Family Role, the request failed and displayed an error message.
This issue prevented volunteers from grouping patients into families, which is a key feature of the Family Management system.
This MR resolves the issue by fixing the request handling and ensuring the correct payload is sent to the backend API.
The change improves reliability in the Family Grouping workflow and allows users to successfully create family groups.
Changes Made
Fixed the family creation API request handling. Ensured correct payload is sent when clicking Create Family. Improved error handling when the API request fails. Updated UI state handling for successful family creation. Ensured proper feedback is displayed to the user.
Technical Details
Root Cause:
The family creation request was either not triggering correctly or sending an incorrect payload to the backend API.
Fix:
Corrected the API request logic. Ensured the form data (Book Number and Family Role) is properly passed. Added proper response handling for success and failure states. For new features:
- Architecture decisions made
- State management approach
- Component structure and data flow -->
Type of Change
-
🐛 Bug fix (non-breaking change that fixes an issue) -
✨ New feature (non-breaking change that adds functionality) -
💥 Breaking change (fix or feature that would cause existing functionality to change) -
📝 Documentation update -
🎨 UI/UX improvement -
♻ ️ Refactor (no functional changes) -
⚡ Performance improvement -
🧪 Test update -
🔧 Configuration change -
🚨 Security fix
Related Issues / References
Link to related issues using GitLab syntax:
- related #267 (closed)
Screenshots or Screen Recordings
backend response
How to Set Up and Validate Locally
Testing Done
Test Cases Covered:
| Scenario | Expected Result | Status |
|---|---|---|
| Create family with valid book number | Family should be created successfully | |
| Submit family creation form | API request should be triggered | |
| Error handling | Proper error message should be shown if API fails |
Code Quality Checklist
Code Standards
-
Code follows project conventions (naming, structure, formatting) -
No console.log() or debugger statements left in code -
No unused imports, variables, or functions -
No duplicate code and use of existing components for reusability -
i18n check passed with no hardcoded strings in codebase for i18n support -
TypeScript types are properly defined (no anyunless justified) -
ESLint and Prettier checks pass bun run lint
React Best Practices
-
Components are properly split and single-responsibility -
Hooks follow rules (no conditional hooks, proper dependencies) -
State management is appropriate (local vs global state) -
No unnecessary re-renders (memoization used where needed) -
Event handlers are properly cleaned up
Component Patterns
-
shadcn/ui components used correctly -
Tailwind classes follow utility-first approach -
Responsive design considered (mobile-first if applicable) -
Accessibility attributes included (aria-*, role, etc.) -
Icons from lucide-react used consistently
API & Data Fetching
-
TanStack Query used for server state (if applicable) -
Loading and error states handled -
API types defined in src/types/api.ts -
Axios interceptors handle auth tokens correctly -
Use of Zod for data validations
Error Handling
-
Errors are caught and handled gracefully -
User-friendly error messages displayed -
Errors are being toasted properly -
Network failures handled appropriately
Documentation
-
README.md updated (if setup steps changed) -
.env.exampleupdated (if new env vars added) -
CHANGELOG.md updated (if applicable)
Known Limitations / Technical Debt
Additional Notes
MR Acceptance Checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
abhilash653




