payutc / onyx Goto Github PK

Dans la PR #17, il y'a de nombreuses variables qui sont fixés en dur.
Url du CAS et URL de Ginger (+clef de ginger)

Il est important de déplacer ces variables dans la config.

L'envoi des mails est géré par une file d'attente lancé par un cron.

Il faut faire une page de wiki (ou ajouter ça au README) pour expliquer comment mettre en place le cron.

Un cron doit appeler une méthode qui pour chaque billet "non payé" (=> Dans un panier), va vérifier si l'utilisateur est encore sur le site (session ?), si l'utilisateur n'est plus sur le site, et que l'utilisateur n'a pas essayé de la payer (pas d'id payutc) alors on supprimes le billet.
Si il y'a un id payutc, on vérifie du coté de payutc s'il a été payé ou non, si non on le supprimes, si oui on le valide (=> Génération d'un code barre + génération du pdf de la place + envoie par mail).

Lorsque l'on crée un utilisateur, il faut lui envoyer son mot de passe par mail.
(Et bien s'assurer que c'est un mot de passe généré)

De cette manière ça permet de vérifier que l'adresse mail lui appartient bien.

Dans le cas ou les billets sont vendus "physiquement" ou via l'interface d'administration, il est important de savoir qui à réalisé la vente (qui était authentifié sur l'interface).

Pour des raisons de traçabilités, surtout si un jour on ajoute un module permettant de vendre des places "physiquement".

Il faut pour un user, dire quels sont ces groupes.

Il faut bloquer l'accès à l'administration de la partie "utilisateurs" et "gestion des groupes" si l'utilisateur n'a pas le droit ROLE_SUPER_ADMIN

Le fichier est au nom de symfony avec une licence MIT, faudrais adapter ça au projet onyx ;)

Sur la page inscription, il faudrait mettre l'email en premier (réordonner les champs)

Pour un event donné il faut :

• Le bandeau "header" (ou un bandeau par défaut)
• L'image de description
• Le texte descriptif + le titre + les dates clairement
• Une sous zone, avec "mes places" (ou si je ne suis pas connecté, un bouton m'invitant à me connecter pour voir mes places achetés + les tarifs spéciaux)
• Une sous zone avec les différents tarifs dispo, et un bouton "Réserver"

Lorsqu'un utilisateur est crée via une authentification CAS. On lui crée un mot de passe "de secours".

Actuellement ce mot de passe est tout simplement son login, on ne peut pas mettre en production tant que c'est comme ça.

On risque potentiellement de se prendre un problème d'UI de taille du listing dans le Back-Office, à partir du moment où on commencera à avoir pas mal d'évènements, de tarifs ou d'utilisateurs... Mais surtout de tickets : ça peut être super pratique pour une vérifier instantanément si un mec à bien un ticket ou non sans avoir besoin de ses identifiants !
Je voudrais tenter une petite solution qui n'a pas l'air trop complexe :

Datagrid est un plugin bootstrap de Fuel UX permettant de trier et paginer un tableau, et ajoute un moteur de recherche.
Il nécessite un petit export JSON des données.

dailyJs : Charger une dataSource asynchrone

Lorsque le panier (billet non payés pour l'utilisateur courant) n'est pas vide. On affiche a différent endroits stratégiques des boutons pour accéder au paiement des billets.

Ce bouton mène à une page qui affiche le résumé des places qui vont être payés. (Possibilité d'en annuler certaines et dernière chance de changer un nom).

Un bouton en bas de page, dont le lien sera donné par payutc permet d’accéder au paiement (controlleur qui effectuera quelques actions de communication avec payutc puis effectuera un "redirect")

Sur la page d'accueil je veux voir la liste des events à venir.

Au retour de l'inscription, une "popup" verte souhaite nous indiquer la réussite de l'opération, mais le texte est array ...

Il faut régler ce bug.

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).

Quand on a un utilisateur de l'UTC, il faut qu'on stocke son login.

L'utilisateur doit valider son adresse mail en cliquant sur un lien reçu par mail.

Car l'adresse mail permet d'identifier l'école de provenance et parfois de distinguer certains groupes d'utilisateurs et donc de tarifs.

De plus les billets seront envoyés par mail, il faut donc que l'ont vérifie que l'utilisateur reçoive bien nos mails.

Pour l'interface d'Admin l'authentification est très proche de celle utilisé pour l'interface "user" qui utilise le CAS.

Sauf que dans ce cas la, c'est à payutc de valider le ticket CAS, vu que l'on doit s'authentifier au passage auprès du CAS, qui permet de nous donner les droits de l'user (sur les fundations (= assos))