tbianchini/shopit-back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a919e9366b4e4c0d059fa4afa7d93ecbc39d8dcc
shopit-back/app/Domains/Ticket/documentacion
History
ncoronel 573d4fe5e6 Refactor ticket validity handling and improve tests 
- Updated tests for Accommodation, Entry, Food, Merchandise, and Sale controllers to use soft deletes for variants and ensure proper inventory counts.
- Enhanced ticket generation logic to resolve validity from soft-deleted catalog sources.
- Introduced a new TicketValidityResolver service to manage ticket validity based on event dates and variant definitions.
- Removed unnecessary database assertions and improved the clarity of validity checks in tests.
- Added comprehensive tests for the new TicketValidityResolver service, ensuring correct handling of event dates and multi-select options.
- Cleaned up unused code and assertions in existing tests for better maintainability.
2026-08-14 09:00:51 -03:00
..
README.md
Refactor ticket validity handling and improve tests
2026-08-14 09:00:51 -03:00

README.md

Dominio Ticket

Propósito

Genera, valida, consulta y exporta entradas asociadas a compras pagadas de productos o variantes ticketables.

Modelo

  • Ticket: pertenece a tenant y usuario, y conserva referencias a compra, producto, variante y usuario escáner.
  • El nombre y la descripción se calculan dinámicamente desde el producto y la variante; los tickets no persisten una copia de esos textos.
  • ValidityTime: define ventanas absolutas o relativas de vigencia para fechas de evento y opciones de atributos.
  • ValidityTimeType: enum de estrategias de vigencia.

TicketValidityResolver deriva la vigencia desde la variante asociada. Las alternativas de un mismo atributo se combinan con OR y las dimensiones diferentes se combinan con AND. El modelo calcula si un ticket está vigente, vencido o usado, y resuelve sus fechas efectivas de inicio y fin sin persistir vigencias en el ticket.

Flujo de generación

  1. Purchase emite PurchasePaid al confirmarse el pago.
  2. GenerateTicketsForPaidPurchase atiende el evento.
  3. TicketGeneratorService crea los tickets requeridos según ítems, cantidades y vigencia.
  4. El flujo puede emitir disponibilidad para que Notification informe al comprador.

Endpoints

Bajo /tenants/{tenant:codigo}, protegidos por auth:sanctum:

  • GET /tickets.
  • POST /tickets/pdf.

TicketPdfService genera la descarga y TicketResource/ValidityTimeResource definen las respuestas.

Dependencias y reglas

Depende de Purchase, Catalog, Tenant y Auth. La generación debe ser idempotente ante reintentos del evento. TicketNotAvailableException y TicketGenerationException separan indisponibilidad de errores de generación.