# User Account Management

## Overview

User Account Management handles the complete user lifecycle from creation through deactivation, including profile updates. Each user has a status that controls their access to the system: PENDING (awaiting activation), ACTIVE (full access), or INACTIVE (access revoked). Status transitions follow defined rules to ensure security and auditability. Profile fields (name, email) can be updated at any point in the lifecycle regardless of status.

This feature provides the foundation for all identity-related operations in the ERP system.

## Business Purpose

Organizations need controlled user provisioning to ensure only authorized individuals can access the system. The status-based lifecycle provides:

- **Onboarding control**: New users start in PENDING status until verified
- **Access management**: Only ACTIVE users can perform operations
- **Profile maintenance**: User name and email can be corrected or updated throughout the account lifecycle
- **Offboarding safety**: Deactivated users retain their data for audit purposes while losing access
- **Compliance tracking**: Clear status transitions support regulatory requirements (GDPR right to rectification supported via profile updates)

## Process Flow

```mermaid
flowchart TD
    A[Create User] --> B[Status: PENDING]
    B --> C{Verification Complete?}
    C -->|Yes| D[Activate User]
    D --> E[Status: ACTIVE]
    E --> F{Employee Leaves?}
    F -->|Yes| G[Deactivate User]
    G --> H[Status: INACTIVE]
    H --> I{Employee Returns?}
    I -->|Yes| J[Reactivate User]
    J --> E

    subgraph Valid Transitions
    B -->|activateUser| E
    E -->|deactivateUser| H
    H -->|reactivateUser| E
    end

    subgraph Profile Updates - Admin
    B -->|updateUser| B
    E -->|updateUser| E
    H -->|updateUser| H
    end

    subgraph Profile Updates - Self
    E -->|updateOwnProfile| E
    end
```

## Scenario Patterns

- **New Employee Onboarding**: HR creates user account with name and email, user starts in PENDING status. After background check and IT setup complete, administrator activates the user.
- **Employee Departure**: When employee resigns or is terminated, administrator deactivates user account. User data is preserved for audit and historical reporting, but all access is revoked.
- **Contractor Return Engagement**: Previously offboarded contractor returns for new project. Administrator reactivates existing account rather than creating duplicate, preserving historical associations.
- **Profile Correction (Admin)**: Administrator updates a user's name after a legal name change via `updateUser`. The update applies immediately regardless of user status.
- **Email Change (Admin)**: Administrator updates a user's email address via `updateUser`. The system validates format and uniqueness before applying the change.
- **Self-Service Profile Update**: An ACTIVE user updates their own name or email via `updateOwnProfile`. The command implicitly targets the calling user — no userId parameter is needed. Only ACTIVE users can update their own profile.
- **Duplicate Prevention**: Attempt to create or update a user with an email already used by another account is rejected with clear error, preventing duplicate accounts.
- **Invalid Activation**: Attempt to activate already-active user or deactivate already-inactive user returns appropriate error with current status.

## Test Cases

- Creating a user with unique email should succeed and set status to PENDING
- Creating a user with duplicate email should fail with USER_ALREADY_EXISTS error
- Activating a PENDING user should transition status to ACTIVE
- Activating an already ACTIVE user should fail with INVALID_STATUS_TRANSITION error
- Deactivating an ACTIVE user should transition status to INACTIVE
- Deactivating a PENDING user should fail with INVALID_STATUS_TRANSITION error
- Reactivating an INACTIVE user should transition status to ACTIVE
- Reactivating a PENDING user should fail with INVALID_STATUS_TRANSITION error
- updateUser: Updating a user's name should succeed for any user status (PENDING, ACTIVE, INACTIVE)
- updateUser: Updating a user's email to a unique valid email should succeed
- updateUser: Updating a user's email to an email already used by another user should fail with USER_ALREADY_EXISTS error
- updateUser: Updating a user with an invalid email format should fail with validation error
- updateUser: Updating a user's name to empty should fail with validation error
- updateUser: Updating a non-existent user should fail with USER_NOT_FOUND error
- updateOwnProfile: ACTIVE user updating own name should succeed
- updateOwnProfile: ACTIVE user updating own email to a unique valid email should succeed
- updateOwnProfile: ACTIVE user updating own email to an email already used by another user should fail with USER_ALREADY_EXISTS error
- updateOwnProfile: PENDING user updating own profile should fail with INVALID_STATUS_TRANSITION error
- updateOwnProfile: INACTIVE user updating own profile should fail with INVALID_STATUS_TRANSITION error
- User email should be validated for proper format
- User name should be required and non-empty

## Reference Links

- [Odoo User Management](https://www.odoo.com/documentation/19.0/applications/general/users.html)
- [NIST Identity Management Guidelines](https://pages.nist.gov/800-63-3/sp800-63a.html)