Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mutación — Regalar Ticket #30

Open
fforres opened this issue Aug 5, 2023 · 3 comments
Open

Mutación — Regalar Ticket #30

fforres opened this issue Aug 5, 2023 · 3 comments
Labels
Backend mutation Mutation Request

Comments

@fforres
Copy link
Member

fforres commented Aug 5, 2023

Un usuario puede regalar un userTicket a otro usuario.

Cuando un userTicket se regala a otro usuario, el userTicket queda en estado "pendiente de aceptación".

este userTicket no puede ser redimido hasta que la invitación sea aceptada, rechazada, o retirada.

Permisos:

  • Solo el dueño del ticket puede regalar un ticket.
@fforres fforres added the mutation Mutation Request label Aug 5, 2023
@Pillin
Copy link

Pillin commented Aug 5, 2023

Inputs necesario:
Correo del destinatario
ID del ticket

@Pillin
Copy link

Pillin commented Aug 5, 2023 •
edited
Loading

.

@Pillin Pillin added the Backend label Aug 5, 2023
@fforres
Copy link
Member Author

fforres commented Oct 3, 2023

@Benjvvp creo q no deberíamos hacer esta parte ahora al toke. Deberíamos implementar la API en las versiones más básicas primero. (onda...api sin frontend...niun brillo 😆 )

Dejo escrita la explicacion igual :)

Esto es cuando yo tengo un ticket. (lo compré, o lo reservé)
Pero no puedo asistir al evento.

Entonces en ves de cancelarlo, se lo quiero regalar a alguien más.

Estos flujos tienen 3 entidades principales. UsuarioA, UserTicketA, UsuarioB

Flujo de aceptacion

  • UsuarioA pide el UserTicketA
  • UsuarioA inicia el proceso de "regalo de tickets" de UserTickeA hacia `UserB
  • UsuarioB recibe un correo que dice "Te estan regalando un ticket, aceptalo en la página xxxxx"
  • UsuarioB va a la página y ve que tiene un ticket "por aceptar"
  • UsuarioB acepta el ticket UserTicketA
  • FIN

Flujo de Cancelacion

  • UsuarioA pide el UserTicketA
  • UsuarioA inicia el proceso de "regalo de tickets" de UserTickeA hacia `UserB
  • UsuarioA Cancela el regalo
  • FIN

Flujo de Rechazo

  • UsuarioA pide el UserTicketA
  • UsuarioA inicia el proceso de "regalo de tickets" de UserTickeA hacia `UserB
  • UsuarioB No acepta el regalo
  • UsuarioA recibe un correo con "Tu regalo fue rechazado"
  • FIN

Esto quiere decir que tenemos que tener una tabla nueva de "UserTicketGifts", que tenga una referencia al GifterUser ReceiverUser, UserTickets y con un campo status (pa ver si fue aceptado/rechazado/etc)

This was referenced Oct 3, 2023
Open
Open
@TextC0de TextC0de mentioned this issue Oct 7, 2024
Merged
TextC0de added a commit that referenced this issue Oct 15, 2024
@TextC0de
Implementación de sistema de transferencia de tickets (#286)
ab11309 
Este PR implementa la funcionalidad de regalo de tickets (relacionado a
#30, #31) y además incorpora optimizaciones de rendimiento propuestas en
el PR #273.

Se incluyen los siguientes cambios principales:

1. Nuevas tablas y relaciones:
- `user_ticket_gifts`: Almacena información sobre los regalos de
tickets.
   - Actualización de `user_tickets` con nuevos estados y relaciones.

2. Endpoints GraphQL:
- Mutación `giftMyTicketToUser`: Permite a un usuario regalar su ticket.
- Mutación `acceptGiftedTicket`: Permite al receptor aceptar un ticket
regalado.
- Query `myTicketGifts`: Obtiene los regalos de tickets enviados o
recibidos por el usuario actual.

3. Lógica de negocio:
- Implementación de validaciones para evitar auto-regalos y exceder
límites de tickets.
- Manejo de estados de regalo (pendiente, aceptado, rechazado,
cancelado, expirado).
   - Cálculo de fechas de expiración para regalos.

4. Servicio de correo electrónico (solo para 9punto5, luego hay que
extenderlo):
- Nuevas plantillas de correo para notificaciones de regalo de tickets.
- Implementación de métodos para enviar correos de confirmación de
regalo y aceptación.

5. Actualizaciones en flujos existentes:
- Modificación de `claimUserTicket` para manejar regalos de tickets
durante la compra.

6. Pruebas:
   - Nuevos tests para cubrir los escenarios de regalo de tickets.

## Optimizaciones de rendimiento (del PR #273):

Dado que estamos añadiendo más complejidad a la mutación `claim`, se han
incorporado las optimizaciones propuestas en el PR #273. Estas incluyen:

- Eliminación de verificaciones redundantes.
- Paralelización de operaciones usando `Promise.all`.
- Optimización de consultas a la base de datos, reemplazando múltiples
consultas individuales por consultas en lote más eficientes.

Estas optimizaciones, aunque no cruciales, son relevantes para mantener
el rendimiento de la mutación `claim` a medida que se añade nueva
funcionalidad.

Cualquier feedback o sugerencia para mejorar la implementación es
bienvenido.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Backend mutation Mutation Request
Projects
Devents
Status: No status
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Pillin @fforres