senzowayne / resavo Goto Github PK

Il faut mettre en place des fixtures avec :

• Quelques utilisateurs
• Un Admin
• Des réservations
• Des salles
• Des séances

Cf: https://fr.reactjs.org/

J'ai remarqué que certaines commande du Makefile ne sont pas executer dans les containers Docker, par exemple celle-ci:

il sagit de la page expliquant le projet a nos prospect et proposant la démonstration du système de réservation

Revoir toutes les functions effectuées des refactorings si possible.
Deporter certaines fonctions en plusieurs fichier pour une meilleure lisibilité et scalabilité.

Note: ajout de constante pour les url dans un fichier deporté.

Après relecture beaucoup d’asserts (contrainte de validation) son manquant pour sécurisé nos Entity

Note : Ne pas hésiter à utilisé des regex

L'API sera chargé de gerer le backend, tandisque le frontend va se charger de l'experience utilisateur. Ça permet d'avoir un code beaucoup plus lisible et facilement maintenable.

Il devrait être possible pour un client de modifier sa reservation au moins 2 fois tant qu'il est bien 48h avant la réservation.

Je pense que ça pourrait être bien d'utiliser aussi des images Docker pour composer et node, afin d'avoir tout l'environnement dans docker.

Qu'en penses tu @senzowayne ?

Workflow permet la gestion du statue d'une réservation

Il serai intéressant d’utiliser cette outils pour gérer différent état d’une réservation

Cf: https://symfony.com/doc/4.4/components/workflow.html
Note: étudier les cas possible

On peut voir que dans l’idée d’une salle à réserver on bloque des séances par rapport à celle-ci. Donc une même séance pour 2 salles différentes sont indépendantes. Par contre admettons que je puisse proposer qu’une formule à la fois.

Exemple je suis coiffeur indépendant et peut importe la formule choisi je dois bloquer les séances par rapport à la journée uniquement. Car je ne peux pas gérer 2 ou plus à la fois.

C’est cette gestion qu’il faut mette en place par le biais d’un simple boolean depuis les paramètres du marchant ensuite si ce boolean est true, l’idée est de modifier la requête de vérification de disponibilité en ne se basant pas sur date / room / séance
Mais sur date / séance. Ce qui m’a l’air de bien gérer le cas voulu.

Salut! J'ai remarqué dans le Readme que y'a des identifiants Paypal à indiquer pour les paiements, mais j'vois rien pour lier à d'autres agendas style google agenda.

Côté Laravel j'sais qu'on a des packages pour faire le lien facilement avec l'API de google agenda. Mais j'suppose que côté Symfony doit déjà y avoir des trucs tout fait aussi.

Pour que nous puissions avancer tous dans des bonnes directions, je suggères que l'on fasse un debriefing du projet. Expliquer le but du projet, comment le réaliser, les différents acteurs, la conception(base de donnée + relation)

Mettre à jour le projet. Faut partir sur des bonnes bases et pas dev' sur une vieille version de PHP.

Pour une optimisation maximale, remplacer tout les links CDN par les fichiers nécessaire au bon fonctionnement de l'application

Corriger les quelques typos qu'il reste 😉

L'idée serai de pouvoir personnaliser sa config de façon dynamique, on y retrouverai les choix suivants :

• Paiement (ex : Paypal ou Stripe)
• Couleur du thème
• Nom de l'enseigne

[EN COUR DE REDACTION]

Ajouter dans twig.yaml
exception_controller: null

Changer la clef naming-strategy dans doctrine.yaml :
naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware

Bonus: Voir si ya pas d'autres dépréciations pour les updates à venir
Cf: https://afsy.fr/avent/2019/02-symfony4-vers-symfony5

Cf : https://symfony.com/doc/current/components/mailer.html

Bonne pratique de code :
De la même façon que tu veux séparer les contrôleurs des vues, tu voudras toujours séparer ton template de mail des données que tu lui donnes.
ça te permettra de réutiliser ton template.

D'ailleurs, utiliser un templater comme twig pour les mails, faut les traiter comme n'importe quelle autre vue.

Le code des formulaire est mal formaté, avec beaucoup d'ambiguité.

Cf: https://symfony.com/doc/current/web_link.html

• Menu
• Datepiker
• Bouton

Le choix des noms de variable pas forcement cohérent passant du français à l'anglais, bref pas top..
Passer toutes les propriétés + (getter/setter) en anglais.

L'idée est de plus affiché les séances non disponible pour optimisé le nombre de requêtes inutile.

Lors d'un docker-compose up, php effectue quelques tâches au démarrage pendant ce temps on obtient une 500 qui peut laisser penser que rien ne fonctionne.

Trouvez un moyen d'informer ou d'éviter l'erreur 500.

Même idée que pour google pouvoir s'authentifier via Apple

Cf : https://developer.apple.com/sign-in-with-apple/

L'idée est de pouvoir disable les dates voulu par l'admin

Dans le cadre d’un meilleur suivi de ce qui se passe sur l'application. (Exemple: si les réservations ce passe correctement ou pas, ou si les utilisateurs rencontrent des erreurs)

Il faudrai mettre en place des logs qui nous permettre de suivre une réservation depuis début le paiement jusqu’a l’envoi du mail de confirmation.

Bonus : il serai idéal de recevoir un mail en cas de log critique
Cf: https://www.remipoignon.fr/symfony-configuration-des-logs-monolog/
https://symfony.com/doc/current/logging.html

L'idée est de remplacer tout le code appelant les variables POST
en utilisant l'object request.

Cf: https://symfony.com/doc/current/components/http_foundation.html

L'idée est de pouvoir s'authentifier directement via un compte google :)

Cf : https://developers.google.com/identity/protocols/OAuth2
Cf: https://packagist.org/packages/hwi/oauth-bundle (ou voir autre solution)

L'idée c'est qu'un client connecté sur une résa disponible au moment de sont arrivé
soit mise a jour en temps réelle ci celle-ci n'est plus disponible.

• makefile with cmd [make start]
• docker
• utilisation de mercure

En vue de la séparation du coter back et front.

Customiser les pages d'erreurs.

Cf : https://symfony.com/doc/current/controller/error_pages.html

Actuellement ces fichiers sont situer dans le controller il serai plus judicieux de les deplacer dans un dossier destiné à paypal.

Actuellement nous nous basons sur des simples boolean pour verifier que tous se passe bien.
Mais il est dans ce cas pas possible de remonter un problème !
Il faudrai dans ce cas renvoyer une exception et pourquoi pas renvoyez une notification à l'utilisateur.

• Installer PHP Units si ce n’est pas déjà fait
• Créer des tests unitaires sur les fonctions de vérification du paiement & partout où nécessaire.

Ce qui nous permettra de toujours vérifier le bon comportement de nos fonctions.

A voir ce qu'impliquerait de faire les changements, mais je pense qu'il est nécessaire de le faire le plutôt possible.

Package braintree/braintreehttp is abandoned, you should avoid using it. No replacement was suggested.
Package zendframework/zend-eventmanager is abandoned, you should avoid using it. Use laminas/laminas-eventmanager instead.
Package zendframework/zend-code is abandoned, you should avoid using it. Use laminas/laminas-code instead.
Package twig/extensions is abandoned, you should avoid using it. No replacement was suggested

Je vois des textes en dur.
Exemple ici :

-> Utiliser un système de traduction.

Cf : https://symfony.com/doc/4.4/frontend.html