Skip to main content

Workflow d’Ownership de fitxes (CLAIM / TRANSFER)

Aquest document descriu el sistema de reclamació i gestió de propietat de fitxes de domini (sobretot Choreographer) dins de LDP.

Objectiu: garantir que les fitxes “oficials” tinguin un responsable clar, però permetent gestionar reclamacions, transfers i disputes.

1. Conceptes principals​

1.1. Fitxa reclamable​

Tipus de fitxes reclamables (a curt termini):

  • Choreographer SOLO (persona individual).

Fitxes no reclamables de moment:

  • grups (isGroup = true),
  • altres rols (DJ, TEACHER…) fins que es defineixin normes específiques.

1.2. Owner​

  • És el User que té la responsabilitat de gestionar la fitxa.
  • Només hi pot haver un owner actiu per fitxa reclamable.
  • L’owner pot:
    • editar dades públiques de la fitxa,
    • proposar canvis a balls associats,
    • iniciar una transferència de propietat.

1.3. OwnershipRequest​

Entitat conceptual:

  • id
  • choreographerId (o altra fitxa reclamable)
  • requesterUserId
  • targetUserId? (per transfers)
  • type:
    • CLAIM – reclama una fitxa sense owner o amb owner incorrecte.
    • TRANSFER – proposa transferir la propietat a un altre usuari.
  • status:
    • PENDING_CLAIM
    • PENDING_TRANSFER
    • APPROVED
    • REJECTED
    • CANCELLED
  • message (justificació de la sol·licitud)
  • timestamps (created_at, updated_at, resolved_at?)

2. Flux de CLAIM (reclamar fitxa)​

2.1. Precondicions​

  • La fitxa ha de ser de tipus reclamable (coreògraf SOLO).
  • Si ja té owner:
    • es permet CLAIM igualment, però es tracta com una disputa de propietat que haurà de resoldre un ADMIN.

2.2. Passos del flux​

  1. Usuari autenticat navega a una fitxa de coreògraf.
  2. Prem el botó “Reclamar fitxa”.
  3. Es mostra un modal que:
    • recorda que es demanaran evidències,
    • demana un missatge de justificació (message).
  4. En confirmar:
    • es crea un OwnershipRequest de tipus CLAIM amb estat PENDING_CLAIM.
  5. Un ADMIN revisa la sol·licitud:
    • comprova dades, evidències (mails oficials, enllaços, xarxes socials…),
    • si cal, contacta amb l’owner actual o amb l’usuari que reclama.
  6. L’ADMIN decideix:
    • APPROVED:
      • assigna l’usuari com a nou owner (potser substituint l’anterior),
      • marca la resta de sol·licituds relacionades com a resoltes.
    • REJECTED:
      • es manté l’owner actual (o cap si no n’hi havia),
      • es deixa constància del motiu al request.

3. Flux de TRANSFER (transferència voluntària)​

3.1. Precondicions​

  • Només l’owner actual pot iniciar una transferència.
  • Cal conèixer el User de destí (email, id, etc.).

3.2. Passos del flux​

  1. L’owner fa clic a “Transferir propietat” a la fitxa.
  2. Es demana:
    • identificació de l’usuari receptor (email o selector),
    • missatge opcional.
  3. Es crea un OwnershipRequest de tipus TRANSFER amb estat PENDING_TRANSFER.
  4. Un ADMIN rep la sol·licitud i:
    • comprova que:
      • el requester és realment l’owner actual,
      • el targetUserId és correcte.
    • pot contactar amb les dues parts si cal.
  5. L’ADMIN decideix:
    • APPROVED:
      • assigna l’owner a targetUserId,
      • registra el canvi al log/històric.
    • REJECTED:
      • es manté l’owner original.

4. Regles de negoci i restriccions​

  • Un User només pot ser owner d’un coreògraf SOLO (regla 1:1).
  • Les fitxes de grup:
    • actualment no són reclamables,
    • es pot mostrar un missatge: “Fitxa de grup, no reclamable”.
  • No es permeten CLAIMs anònims:
    • cal estar autenticat.
  • Es registra qui i quan ha resolt cada OwnershipRequest.

5. UI i missatges clau​

5.1. Botó “Reclamar fitxa”​

  • Només es mostra si:
    • l’usuari està autenticat,
    • la fitxa és reclamable.
  • Missatge al modal:
    • “Estàs segur que vols reclamar la propietat d’aquesta fitxa?
      Se’t poden demanar evidències per verificar que ets qui dius ser.”

Pot incloure:

  • exemples d’evidències:
    • correu oficial amb el mateix domini que el del web,
    • enllaç a xarxes on es vegi clarament la titularitat, etc.

5.2. Feedback d’estat​

A la fitxa s’hauria de mostrar un petit badge o text segons:

  • PENDING_CLAIM:
    • “Reclamació pendent de revisió”.
  • CLAIMED:
    • “Fitxa reclamada per {nom d’usuari}” (o simplement “Fitxa reclamada” per no exposar dades).
  • Sense owner:
    • “Fitxa informativa (sense gestor assignat)”.

6. Gestió de disputes​

En casos de conflicte (dos usuaris que asseguren ser el mateix coreògraf, etc.):

  • L’ADMIN pot:
    • recollir evidències extra,
    • contactar amb les parts,
    • decidir manualment qui és l’owner o deixar la fitxa sense owner.
  • Opcionalment es poden definir:
    • regles de prioritat (correu oficial, proves de xarxes, etc.),
    • però sempre amb marge per decisió manual.

Aquestes decisions i canvis s’han de documentar internament (log administratiu, no necessàriament públic).

7. Documents relacionats​

  • Model d’identitat: architecture/identity-model
  • Model de dades / restriccions: architecture/db-redesign-plan
  • Rols i permisos: architecture/security
  • Roadmap de funcionalitats relacionades: roadmap/roadmap-global, roadmap/backlog