tbianchini/shopit-back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a4a8a3ef8fe90d1a8c0f93fca372911f519128e2
shopit-back/app/Domains/Ticketing/Event/documentacion/README.md

2.6 KiB
Raw Blame History

Dominio Event

Propósito

Administra los eventos de un tenant, sus fechas y sus redes sociales.

Modelo

Tenant tiene muchos Event. Cada evento tiene título, subtítulo, descripción, ubicación, texto de fechas y published_at. Sus fechas se guardan en event_dates mediante event_id. El catálogo social_media define las plataformas; event_social_media guarda la URL y el orden de cada cuenta del evento. exact_location guarda opcionalmente un objeto JSON con latitude (-90 a 90) y longitude (-180 a 180). location sigue siendo la dirección legible.

La migración 2026_09_18_000500_restore_events crea un evento por cada tenant que tenía datos de evento o fechas, y migra las fechas y redes correspondientes. 2026_09_18_000600_associate_active_event_social_media copia al evento activo las redes del tenant que falten, sin sobrescribir las URL propias del evento. El seeder de Fiesta Fútbol Infantil hace lo mismo cuando crea el evento en una base nueva.

Storefront

  • onticket muestra el evento señalado por tenants.active_event_id.
  • onticket_multi_event permite varios eventos publicados y mantiene tenants.active_event_id en NULL. La presentación y gestión de esos eventos en el frontend quedan pendientes de diseño.

active_event_id selecciona el evento del storefront de evento único; no indica si está publicado. La asignación de este campo y los cambios de tipo de storefront se administran directamente en la base de datos. La aplicación no valida ni automatiza esas operaciones.

Cuando hay un evento activo, el campo social_media del bootstrap usa sus redes, igual que event.social_media. Las actualizaciones de redes de ese tenant también se guardan en el evento. Sin evento activo se conservan las redes propias del tenant.

API

Los endpoints de AdminApp usan auth:sanctum y adminapp.tenant:

  • GET/PUT /v1/adminapp/tenant/event: acceso al evento seleccionado para el storefront de evento único.
  • POST /v1/adminapp/tenant/event-dates: crea una fecha para ese evento.
  • POST /v1/adminapp/tenant/event-dates/{eventDate}/reschedule y POST /v1/adminapp/tenant/event-dates/{eventDate}/suspend: cambios de fecha.

El bootstrap del tenant entrega event para el evento seleccionado. No entrega una lista de eventos ni existe todavía una pantalla para gestionarlos.

Dependencias

Las fechas se vinculan con variantes de Catalog, que a su vez pueden generar tickets. Los avisos por suspensión y reprogramación se construyen dinámicamente después de excluir los cambios que el usuario ya vio tres veces.