fix: activation failing for users with no demographics row - #149
fix: activation failing for users with no demographics row#149snehar-nd wants to merge 1 commit into
Conversation
deletedUserDetails dereferenced the m_userdemographics lookup without a null check. v_showuser -- which backs the employee list -- LEFT JOINs m_userdemographics, so a user can legitimately appear in the list with no demographics row; for those users DataByUserID() returns null and the next line NPEs. The exception is caught and returned as HTTP 200 with statusCode 5000, so nothing is written and nothing visibly fails. The demographics update is now skipped (and logged) when the row is absent rather than failing the whole call, so activation applies to m_user as it should. m_user.Deleted is what v_showuser exposes as Deleted, so that write alone is what the list reflects. Also guards the two other unchecked dereferences on this path: a null user row from editData(), and the Boolean unboxing of getDeleted() in the agent-status branch, which NPEs if the payload omits the flag. Co-Authored-By: Claude Opus 5 (1M context) <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 |
|
1 participant
Problem
Clicking Activate on a deactivated user does nothing — the user stays deactivated.
deletedUserDetails(the endpoint the Activate button calls) dereferences them_userdemographicslookup with no null check:v_showuser— the view backing the employee list — LEFT JOINsm_userdemographics, so a user can legitimately appear in the list with no demographics row. For those usersDataByUserID()returnsnulland the next line throws. Thecatchturns it intoresponse.setError(e), which is HTTP 200 withstatusCode: 5000, so the caller sees no HTTP error and nothing is written.Fix
logger.warn) when the row is absent, instead of failing the whole call.m_user.Deletedis whatv_showuserexposes asDeleted, so that write alone is what the list reflects — activation now takes effect.editData().getDeleted()in the agent-status branch, which NPEs if the payload omits the flag.editedDatafor the response body when there's no demographics row (it wassaveDemoData.toString(), itself a latent NPE).Scope
Only
deletedUserDetails. No change to the success path for users that do have a demographics row: same two writes, same order, same response shape.Verification status
The NPE is the strongest candidate and matches every observed symptom, but it has not been confirmed against a live failure — the swallowed error (see the companion UI PR) is precisely what prevents seeing the real exception. To confirm:
grep "deletedUserDetails failed with exception"in the Admin-API log after a failed Activate click. If it names something other than an NPE on demographics, this PR still fixes a real latent bug but may not be the whole story.Related
sn/3.8.4-fix-user-activation— makes the failure visible instead of reporting "Activated successfully". Independent; merge order doesn't matter.deleteUserRoleMapping/ the ASHA reactivation fix onfix/asha-reactivation-facility-check, which is a different endpoint.🤖 Generated with Claude Code