feat: deactivateOrg to work with tenant code #792
Conversation
WalkthroughController now forwards tenant-id and requester ID to the service when deactivating an organization. Service refactored to deactivate by organizationCode + tenantCode, cascade-deactivate users, remove their sessions, and broadcast end-session events. JSDoc expanded; method signature in service updated accordingly. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Admin as Admin User
participant Ctrl as Controller (v1/admin)
participant Svc as AdminService
participant Org as Org Store
participant Users as User Helper
participant Sess as Session Service
participant Bus as Event Bus
Admin->>Ctrl: POST /deactivateOrg (orgCode, headers.tenant-id)
Ctrl->>Svc: deactivateOrg(orgCode, tenantCode, requesterId)
Svc->>Org: Deactivate organization (orgCode, tenantCode)
Org-->>Svc: Rows affected
Svc->>Users: deactivateUserInOrg(orgCode, tenantCode)
Users-->>Svc: {count, users[]}
alt users deactivated
Svc->>Sess: removeSessions(userIds)
Svc->>Bus: broadcastEndUpcomingSessions(userIds)
end
Svc-->>Ctrl: {status: ORG_DEACTIVATED, deactivated_users: count}
Ctrl-->>Admin: HTTP 200 response
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/services/admin.js (1)
648-649: Consider including more context in error logs.While error logging is present, consider including the
organizationCodeandtenantCodein the error log for better debugging.-console.error('Error in deactivateOrg:', error) +console.error('Error in deactivateOrg:', { error, organizationCode, tenantCode, loggedInUserId })src/controllers/v1/admin.js (1)
157-157: Consider adding validation for the tenant-id header.While the optional chaining prevents runtime errors, consider validating that the tenant-id header is present before calling the service method, as it's a required parameter.
+if (!req.headers?.['tenant-id']) { + throw responses.failureResponse({ + message: 'TENANT_ID_REQUIRED', + statusCode: httpStatusCode.bad_request, + responseCode: 'CLIENT_ERROR', + }) +} + const result = await adminService.deactivateOrg( req.params.id, req.headers?.['tenant-id'], req.decodedToken.id )
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/controllers/v1/admin.js(2 hunks)src/services/admin.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/controllers/**
⚙️ CodeRabbit Configuration File
These are API controllers. Focus on request/response handling, security (auth middleware usage), and proper status codes.
Files:
src/controllers/v1/admin.js
src/services/**
⚙️ CodeRabbit Configuration File
This is core business logic. Please check for correctness, efficiency, and potential edge cases.
Files:
src/services/admin.js
🧠 Learnings (1)
📓 Common learnings
Learnt from: nevil-mathew
PR: ELEVATE-Project/user#776
File: src/services/entities.js:18-23
Timestamp: 2025-07-31T08:44:36.982Z
Learning: In the ELEVATE-Project/user codebase, organizationCode and tenantCode parameters passed to service methods always come from req.decodedToken.organization_code and req.decodedToken.tenant_code, which are guaranteed to be present after token validation. Additional validation for these parameters in service methods is unnecessary as the token validation process ensures they are always available.
🔇 Additional comments (6)
src/services/admin.js (4)
570-588: Excellent JSDoc documentation!The comprehensive documentation clearly describes the method's behavior, parameters, return values, and error scenarios. This will greatly help maintainability.
590-591: Method signature updated correctly to support tenant-based operations.The new signature with
organizationCode,tenantCode, andloggedInUserIdparameters aligns well with the multi-tenant architecture and provides proper audit tracking.
626-637: Robust cascade deactivation with proper session cleanup.The implementation correctly handles the cascade deactivation of users, removes their sessions, and broadcasts events for upcoming session termination. This ensures a clean deactivation flow.
613-624: VerifieddeactivateUserInOrgsignature and return structure
ThedeactivateUserInOrgmethod is defined insrc/database/queries/users.jsand returns[rowsAffected, returnUpdatedUsers ? users : []], matching the[userRowsAffected, updatedUsers]tuple expected by the call insrc/services/admin.js. No changes required.src/controllers/v1/admin.js (2)
122-143: Well-documented controller method with clear parameter descriptions.The JSDoc clearly describes all parameters including the tenant-id header and expected responses. This improves API maintainability.
155-159: Validate route parameter for organization deactivationEnsure that
req.params.idactually carries the organization code (as required byadminService.deactivateOrg) rather than a numeric database ID. The interface-routes config uses/user/v1/admin/deactivateOrg/:id, which by convention suggests an integer ID. Please verify the route-to-controller mapping and either confirm that this param is indeed the code or rename it to:organizationCodefor clarity.
Summary by CodeRabbit