Venues i Locations — el reglament

Estat (2026-04-28): Venue, Location i Location.kind implementats (V90). Events poden ser a un Venue o a una Location directament (V91, CHECK XOR). Cicle de vida unificat de Venue implementat amb V92 (listing_status, vegeu sota). Pendent: responsible_user_id per a Locations standalone amb perfils 3/4 i flow real de Claims (sprint Expedients). Document recull l'estat objectiu post-implementació de governance.

Diferència bàsica

Concepte	Què representa	Exemples
Location	Una referència geogràfica (punt al mapa)	"Plaça Major de Terrassa", "Pavelló Municipal de Mataró", "Centre Cívic Casa Vapor", "Terrassa" (ciutat)
Venue	Un lloc gestionat amb propietari potencial (sala, bar, escola)	"Sala Legends", "Bandits Country Bar", "Escola Step by Step"

Cada Venue té la seva pròpia Location dedicada (1:1) amb les coordenades exactes de l'edifici. NO es comparteix una Location genèrica entre Venues.

A més, hi ha Locations standalone (sense Venue) per a events en espais que no són venues fixos: places, parcs, ubicacions temporals.

Cicle de vida del Venue (V92, 2026-04-28)

Implementat com a venues.listing_status amb el mateix enum ListingStatus que Choreographer (V23).

Estat	Significat	Events creables	Banner públic
INFORMATIVE	Venue registrat però sense propietari acreditat (creator = admin o usuari sense expedient). És l'estat per defecte de tot Venue creat avui	Admin	"Informació no verificada per l'organitzador ni pel propietari del lloc"
PENDING_CLAIM	Sol·licitud de claim oberta, expedient pendent revisió	Admin	Banner mantingut
CLAIMED	Propietat acreditada via expedient. Owner verificat	Owner + admin (override)	Banner desapareix — el lloc està verificat
PENDING_TRANSFER	Transferència d'ownership pendent	Admin	Banner mantingut
SUSPENDED	Retirat (moderació, abús, o local que ja no opera). Cobreix tant la suspensió punitiva com el "tancat per defunció"	Cap	El Venue mateix queda fora de selectors
VERIFIED	Verificació oficial reforçada (reservat futur)	Owner + admin	Banner desapareix

Decisió 2026-04-28 (Opció A): NO afegim un INACTIVE separat. SUSPENDED cobreix els dos casos (moderació + tancament natural). Si en el futur cal distingir, afegirem INACTIVE llavors. La distinció no aporta valor avui.

Promoció avui: només admin via PATCH /api/venues/{id}/listing-status (manualment). El flow de petició de claim per peticionari arribarà amb el sprint d'Expedients (project_claim_expedient_planning.md).

Filtre i visualització: la llista de Venues té un filtre per estat (admin only) i mostra una badge a cada fila. La fitxa del Venue té un Select admin-only per canviar l'estat manualment.

Aquest cicle és paral·lel al de Choreographer (V23) — vocabulari unificat a tota la plataforma.

Tipus de Location (kind)

Una Location té un camp kind per diferenciar tipus de lloc sense convertir-lo en Venue:

Kind	Descripció	Marker al mapa	Exemple
OUTDOOR	Espai a l'aire lliure	Pin simple	Plaça Major, parc municipal, camp de festes
INDOOR_BUILDING	Edifici/sala que no és un Venue oficial	Pin amb icona d'edifici (distingible de Venue)	Pavelló municipal sense Venue creat encara, sala de cultura puntual
CITY_GENERIC	Referència de ciutat/localitat sense lloc concret	Pin desaturat	"Terrassa" com a context general

Regles:

