fix: amm-2368 item to store mapping issue - #148
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughIn ItemToStoreMappingComponent, buffer array update logic was changed to avoid in-place mutation of bufferarray.data. addtoBufferArray, removeRow, and removeItem now operate on copies of the array and reassign the result, including conditional row removal when nested itemID1 becomes empty. ChangesBuffer Array Immutability
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed: dependency version conflict. Check your lock file or package.json. 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 |
|
vishwab1
approved these changes
Jul 1, 2026
vanitha1822
pushed a commit
that referenced
this pull request
Sep 2, 2026
* fix: pom version * feat: added facilty hierachy * feat: chnages in work location maping * feat: chnages in work location maping * fix: modified the work location * fix: corrections * fix: facilty changes * fix: facilty hierachy * fix: inventory * fix: add missing environment URLs for facility and asha supervisor mapping Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: revert Common-UI submodule to main and update pom version to 3.8.1 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: revert Common-UI submodule pointer to match main Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: align Common-UI submodule with release-3.8.1 * fix: added new inventory flow * Work Location Mapping enhancements for Stop TB, search, and select all (#133) * fix: wrap SaveWorkLocationMapping payload in array for grouped role update The userRoleMappings API expects an array but was receiving a single object when adding new roles during grouped edit, causing "Failed to update mapping" error. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: add search to dropdowns, Volunteer role logic, Select All and compareWith fixes - Add search filter to User, State, District, Block dropdowns in work location mapping - Add search icon to all dropdown search boxes across components - Show village dropdown instead of facility for Volunteer role in FLW/HWC - Fix Select All villages not updating UI (new array reference for change detection) - Fix village search losing selection in facility creation (add compareWith) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: select all facilities by ID, move village after role for volunteer - fix select all facilities using ID-based comparison instead of reference/length so filtered search selections are preserved across different searches - move village dropdown after role in both create and edit modes so it appears only after volunteer role is selected Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: keep selected items visible in search dropdowns across all components Selected items no longer disappear when typing in search — filter always includes already-selected items so mat-select retains the selection. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: enable Block and Village dropdowns for Stop TB serviceline Add 'Stop TB' to showBlockDrop and showEditBlockDrop so the work-location form renders Block (required) and Village (required, multi-select) for the new Stop TB serviceline, matching the FLW non-facility flow used by the Volunteer role. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: show Work Location dropdown for non-facility servicelines Re-add Select Work Location field in both create and edit forms, shown only when !isFacilityServiceline. HWC and FLW keep their facility sub-component; TM, MMU, Stop TB and other non-facility servicelines see the dropdown backed by showofficedetails / m_providerserviceaddmapping. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: remove Volunteer special-case from FLW/HWC flow Volunteer role now belongs to the new Stop TB serviceline (non-facility flow), not to FLW/HWC. Drop all isVolunteerSelected / isVolunteerSelectedEdit branches that previously routed Volunteer users around the Facility sub-component. FLW and HWC always use Facility hierarchy; Stop TB uses the old Block/Village/Work Location flow. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add Search and Select All to create-form Village dropdown Mirror the UX of the facility picker and the edit-form village dropdown: the create-form multi-select for Village now has an in-dropdown search box and a Select All checkbox. Affects Stop TB, TM, MMU flows where Village is picked via the parent form (non-facility servicelines). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: hide Work Location dropdown for Stop TB in create and edit forms Stop TB uses block+village mapping, not work location. Work Location is now hidden (create and edit) when isBlockRequired/isBlockRequiredEdit is true, keeping it visible for all other non-facility servicelines. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: show Village for Stop TB by guarding against stale villageFlag Village *ngIf now uses (villageFlag || isBlockRequired) so it renders even when villageFlag is out of sync with isBlockRequired. Also reset isBlockRequired and isVillageRequired in resetAllFields() and in the showBlockDrop else-branch to prevent stale state for non-block servicelines. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: load Block/Village in edit mode for Stop TB serviceline getEditBlockPatchMaster was not called for Stop TB, so the Block and Village dropdowns never appeared when editing a Stop TB mapping. Added Stop TB to the serviceline guard alongside FLW/HWC/TM/MMU. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * AMM-118: Add employee lock controls in admin UI * Sn/active/deactive (#145) * fix: pom version * AMM-118: Add employee lock controls in admin UI * fix: amm-2343 fixed the active deactive functionality * fix: amm-2343 lock/unlock application crash fix --------- Co-authored-by: vishwab1 <vishwanath@navadhiti.com> Co-authored-by: Varun Deep Saini <varun.23bcs10048@ms.sst.scaler.com> Co-authored-by: Sneha <sneha@ADMINs-MacBook-Pro.local> * Bump version from 3.8.1 to 3.8.2 (#146) * fix: amm-2368 item to store mapping issue (#148) Co-authored-by: Sneha <sneha@ADMINs-MacBook-Pro.local> * feat: add nikshay tu/facility/village dropdowns to work location mapping New cascading multi-select dropdowns (TU, Health Facility, Village), shown only for Stop TB, sourced from Admin-API's new Nikshay endpoints. Create flow saves one row per TU x Facility combination, same pattern already used for ASHA Supervisor's multi-facility mapping. Edit flow pre-fills existing selections (including for pre-Nikshay users, who see empty-but-usable dropdowns to migrate onto the new fields), and reconciles changes on save by deactivating old rows and creating fresh ones for the current selection. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: add nikshay location urls to prod/ci/test/local environment configs The nikshay tu/facility/village dropdown feature only had its endpoint urls defined in the gitignored environment.ts, so ng build failed against every real environment config (production, ci, test, local). * fix: send nikshayTUID/nikshayFacilityID on Stop TB work location save saveWorkLocations() built the request payload before the Nikshay TU/ Facility fields existed on the buffer object, so it only referenced facilityID (unused by Stop TB) and never sent nikshayTUID or nikshayFacilityID. The Admin-API backend already accepts and persists both fields, so mappings saved with a NULL facility/TU (shown as N/A in the grid). Also stop showing the standard block/village "Select Village" field for Stop TB in both create and edit mode, since that service line now has its own Nikshay TU -> Facility -> Village cascade; the extra field was redundant and blocked Save until filled. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: include blockID/blockName in Stop TB work location save setWorkLocationObject()'s Stop TB branch built the buffer row without blockID/blockName, so every Stop TB mapping saved those columns as NULL even though the Select Block field is filled in and required in the UI. saveWorkLocations() already reads blockID/blockName generically for every service line, so this just supplies the values using the same objectToBeAdded.Serviceblock pattern other service lines use. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: use Nikshay TU as Block for Stop TB work location save AMRIT's own Block master is sparser than Nikshay's TU list per district, so the generic Block dropdown often had no matching entry for Stop TB users. Hide it for Stop TB and derive blockID/blockName from the selected Nikshay TU instead, in both create and edit flows. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(nikshay): wire work-location-mapping to independent Nikshay hierarchy - Fix Roles loading: move getAllRoles() trigger from District's selectionChange to State's, since it only depends on State.providerServiceMapID — was previously empty if District hadn't been selected yet, for every service line. - Add resolveNikshayDistrictAndLoadTUs(): bridges AMRIT's selected State/District to Nikshay's own State/District by name match, then loads the TU list. AMRIT's State/District dropdowns stay as the single source of truth (still drive getAllRoles/getAllWorkLocations/ getBlockMaster for every service line) — this only resolves the corresponding Nikshay IDs, no new dropdowns added. - Add a genuine single-select "Block" field (TU-sourced) alongside the existing multi-select "TU" field, per updated Stop TB requirements. - Fix 3 leftover districtBranchID references (old AMRIT-village ID field) to nikshayVillageID in Nikshay-specific save/edit code paths, matching the new NikshayVillage entity built in Admin-API today. * feat(nikshay): replace AMRIT-district name-matching with dedicated dropdowns Remove resolveNikshayDistrictAndLoadTUs (bridged AMRIT's District to Nikshay's by name match). AMRIT's own m_District proved unreliable for this: 144 orphaned district rows across all 10 covered states from an earlier abandoned import attempt, plus inconsistent data between dev environments (one had Andhra Pradesh's post-2022 districts, another didn't). Bridging through it meant inheriting that unreliability. Add dedicated "Select State (Nikshay)" / "Select District (Nikshay)" dropdowns instead, shown only for Stop TB, sourced entirely from the independent m_nikshay_state/m_nikshay_district tables — zero AMRIT dependency. AMRIT's own State/District dropdowns are untouched, still driving getAllRoles/getAllWorkLocations/getBlockMaster for every service line as before. * fix(nikshay): merge State/District back into single AMRIT-sourced fields Live testing showed a real bug from the separate Nikshay State/District dropdowns added previously: getAllRoles() only fires on AMRIT State's selectionChange, so if an admin filled the Nikshay-labeled fields but skipped the plain AMRIT ones, Role stayed empty with no explanation. Restore resolveNikshayDistrictAndLoadTUs as the single bridge: AMRIT's State/District are the only fields shown (unchanged, still drive getAllRoles/getAllWorkLocations/getBlockMaster), and selecting District silently resolves the matching Nikshay State/District by name to load the TU list. Shows a clear error if either isn't in Nikshay's data yet, instead of failing silently. Removed the now-dead selectedNikshayState/ selectedNikshayDistrict/nikshayDistrictList/nikshayStateSearch/ nikshayDistrictSearch fields and their filtered-list getters. * fix(nikshay): make District 100% Nikshay-sourced for Stop TB, drop district-level AMRIT matching Live testing confirmed the district-level bridge was the wrong tradeoff: even when it worked, "Select District" still showed AMRIT's incomplete list (missing newer districts like Alluri Sitharama Raju entirely on some environments). District-level matching was also the exact layer where AMRIT's data proved unreliable all session (144 orphaned rows, stale post-2022 reorganization, inconsistent between environments) — no reason to keep depending on it here. New flow: selecting AMRIT State resolves the matching Nikshay state by name (low-risk — ~10 stable names, no reorganization ambiguity) and loads that state's district list directly from m_nikshay_district into "Select District". From there, District is 100% Nikshay data — no further matching. Selecting it loads TUs directly via nikshayDistrictID, no bridge step. AMRIT's districtID goes into the save payload as null for Stop TB rows now (District is a Nikshay object there) — accepted as-is; nothing confirmed to depend on it, not solving for it speculatively. * fix(nikshay): fix Chattisgarh spelling mismatch, make State selection either/or Verified directly against both databases: AMRIT's m_state spells it "Chattisgarh" (one 'h'), Nikshay's own data spells it "Chhattisgarh" (two 'h's, correct). All other ~9 covered states match exactly. Add a small explicit alias for this one verified exception rather than general fuzzy matching. Also fix State's selectionChange calling AMRIT's getAllDistricts() unconditionally alongside the Nikshay resolution — for Stop TB it was firing uselessly (its result was already being ignored by the District dropdown). Now it's a real either/or: Stop TB calls only resolveNikshayStateAndLoadDistricts, every other service line calls only getAllDistricts, matching what each actually needs. * fix(nikshay): fix Edit-flow district resolution and collapse TU/Facility rows Edit was passing an AMRIT district ID straight into the Nikshay TU lookup instead of resolving it by name first, same bug Create had. Also stop creating one row per TU x Facility combination on save (10 TUs x 100 facilities = 1,000 rows for one user) — now a single row per user-role with comma-joined NikshayTUID/NikshayFacilityID, matching the TEXT columns. Edit-mode pre-selection now splits those CSVs back into IDs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(nikshay): wire real Edit entry point and fix DistrictID storage editGroupedRow() is the actual live Edit entry point (editRow() with the correct Stop TB handling was dead code, never called from the template) - it never set isStopTBServicelineEdit or loaded Nikshay selections, so Edit always fell through to the generic AMRIT Work Location field with an empty required District and no roles loaded. Also fixes DistrictID always saving as null for Stop TB: the Create form's District control binds the NikshayDistrict object, whose ID field is nikshayDistrictID, not districtID - reading .districtID silently returned null every time. DistrictID is repurposed to hold the Nikshay district ID directly (AMRIT's own is unused for Stop TB), so Edit can now resolve it straight from the saved row instead of name-matching against fields Stop TB never populates. BlockName also now keeps only the first selected TU's name instead of joining all of them, since Block is meant to stay single-value - the full multi-TU list already lives in NikshayTUID/NikshayTUName. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(nikshay): wire Edit to the new saved-TU/Facility/District endpoint mappedWorkLocationsList (backing loadNikshayEditSelections) never carried DistrictID/NikshayTUID/NikshayFacilityID, since the view it comes from doesn't expose those columns - Edit's TU/Facility/Village pickers always loaded empty as a result, regardless of what was actually saved. Fetches them from Admin-API's new /nikshay/location/userMapping endpoint by USRMappingID instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(nikshay): fix Edit District dropdown source and stop relying on a fragile row re-filter Select District in edit mode sourced its options from districts_array (AMRIT), but the resolved value is a Nikshay district ID - no option ever matched, so it always displayed blank even when correctly resolved internally. Now sources from nikshayDistrictList for Stop TB, populated via a new helper since the ID-based resolution path never loaded it. loadNikshayEditSelections() also re-filtered mappedWorkLocationsList by roleName to find "this row" again, even though edit_Details already IS that row - if the filter came up empty for any reason, district-list loading and village pre-selection silently broke while TU/Facility kept working fine (they come from the new endpoint, not this filter). Reads stateName/villageidDb directly off edit_Details instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(nikshay): route Stop TB Update clicks to updateStopTBWorkLocation The Update button calls updateGroupedWorkLocation(), which only special-cased ASHA Supervisor before falling through to a generic rolesToKeep update path with no idea about NikshayTUID/ NikshayFacilityID/Nikshay village IDs - it would silently save a payload missing all of them. updateStopTBWorkLocation() already had the correct TU/Facility/Village reconciliation logic but was never actually called from here, only from the unrelated updateWorkLocation() function the Update button doesn't use for grouped rows. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(nikshay): fix Stop TB update payload shape - was silently saving nothing buildNewRows() sent a flat object shape directly to /userRoleMappings, but that endpoint parses a specific nested structure (previleges[].ID[]) - confirmed by comparing against saveWorkLocations(), the Create flow's actual working payload builder. The mismatched shape meant the backend's nested-array parsing found nothing to iterate over, so it silently created zero rows, no error surfaced. Combined with the delete calls that run first (deactivating the old row), every Update click was quietly deleting the mapping with nothing to replace it. buildNewRows() now builds the same previleges/ID nested shape saveWorkLocations() already sends successfully. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(nikshay): switch Stop TB Update to the shared in-place update path updateStopTBWorkLocation()'s deactivate-then-recreate approach left a trail of deactivated ghost rows behind on every single edit (confirmed: updateUserRoleMapping, the true in-place update endpoint, already handles NikshayTUID/NikshayFacilityID correctly - the deactivate/ recreate dance was never actually necessary). updateGroupedWorkLocation()'s existing rolesToKeep/rolesToRemove/ rolesToAdd reconciliation - already used by every other serviceline - is now Nikshay-aware: block/village/nikshayTUID/nikshayFacilityID come from the Nikshay TU/Facility/Village pickers for Stop TB instead of the generic AMRIT block/village pickers. Existing roles update in place via their existing USRMappingID, only genuinely new roles create a new row. Removed updateStopTBWorkLocation() and its dead-code guard in updateWorkLocation() entirely - fully unreachable now, not just unused. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(nikshay): add Edit District picker for old users, block Villageid overwrite Old-style Stop TB users have no saved NikshayTUID/DistrictID, so Edit had no way to even start a District->TU->Facility->Village pick for them. Select District is now editable for Stop TB and tries, in order: auto-select from saved data (unchanged), name-match against a genuinely old row's real AMRIT WorkingDistrictName (only ever populated for pre-Nikshay rows, which went through the old AMRIT work-location flow), then falls back to populated-but-unselected options for the admin to pick manually. Also stops the Nikshay Village picker's selection from ever reaching Villageid, in either Create or Edit. Villageid holds AMRIT village IDs everywhere else in the system, including the mobile app's own beneficiary worklist match (BenFlowStatus.villageID) - saving Nikshay village IDs into it breaks that match, silently cutting a worker off from beneficiaries they can already see. Create sends null (safe, nothing to erase yet); Edit round-trips the row's existing villageidDb/villageNameDb unchanged, since updateUserRoleMapping's setVillageID/setVillageName are unconditional overwrites with no null-check - sending null there would have erased real data instead of leaving it alone. Revisit once a Nikshay-village-to-AMRIT-village bridge table exists to translate safely. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(nikshay): make Select Block functional, enable Village overwrite in Edit Select Block existed in Create but never actually did anything - selectedNikshayBlock wasn't read anywhere, just a decorative single-select. Picking a Block now adds that TU into the Select TU multi-select (onNikshayBlockChange), covering the common one-TU case fast while Select TU still handles picking more. Edit gets the same two-field layout Create already had (previously Edit only had one combined "Select TU (Block)" field). Also, per explicit instruction: Edit now saves the Nikshay Village picker's selection directly into Villageid/VillageName, overwriting whatever was there before (Create is unchanged, still sends null for new users). This reverses the round-trip-existing-value safety behavior from earlier - Villageid still holds AMRIT village IDs everywhere else in the system, including the mobile app's own beneficiary worklist match, so a worker edited through this path will not see beneficiaries in these villages in their worklist until a Nikshay-village-to-AMRIT-village bridge table exists to translate between the two numbering systems. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat: add nikshay tu/facility/village dropdowns to work location mapping New cascading multi-select dropdowns (TU, Health Facility, Village), shown only for Stop TB, sourced from Admin-API's new Nikshay endpoints. Create flow saves one row per TU x Facility combination, same pattern already used for ASHA Supervisor's multi-facility mapping. Edit flow pre-fills existing selections (including for pre-Nikshay users, who see empty-but-usable dropdowns to migrate onto the new fields), and reconciles changes on save by deactivating old rows and creating fresh ones for the current selection. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: add nikshay location urls to prod/ci/test/local environment configs The nikshay tu/facility/village dropdown feature only had its endpoint urls defined in the gitignored environment.ts, so ng build failed against every real environment config (production, ci, test, local). * fix: default provider Valid Till to 5 years out instead of today Valid Till previously defaulted to the creation date, so a provider created without the admin explicitly extending it would fail login the very next day (validTill > now() check in Common-API login). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: stop tb village save on create + edit dropdown gaps - Stop TB Create was hardcoding villageID/villageName to null, silently dropping the admin's village selection; it now saves them the same way Edit already does. - Old-style (pre-Nikshay) Stop TB users no longer get a guessed district auto-selected on Edit via AMRIT name-matching, and no longer inherit a stale AMRIT district ID into the Nikshay district field. District/TU/Facility/Village now come up blank for these rows so the admin picks fresh Nikshay values. - Edit's Stop TB Block/TU/Facility/Village dropdowns now have the same search box and Select All control Create already has. - MMU/TM's Edit Village dropdown was also missing search (had Select All only) - added for consistency. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: scrollable village cell in work location mapping tables Long comma-joined village lists (especially Stop TB's, sourced from an entire TU/facility) were either blowing out row height or, via the table-responsive wrapper, forcing the whole table to scroll horizontally past Edit/Deactivate. The Village cell now gets its own fixed-width, scrollable/draggable box with a hover tooltip showing the full list, so the rest of the columns stay on screen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Vb/release 3.8.2 fix (#156) * fix: stop tb village save on create + edit dropdown gaps - Stop TB Create was hardcoding villageID/villageName to null, silently dropping the admin's village selection; it now saves them the same way Edit already does. - Old-style (pre-Nikshay) Stop TB users no longer get a guessed district auto-selected on Edit via AMRIT name-matching, and no longer inherit a stale AMRIT district ID into the Nikshay district field. District/TU/Facility/Village now come up blank for these rows so the admin picks fresh Nikshay values. - Edit's Stop TB Block/TU/Facility/Village dropdowns now have the same search box and Select All control Create already has. - MMU/TM's Edit Village dropdown was also missing search (had Select All only) - added for consistency. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: scrollable village cell in work location mapping tables Long comma-joined village lists (especially Stop TB's, sourced from an entire TU/facility) were either blowing out row height or, via the table-responsive wrapper, forcing the whole table to scroll horizontally past Edit/Deactivate. The Village cell now gets its own fixed-width, scrollable/draggable box with a hover tooltip showing the full list, so the rest of the columns stay on screen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> * fix: pre-select Select Block with the saved TU in edit work location mapping Stop TB's Select Block is a single-select quick-add convenience over the same TU list Select TU manages (see onNikshayBlockChange) — it isn't a separate saved value. loadNikshayTUsForEditContinued() restored selectedNikshayTUs (so Select TU showed correctly) but never wrote back to selectedNikshayBlock, so it rendered empty on Edit even though the TU/block was fully saved. Pre-fill it whenever exactly one TU is restored, the case for all live Stop TB rows. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: derive Select Block pre-fill from saved blockID, not TU count The previous fix guessed selectedNikshayBlock off selectedNikshayTUs.length == 1, which left Block blank whenever a row had more than one TU (a real, observed case). blockID/blockName on m_userservicerolemapping ARE the saved Select Block value in their own right, stamped by onNikshayBlockChange() at save time independent of how many TUs later joined NikshayTUID. Use getNikshayUserMappingData's blockID directly to look up the matching entry in nikshayTUList instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: save selectedNikshayBlock's TU as blockID/blockName, not array[0] Create's setWorkLocationObject and Edit's updateGroupedWorkLocation both wrote blockID/blockName from selectedNikshayTUs[0] — whichever TU happened to land first in the multi-select array — instead of the TU the admin actually picked in Select Block. That's order-dependent, not selection-dependent: adding a second TU after picking Block, or in a different order, silently changes what gets saved as the block with no relation to what Select Block showed on screen. Both paths now read selectedNikshayBlock.nikshayTUID/tUName directly, falling back to the first selected TU only when Block was never touched. Combined with the earlier edit-load fix (looking the saved blockID up in nikshayTUList), Select Block now round-trips correctly: whatever's picked is what's saved, and it's what shows back up next time the row is edited. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: read saved blockID from edit_Details, not the raw-table endpoint getNikshayUserMappingData() (/admin-api/nikshay/location/userMapping) only returns nikshayTUID/nikshayFacilityID/districtID — verified against a live UAT response — it never carries blockID/blockName. The previous fix read data.blockID from exactly that response, so it was always undefined -> NaN -> the lookup silently no-op'd and Select Block stayed blank on every edit, regardless of what was actually saved. edit_Details already holds blockID/blockName intact — it's sourced from getUserRoleMapped (v_userservicerolemapping) when the row is opened for Edit, which does carry both columns. Pull savedBlockID from there instead. No backend change needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: unlock button disabled after locking a user account (AMM-2343) (#158) Locking a user sets deleted=true and lockedDueToFailedAttempts=true. The Unlock button required deleted !== true to show, so a locked account had no enabled control left to unlock it. Unlock now shows whenever lockedDueToFailedAttempts is true, regardless of deleted, matching the logic already on main/release-3.6.2. Co-authored-by: Sneha <sneha@ADMINs-MacBook-Pro.local> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: vishwab1 <vishwanath@navadhiti.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Vishwanath Balkur <118195001+vishwab1@users.noreply.github.com> Co-authored-by: Varun Deep Saini <varun.23bcs10048@ms.sst.scaler.com> Co-authored-by: Sneha <sneha@ADMINs-MacBook-Pro.local>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 Description
JIRA ID:
AMM-2368
✅ Type of Change
ℹ️ Additional Information
bufferarray was not appending the new data.
Summary by CodeRabbit