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

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

Je vois des textes en dur.
Exemple ici :

-> Utiliser un système de traduction.

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

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)

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

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 ?

Il faut mettre en place des fixtures avec :

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

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

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.

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

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

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

Corriger les quelques typos qu'il reste 😉

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

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.

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

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

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.

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

Customiser les pages d'erreurs.

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

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]

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

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

• Menu
• Datepiker
• Bouton

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

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.

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

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.

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

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

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

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.

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

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

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

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.

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.

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

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)