Skip to content

Fix/family creation failure in Family Grouping module

mondyagu abhilash requested to merge fix/family-grouping into develop

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:

Screenshots or Screen Recordings

Screenshot_from_2026-03-25_15-18-47
before

Screenshot_from_2026-03-25_15-19-04

Screenshot_from_2026-03-25_15-19-15 after

backend response

Screenshot_from_2026-03-26_16-05-01

Screenshot_from_2026-03-26_16-06-09

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 any unless 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.example updated (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

Edited by mondyagu abhilash

Merge request reports

Loading