Role Mapping Not Saving When Updating Multiple Roles (Registrar/Nurse/Counsellor) - #162
Conversation
existingRoleIDs (from group.roles) and newRoleIDs (from roleIDs_duringEdit) were compared with plain Array.includes() with no type coercion. When one source returns roleID as a numeric string and the other as a number, an already-existing role fails the match and gets bucketed into both rolesToAdd and rolesToRemove, firing simultaneous create+delete calls that race each other and can silently drop a role (e.g. Counsellor) on update. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rolesToAdd previously fired one SaveWorkLocationMapping POST per role in parallel via forkJoin. The backend treats a create as the sole active role for the user+serviceline+block scope, so separate parallel creates raced each other and only the last commit stayed active - dropping roles added alongside others (reproduced with StopTB Counsellor + Nurse, where Nurse's row was born already deleted). Batch all rolesToAdd into one call instead, with every new role in the previleges[0].ID array - the same shape already used when two roles are added together via Create New Mapping, which works correctly. Location fields (incl. StopTB's nikshayTUID/nikshayFacilityID) are per-group, not per-role, so batching does not change what is sent for them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- newly-added roles (e.g. Nurse + Counsellor) must go out in a single SaveWorkLocationMapping call, not one per role - an existing roleID stored as a numeric string must be treated as equal to the same roleID selected as a number, so it is kept in-place rather than spuriously added and removed at once Regression coverage for the StopTB Counsellor/Nurse role-dropping bug fixed in the previous two commits. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…HWC/FLW
Two related changes to updateGroupedWorkLocation()'s edit flow, both
scoped to make the Select Role checkboxes behave as the single source
of truth: checked = active, unchecked = soft-deleted, and re-checking a
previously-removed role reactivates it rather than piling up duplicates.
1. Stop TB rows are now grouped by user+TU (Nikshay block), same as
HWC/FLW already are, so multiple roles for one user+location show as
one row with multiple role chips instead of a separate row per role.
This also removes the risk of an edit on one role's row reaching into
an unrelated sibling row's role, since everything for that
user+location is already one group.
2. A role in rolesToAdd that has an old soft-deleted row (group.roles
keeps deleted entries; only existingRoleIDs filters them out) is now
reactivated in place via the same {uSRMappingID, deleted:false} call
the existing Activate button already uses, with its location/role
fields refreshed to the current edit form — instead of always
creating a brand-new duplicate row. Only roles with no prior row at
all go through the batched create path added in the previous fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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: 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 |
|



📋 Description
JIRA ID: PSMRI/Admin-API#148
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.