feat(api): expose domain users associated with OCPP tags and transactions

[juherr]

Parent and related issues

• Part of Meta - API Endpoint #1000
• Related, but distinct from Support multi users and rbac #991 and Feature request: Web UI to manage Web-User (login) accounts #2059

Terminology

This issue concerns SteVe's domain user resource: the operator-managed person or organization that can be associated with OCPP tags and transactions.

It does not concern manager login accounts (web_user), API credentials, end-user authentication, or RBAC. Manager/API accounts are tracked separately by #2059, #991, and the dedicated REST API issue linked from #1000.

Problem

The REST API exposes OCPP tag CRUD and transaction queries, but it does not expose the domain users associated with those tags and transactions.

External operator systems must currently use the manager UI or direct database access to create domain users, update their details, and manage associations between users and OCPP tags.

This prevents a complete API-based workflow for provisioning an authorization identity and reporting its charging activity.

Proposal

Expose domain users as REST resources.

POST   /api/v1/users
GET    /api/v1/users
GET    /api/v1/users/{userPk}
PUT    /api/v1/users/{userPk}
DELETE /api/v1/users/{userPk}

The exact URL naming should follow the conventions selected for the existing REST API.

Representation

Expose the non-sensitive fields currently managed by the operator UI, together with stable identifiers and creation/update timestamps where available.

The representation should include or link to associated OCPP tags without duplicating the existing /api/v1/ocppTags resource.

{
  "id": 42,
  "name": "Test User",
  "ocppTags": [
    {
      "id": 7,
      "idTag": "TEST-001"
    }
  ]
}

List filters

Useful filters include name or external reference, OCPP tag ID, active/inactive state if represented by the domain model, pagination, and stable sorting.

Relationships and deletion

The API must document what happens when a domain user is assigned to OCPP tags, referenced by transactions, or deleted while historical charging data exists.

Historical transaction integrity must be preserved. If hard deletion is unsafe, expose the existing disable/archive behavior instead.

Acceptance criteria

• A client can create, retrieve, update, and delete or archive a domain user.
• A client can list domain users with pagination and filters.
• User-to-OCPP-tag relationships are represented without duplicating tag data.
• The API documents how tag associations are created and removed.
• Historical transaction references remain valid.
• Domain users are clearly distinguished from manager/API login accounts.
• All endpoints and schemas are included in OpenAPI.
• Existing manager UI behavior remains unchanged.

Non-goals

• Creating customer-facing login accounts.
• Managing web_user records.
• Implementing RBAC or multi-tenancy.
• Implementing billing, tariffs, or an eMSP user portal.