• Una Location associada a un Venue es deriva (no la decideix l'usuari): INDOOR_BUILDING per defecte, OUTDOOR si és pista a l'aire lliure oficial
• Una Location standalone pot ser qualsevol dels tres
• Al mapa, cada kind té el seu marker visual perquè l'usuari distingeixi un Venue acreditat d'una Location informativa

Responsable d'una Location

Tota Location standalone té un responsible_user_id (User responsable). És qui firma les dades davant la plataforma.

• Per defecte: responsible_user_id = createdBy (qui l'ha creat)
• Admin pot reassignar-la (transferència de responsabilitat)
• Si la Location ve d'un Venue (1:1), responsible_user_id és NULL — la responsabilitat l'hereta del Venue (el seu owner)

Aquest camp és diferent de createdBy (auditoria immutable) — responsible_user_id pot canviar.

Carrils de creació d'events

Combinant Venue + Location obtenim els 4 carrils de creació d'events:

Carril	Estat	Cas d'ús
1. Venue CLAIMED	✅ Implementat (esquema)	Owner del venue crea event al seu local
2. Venue INFORMATIVE	✅ Implementat	Admin crea event a un venue sense propietari acreditat
3a. Location INDOOR_BUILDING + admin	✅ Implementat (V91)	Admin crea event a un edifici públic (Centre Cívic) que mai serà Venue
3b. Location OUTDOOR + admin	✅ Implementat (V91)	Admin crea event a un espai obert (plaça, parc)
3c. Location standalone + user responsable	⏳ Pendent (perfil 4)	Persona acreditada (teacher/DJ/organitzador autònom) crea event sota la seva responsabilitat
4. Organization acreditada	⏳ Pendent (perfil 3)	Org crea events itinerants sense venue propi (cas associació)

Sprint 2026-04-27 (feature/event-locations-and-spaces) ha portat el model polimòrfic Venue/Location a l'esquema (events.venue_id o events.location_id, exactament un dels dos via CHECK constraint chk_event_place_xor). El wizard ofereix 3 opcions explícites:

• Local o sala → selector de Venue
• Centre o edifici → selector de Location amb kind=INDOOR_BUILDING
• A l'aire lliure → selector de Location amb kind=OUTDOOR

També es reserva events.organization_id (NULL, sense FK constraint) per al sprint Organizations futur.

Sales dins un Venue (space_label)

Estat: 📝 Documentat però no implementat fins cas real. El camp existeix al schema (V82) com a reserva.

Un Venue pot tenir múltiples sales (Pavelló Municipal amb Sala A + Sala B + Pista Exterior). Avui el sistema no diferencia sales — un Venue = un únic espai per overlap check.

Casuístiques identificades (per documentació, no implementades):

Cas	Descripció	Tractament actual
A	Venue petit amb 1 sol espai (cas majoritari, ~80%)	OK, no afecta
B	Venue gran amb sales paral·leles (Pavelló Municipal: Sala A + B)	Avui no es modela bé — overlap check és massa estricte si dos events simultanis a sales diferents
C	Sala amb tabics mòbils (1 sala que es divideix en 2)	Cas rar, no modelat
D	Edifici amb diversos venues independents (Bar + Escola al mateix Centre Cívic)	Es resol amb 2 Venues diferents al mateix punt
E	Sala temporal en congrés (Palau de Congressos durant unes jornades)	Sense space_label real, només descripció
F	Events a espai obert sense venue (carril 3)	Resol per Location standalone

Decisió actual: deixar space_label com a camp reservat al schema. Activar el vertical slice (DTO + wizard + detail + overlap logic per (venue_id, space_label)) quan aparegui el primer cas B o E real.

Aprovació de Venues creats per usuaris

Estat: ⏳ Pendent (Fase 1B)

Avui qualsevol User autenticat pot crear un Venue via API — risc de soroll/abús al mapa.

Proposta: Venues creats per no-admin entren amb un flag pending_admin_review = true:

• No apareixen a selectors públics fins que admin els valida
• Admin pot aprovar (flag a false, queda INFORMATIVE) o rebutjar (soft delete)
• La reclamació d'ownership va pel flux normal de claims (VENUE_CLAIM)

Locations òrfenes (sense events ni venues)

Estat: ⏳ Pendent — estratègia a definir junt amb el model d'organitzacions

Locations standalone es creen "a demanda" i s'acumulen al mapa. Sense events i sense venues, esdevenen soroll.

Opcions a estudiar (no decidides):

• Filtre soft a cerques: amagar locations sense activitat des de fa N mesos
• Merge de Locations duplicades (patró del Dance merge)
• Vincular a organitzacions quan es dissenyin
• No eliminar mai si té history d'events (integritat referencial)

Què passa amb noms canviats o tancaments

Quan un Venue canvia de nom o tanca:

• Es marca a SUSPENDED (el mateix estat cobreix moderació + tancament natural — Opció A 2026-04-28)
• Si reobre amb un nou nom al mateix lloc: es crea un Venue nou (no es reciclona el vell)
• Si l'edifici canvia totalment de propietari amb continuïtat (ex: un Bar passa a ser una Escola): mateix tractament — Venue nou
• Els events passats vinculats a un Venue suspès hi segueixen apuntant (referència històrica intacta)

Privadesa i GDPR

• Els Venues són dades d'establiment — públiques en general (interès legítim Art. 6.1.f GDPR)
• L'owner d'un Venue és visible al públic com a "verificat" (només nom, no email)
• Si el responsable d'una Location standalone exerceix dret a l'oblit: la Location es reassigna a admin com a placeholder, no es perd
• Les coordenades exactes són públiques (no ocultem on és físicament un Venue)

---

Resum executiu

✅ Venue ↔ Location 1:1 — cada venue té la seva location pròpia amb coords exactes ✅ Locations standalone per espais sense venue (places, parcs) ✅ Cicle Venue unificat amb Choreographer / Organization (INFORMATIVE → CLAIMED) ✅ Location.kind distingeix outdoor / indoor_building / city_generic visualment ✅ Responsible user obligatori per locations standalone ✅ 4 carrils de creació d'events (2 implementats, 2 pendents) ✅ Sales dins venue (space_label) — documentades, no implementades fins cas real

Ordre d'implementació real:

1. ✅ V90 Location.kind
2. ✅ V91 Event polimòrfic Venue/Location amb CHECK XOR + Event.organization_id reservat
3. ✅ V92 Venue listing_status unificat (2026-04-28)
4. ⏳ Sprint Expedients (Claims Module): flow real de petició de claim, manager/delegació, taula d'auditoria, validació estricta de transicions
5. ⏳ Location.responsible_user_id (perfil 4 — persona acreditada)
6. ⏳ Marker visual al mapa diferenciat per kind
7. ⏳ Aprovació de Venues creats per no-admin (flag pending_admin_review)
8. ⏳ Carril 4 (events a Organization) — depèn d'Organizations
9. ⏳ space_label quan aparegui el primer cas real B/E (Món 3)