Skip to main content

Model d'identitat (User / Person / Roles de domini)

Mòdul: Identitat
Versió: 1.0
Actualitzat: 2024-12
Referència: Veure també Security Playbook

Aquest document descriu el model d'identitat de LDP i com es relacionen:

  • els usuaris que es loguegen al sistema (User),
  • les persones i rols de domini (Person, PersonRole),
  • les fitxes de coreògrafs i altres rols públics (Choreographer, DJ, Teacher, etc.).

1. Capes d'identitat​

Hi ha dues capes separades però relacionades:

  1. Capa de seguretat (User)

    • Pensada per autenticació i autorització.
    • Gestiona:
      • email + password,
      • rols de seguretat (USER, TEACHER, ADMIN),
      • estat del compte.

  2. Capa de domini (Person)

    • Representa persones dins de l'ecosistema del line dance.
    • Pot existir encara que no tinguin login.
    • Gestiona:
      • nom públic,
      • país/ciutat,
      • rols de domini (coreògraf, DJ, teacher…),
      • metadades públiques.

2. Capa de seguretat – User​

Entitat User (resum conceptual):

  • id
  • email (únic, login principal)
  • passwordHash (BCrypt)
  • role (seguretat): USER, ADMIN
  • enabled (bool)
  • lockedUntil? / accountLocked?
  • tokenVersion (per invalidar JWT)
  • timestamps: created_at, updated_at
Phase 2B - Canvi Important

A partir de Phase 2B, TEACHER ja no és un rol de seguretat. S'ha mogut a rol de domini (PersonRoleType.TEACHER). Veure ADR-002 per detalls.

Característiques:

  • Un User sempre té un email únic.
  • El rol de seguretat controla què pot fer dins l'app (RBAC).
  • L'autorització d'edició de recursos es basa en ownership, no en el rol de seguretat.

Detalls tècnics a authentication.md.

3. Capa de domini – Person i PersonRole​

3.1. Entitat Person​

Representa una identitat pública dins de LDP:

  • id
  • displayName (nom públic)
  • country, city
  • publicContact? (email web, xarxes socials…)
  • bio?
  • avatarUrl? (quan es defineixi l'avatar, veure roadmap/avatar-feature.md)
  • timestamps

Una Person pot representar:

  • un individu,
  • un grup (p. ex. un col·lectiu de coreògrafs).

3.2. Taula PersonRole​

Per evitar que una sola entitat s'espremi amb massa camps, es defineixen rols de domini:

  • id
  • person_id → Person
  • role (CHOREOGRAPHER, TEACHER, DJ, ARTIST, STAFF, GUEST, …)
  • metadata (JSONB) per a detalls específics del rol:
    • p. ex. per CHOREOGRAPHER: any d'inici, web oficial, etc.

Una mateixa Person pot tenir múltiples PersonRole:

  • p. ex. una persona pot ser CHOREOGRAPHER i TEACHER.

4. Relació User ↔ Person​

No totes les Person tenen per què tenir User associat:

  • hi pot haver fitxes de coreògrafs que només existeixen com a catàleg, sense compte d'usuari.

Quan una persona sí té usuari:

  • User pot tenir un camp person_id (nullable).
  • En el moment de registre o reclamació de fitxa:
    • es pot enllaçar User.person_id a Person.id.

Regles generals:

  • Cada User com a màxim hauria d'apuntar a una Person.
  • Una Person pot tenir 0 o 1 User associats (fins que no es defineixin escenaris especials).
  • La propietat/gestió d'una fitxa pública es fa a través del sistema d'ownership (veure architecture/ownership-workflow.md).

5. Choreographer i altres rols de domini​

Per facilitar consultes i compatibilitat amb el model actual, es pot mantenir una entitat Choreographer com a vista especialitzada sobre Person + PersonRole.

Opcions:

  • A. Entitat pròpia Choreographer
    • amb FK a person_id,
    • camps específics (si n'hi ha gaires).
  • B. Treballar només amb Person + PersonRole("CHOREOGRAPHER")
    • i crear vistes/DTOs per exposar-ho a l'API.

Independentment de la implementació:

  • la fitxa de coreògraf ha de mostrar:
    • nom públic,
    • país / ciutat,
    • foto/avatar,
    • enllaços oficials (web, xarxes),
    • llistat de danceds associats.

6. Ownership i gestió de fitxes​

El sistema d'ownership permet que un User reclami la gestió d'una fitxa de domini (p. ex. un Choreographer).

Conceptes clau:

  • OwnershipRequest
    • tipus:
      • CLAIM (reclamar fitxa existent),
      • TRANSFER (transferir propietat a un altre usuari).
    • estat:
      • PENDING_CLAIM, PENDING_TRANSFER, APPROVED, REJECTED, CANCELLED.
  • Regles:
    • un User només pot ser owner d'un coreògraf SOLO (no grups),
    • hi ha un unic owner actiu per fitxa (regles al backend).

Detalls funcionals a architecture/ownership-workflow.md.

7. Casos típics​

7.1. Coreògraf sense usuari​

  • Es crea una Person + PersonRole("CHOREOGRAPHER").
  • No hi ha User associat.
  • La fitxa és gestionada per admins fins que algú la reclami.

7.2. Coreògraf que es registra a la plataforma​

  1. Es crea User amb rol de seguretat (p. ex. TEACHER).
  2. Es crea o es troba la Person corresponent.
  3. Es llança un OwnershipRequest(CLAIM) sobre la fitxa de coreògraf.
  4. Un ADMIN aprova la sol·licitud.
  5. A partir d'aquí, el User es considera owner de la fitxa.

7.3. Usuari que representa un grup​

  • Person pot marcar-se com a "grup" a nivell de metadades.
  • Les regles d'ownership poden ser diferents (p. ex. permetre més d'un gestor).
  • De moment, els grups poden ser no reclamables per simplificar (decisió temporal).

8. Documents relacionats​