38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# Dominio Event
|
|
|
|
## Propósito
|
|
|
|
Administra la configuración temporal de un tenant orientado a eventos y sus fechas disponibles.
|
|
|
|
## Componentes
|
|
|
|
- `Models/EventDate.php`: fecha del evento con inicio, fin, tenant y variantes asociadas.
|
|
- `Services/EventService.php`: obtiene y actualiza la configuración de evento del tenant.
|
|
- `Services/EventDateNoticeService.php`: reclama y agrupa los cambios pendientes de cada usuario.
|
|
- `Controllers/AdminApp/EventController.php`: consulta y modificación desde AdminApp.
|
|
- `UpdateEventRequest`: valida datos y reglas cruzadas de fechas.
|
|
- `EventResource`: serializa la configuración de salida.
|
|
|
|
## Endpoints
|
|
|
|
Bajo `/v1/adminapp/tenant/event`, protegidos por `auth:sanctum` y `adminapp.tenant`:
|
|
|
|
- `GET`: obtiene la configuración.
|
|
- `PUT`: actualiza la configuración.
|
|
|
|
Para el storefront autenticado:
|
|
|
|
- `POST /tenants/{tenant}/event-date-notices/claim`: devuelve hasta un aviso de suspensiones y otro de
|
|
reprogramaciones. Cada cambio se muestra como máximo tres veces por usuario.
|
|
|
|
## Dependencias
|
|
|
|
Depende de `Tenant`. Las fechas se vinculan con variantes de `Catalog`, que a su vez pueden generar tickets.
|
|
|
|
## Consideraciones
|
|
|
|
Los avisos se construyen dinámicamente después de excluir los cambios que el usuario ya vio
|
|
tres veces. Al reclamar los avisos se incrementa una vez cada cambio incluido, aunque varios
|
|
cambios aparezcan agrupados en el mismo mensaje. El reclamo bloquea al usuario durante la
|
|
transacción para impedir que pestañas concurrentes superen el máximo.
|