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.

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

Gestion d'un "panier" #44

Open
mattgu74 opened this issue Jan 20, 2014 · 6 comments
Open

Gestion d'un "panier" #44

mattgu74 opened this issue Jan 20, 2014 · 6 comments
Assignees

Comments

@mattgu74
Copy link
Member

Lorsqu'un utilisateur est sur le site, il prend des places.

Il faut que ces places soit mise dans un panier (qui décompte le nombre de place disponible pour l'event et pour le tarifs donné) => Création d'un billet

Lors de la création de ce billet, l'utilisateur doit pouvoir définir le nom à écrire sur le billet (si le billet est nominatif, et qu'il n'est pas réservé à la personne connecté au quel cas on reprend le nom de l'utilisateur).

@flo-sch
Copy link
Contributor

flo-sch commented Jan 20, 2014

C'était déjà prévu dans l'entité Ticket le nom à définir ?

Concernant le panier, il faut qu'il soit relié à un utilisateur (normal) et qu'il vérifie juste la conformité de chaque ticket par rapport à l'événement et à l'acheteur du coup ?

Mais est-ce que c'est le rôle du panier de gérer ça ou du contrôleur qui gère la réservation d'une place ?
Et auquel cas le panier servirait juste comme collection de Tickets en session en fait ?

@mattgu74
Copy link
Member Author

Oui dans l'entité Ticket il y'a des champs pour le nom/prénom du bénéficiaire du ticket.

Enfait pour mieux gérer le stock, je suis d'avis à créer un Ticket dés que quelqu'un commence la réservation d'une place. Le "panier" c'est juste un ensemble de méthode, permettant de trouver tout les tickets d'un utilisateur qui n'ont pas encore été payés (lancé la procédure de paiement).

@flo-sch
Copy link
Contributor

flo-sch commented Jan 20, 2014

Okay donc on créé stocke un Ticket en base même avant le paiement du coup ? Ou juste en session ?

@mattgu74
Copy link
Member Author

en base, pour gérer le stock (je te rappelle que pour chaque tarifs (et events) on ne peut pas vendre plus d'un certain nombre de place). Du coup il est impératif de vérifier si la somme des billets vendu (+ceux en panier) est bien inférieur au nombre disponible, Si ce n'est pas le cas, il faut indiquer "rupture de stock" ou un truc du genre.

@flo-sch
Copy link
Contributor

flo-sch commented Jan 20, 2014

Hummm ouaip ça à l'air un tout petit peu plus tendu vu comme ça, je vais faire un premier jet et on verra comment le faire évoluer !

@ghost ghost assigned flo-sch Jan 20, 2014
@flo-sch
Copy link
Contributor

flo-sch commented Jan 27, 2014

Yop Matthieu, j'ai une base de panier à priori fonctionnelle que je continue de tester ;
Par contre j'ai quelques problèmes notamment de données (relations) :

  • Je dois sélectionner et vérifier les tarifs disponibles pour un groupe d'utilisateurs (ce qui fonctionne), mais il n'y a pas (actuellement) de liaison entre User et UserGroup, qu'est-ce qui fait ce lien ? Comment les groupes sont attribués ?
    Est-ce une question de rôles ?
    En gros ma requête SQL/DQL est correcte sémantiquement parlant et en syntaxe, mais comme mon utilisateur n'appartient pour le moment à aucun UserGroup, je ne peux pas trop tester...
  • Comment doit-on gérer une sélection multiple ?
    Actuellement, on peut réserver une place pour un tarif en renseignant un prénom et un nom mais si l'utilisateur désire 10 places, est-ce qu'on va lui demander 10 fois le prénom et le nom ?
  • Au moment de la validation du panier, pour le moment ma série de vérifications propage potentiellement des exceptions (5/6 possibles suivant le cas) en cas d'erreur, du coup quel doit-être le comportement ?
    Permettre de payer les places dispos, ou bien demander à l'utilisateur lui-même de régler ce qui ne va pas avant de pouvoir payer ?
    Exemple, si le mec réserve 6 places d'un tarif qui ne lui autorise que 5 places maxi...
    Est-ce qu'on balance une erreur au moment du paiement ou bien même limite au moment où il veut prendre la place ? Et quel genre d'erreur ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants