# User

## Description

User represents an identity in the ERP system with a lifecycle managed through status transitions. Each user has an email (unique identifier), name, and status that controls system access. The status-based lifecycle ensures controlled provisioning: users start PENDING until verified, become ACTIVE for full access, and transition to INACTIVE when access should be revoked while preserving data for audit purposes.

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

## Domain Model Definitions

### Model type

Stateful

#### State Transitions

```mermaid
stateDiagram-v2
    [*] --> Pending: createUser
    Pending --> Active: activateUser
    Active --> Inactive: deactivateUser
    Inactive --> Active: reactivateUser
```

| Operation | From | To | Command |
|-----------|------|----|---------|
| activate | PENDING | ACTIVE | [activateUser](../commands/ActivateUser.md) |
| deactivate | ACTIVE | INACTIVE | [deactivateUser](../commands/DeactivateUser.md) |
| reactivate | INACTIVE | ACTIVE | [reactivateUser](../commands/ReactivateUser.md) |

### Command Definitions

- [createUser](../commands/CreateUser.md)
- [updateUser](../commands/UpdateUser.md)
- [updateOwnProfile](../commands/UpdateOwnProfile.md)
- [activateUser](../commands/ActivateUser.md)
- [deactivateUser](../commands/DeactivateUser.md)
- [reactivateUser](../commands/ReactivateUser.md)

### Query Definitions

### Models

- User

### Invariants

- Email must be unique across all users (active and inactive)
- Email must follow valid email format
- Name is required and cannot be empty
- Status must be one of PENDING, ACTIVE, or INACTIVE
- Only ACTIVE users can receive role assignments
- Permissions array is a computed cache of all permission keys from the user's assigned roles, updated by an executor when role permissions or assignments change

### Relationships

- **Has Many UserRoles**: User is assigned roles through UserRole join records
