Skip to content

feat: Enforce queue-based workflow for all volunteer actions

Overview:

This merge request enforces a queue-based workflow for all volunteer actions, ensuring that patient-related operations are performed in a structured and consistent manner.

Previously, actions such as recording vitals, verifying medicines, prescriptions, and counseling could be accessed directly from the dashboard. This bypassed the intended queue system, leading to broken patient flow, incorrect status updates, and inconsistent data propagation across workflow stages.

With this change, all direct access to patient actions from the dashboard is removed. Volunteers are now required to select a patient from the appropriate queue before performing any action. Each completed step automatically transitions the patient to the next stage in the workflow, ensuring accurate tracking and data integrity.

This update improves system reliability, enforces proper process flow, and prevents incomplete or incorrectly marked patient records.

What does this MR do and why?

This MR restructures how volunteer actions are executed by enforcing a strict queue-driven workflow instead of allowing direct access from the dashboard.

Motivation: The existing implementation allowed volunteers to perform actions like recording vitals, verifying medicines, prescriptions, and counseling directly from the dashboard. This bypassed the queue system, which is central to maintaining a structured patient flow. As a result:

Patient data did not propagate correctly across stages Patients were not moved to subsequent queues after completing a step Patient status was incorrectly marked as completed despite incomplete workflows

This created inconsistencies in patient tracking and reduced the reliability of the system.

Approach: Removed all direct entry points for patient-related actions from the dashboard Enforced that every action must be initiated through its respective queue Ensured that a valid patient context is always derived from the queue before performing any action Implemented automatic transition of patients to the next queue upon successful completion of a step Added safeguards to block and redirect users attempting to access actions outside the queue flow

Changes Made

  • Removed direct access to all patient-related actions from the volunteer dashboard
  • Updated workflow to enforce action execution only through respective queues
  • Implemented validation to ensure actions are tied to a selected patient from a queue
  • Added automatic transition of patients to the next queue after completing each step
  • Introduced redirection logic to prevent and handle unauthorized direct access attempts
  • Modified relevant components, services, and state handling to support queue-based flow

Technical Details

Adopted a queue-centric architecture where all volunteer actions are routed through dedicated queue modules to enforce a controlled workflow Centralized patient state management to ensure each action operates on a valid queue-selected patient and maintains consistent state transitions Restructured components to separate dashboard (view-only) and queue-driven action components, with clear data flow from queue → selected patient → action → next queue

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

Before - All the components are available in the volunteer dashboard and some of them are entering data directly without following the proper queues so the list of patients and patient status is completely inaccurate. Screenshot_from_2026-04-09_11-03-57 Screenshot_from_2026-04-09_10-56-32

After - Replaced the existing components with queues so that volunteers do not have the direct access to upload data directly without following the proper queues status. Screenshot_from_2026-04-09_10-58-19

How to Set Up and Validate Locally

Pull and checkout the branch:

git fetch origin git checkout 29-feat-enforce-queue-based-workflow-for-all-volunteer-actions

Install dependencies: bun install

Run the development server: bun dev

Validate the changes:

  • Open the app (e.g., http://localhost:5173)
  • Navigate to the volunteer dashboard
  • Verify that direct access to actions (Vitals, Prescriptions, etc.) is blocked or removed
  • Go to the respective queues
  • Select a patient and perform an action
  • Confirm the patient moves to the next queue automatically
  • Ensure the status updates correctly
  • Expected behavior:
  • Actions can only be performed via queues
  • Direct access attempts are blocked and redirected
  • Patient flow progresses correctly across all stages

Testing Done

Describe the testing performed:

  • Manual testing completed
  • Unit tests added/updated

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)

Closes #299 (closed)

Edited by Satyapranavanadh Rayapureddy

Merge request reports

Loading