Pensar logica release de tickets de evento

[limonrojo-nm]

Liberación de tickets

• los tickets se generan on demand, es decir cuando se va a comprar un ticket
• lo anterior implica que, al menos que identifiquemos que se necesita otro funcionamiento, no es necesario tener los tickets previamente generados
• en cada evento se definen los EventTicketType con su respectivo released_quantity
• Dicho released_quantity establece cuantos tickets de ese tipo se pueden vender
• Al momento de comprar un ticket se verifica que haya tickets disponibles
• available_event_tickets = released_quantity - sold_quantity, donde sold_quantity es un Count de la cantidad de tickets vendidos

Habilitación de venta de tickets

• Se agregaría a EventTicketType un campo booleano is_available_for_sale
• Para vender un ticket no solo se debe verificar que haya tickets disponibles sino que también que is_available_for_sale de dicho tipo de ticket sea True

Cambio de cantidad de tickets disponibles

• En caso de querer modificar el released_quantity de EventTicketType, se deberá validar que la nueva cantidad ingresada sea mayor o igual a la cantidad de tickets vendidos

Generación de tickets

• Al momento de iniciar el proceso de compra se genera el ticket correspondiente
• Se deberá definir al momento de pensar la lógica de venta de tickets el cómo dejar "en reserva" o "en proceso de venta" un ticket, es decir, que no se pueda vender dos veces el mismo cupo (lease released_quantity).
• Dicho ticket posee un token hexadecimal aleatorio unico de 128 caracteres

  
  from django.utils.crypto import get_random_string

get_random_string(length=128)

- El token se genera recien al momento de finalizar la compra

[limonrojo-nm]

@pablop94

[pablop94]

Lo que veo es que al no haber release de tickets, este se parece mucho a #10, si no es igual no? En este sentido si te parece, unifiquemos lo mejor de los dos análisis y sigamos la discusión por un solo canal.

Discutimos un rato y vamos a optar por tener el modelo EventTicketType con los siguientes campos:

class EventTicketType:
    event = Event()
    released_quantity = PositiveInteger()
    available_quantity = PositiveInteger()
    is_available_for_sale = BooleanField()

Podriamos para la reserva y el ticket propiamente dichos, hacer lo sugerido en #25, es decir, tener los siguientes dos modelos:

TicketReservation
  event = ForeignKey(Event)
  customer = ForeignKey(Customer)
  timeout = DateTimeField
  status = CharField(active|stale|completed)

Ticket
  event = ForeignKey(Event)
  customer = ForeignKey(Customer)
  reservation = ForeignKey(TicketReservation)

tener dos modelos permite por un lado no tener campos nulos en muchos objetos y separa los conceptos, además los TicketReservation pueden ser borrados en caso de ser stale