BCard - Documentation technique

La quantité est ramenée à un minimum de 1 ; la police vaut Arial et le design classic par défaut. Si un fichier design_file est fourni, il subit trois contrôles successifs, chacun se soldant en cas d'échec par un message flash et un retour vers la fiche produit : validité de l'upload, taille inférieure au paramètre design_file_max_bytes, et type accepté (MIME image/png, image/jpeg, image/jpg, application/pdf ou extension png, jpg, jpeg, pdf). Le répertoire design_directory est créé s'il n'existe pas, puis le fichier est déposé via UploaderService::uploadFile() ; une FileException est journalisée et signalée à l'utilisateur. L'entrée est indexée par l'identifiant du produit, ce qui écrase toute personnalisation antérieure du même produit au lieu de cumuler les quantités.

Route : /panier/ajouter/{id} (POST), nom app_add_cart. Accès public.

Lit le panier en session en le remplaçant par un tableau vide s'il n'est pas un tableau, le normalise via PaymentController::normalizeCart(), réécrit la version normalisée en session (ce qui purge les anciennes entrées contenant des entités sérialisées), puis l'enrichit des entités Card avec PaymentController::hydrateCartForView().

Route : /panier (GET), nom app_cart. Accès public.

Reprend le paiement d'une commande en attente. L'identifiant de commande est lu dans le paramètre de requête order, avec repli sur checkout_order_id en session ; à défaut, ou si la commande est introuvable, l'utilisateur est renvoyé au panier. Le contrôle d'accès est identique à celui de PaymentController::showOrder(). Une commande déjà en Order::EN_TRAITEMENT redirige vers payment_success. Une commande en Order::EN_ATTENTE_PAIEMENT d'un utilisateur connecté est renvoyée vers PaymentController::resumeOrderPayment(), qui ouvre une nouvelle transaction Djomy ; toute autre commande est déclarée non reprenable. Aucune transaction n'est créée ici.

Route : /continue-to-paiement (toutes méthodes), nom app_continue_payment. Accès public sous réserve du contrôle de propriété.

Normalise et réenregistre le panier en session, puis le réhydrate. Les lignes de quantité nulle ou négative sont ignorées. Les options de couleur et d'impression ne sont prises en compte que si elles existent, sont actives et appartiennent bien au produit de la ligne : cette validation évite qu'une option d'un autre produit gonfle le prix. Le prix unitaire additionne le prix du produit et celui des options retenues ; le total et les montants sont arrondis à l'entier. L'illustration est la première image du produit, à défaut une image par défaut.

Route : /panier/mini (GET), nom app_cart_mini. Accès public.

Page d'annulation neutre (Djomy ne s'en sert pas : son retour passe par djomy_payment_return). Aucune donnée n'est modifiée : ni la commande ni le paiement ne changent de statut, et le panier est conservé pour permettre une nouvelle tentative. Un simple message flash d'erreur est ajouté.

Route : /payment-cancel (toutes méthodes), nom payment_cancel. Accès public.

Applique le même contrôle d'accès que PaymentController::showOrder() : propriétaire connecté ou identifiant de commande présent en session pour un invité. Une commande déjà en Order::EN_TRAITEMENT voit son panier et son identifiant de session nettoyés (ce qui dépend de la session et reste donc ici) puis la page de confirmation est rendue. Pour un paiement en ligne, la commande n'est confirmée que par PaymentFulfillmentService (retour Djomy vérifié ou webhook) : tant qu'elle n'est pas EN_TRAITEMENT, cette page ne modifie rien et renvoie vers le détail de la commande. Seul le paiement à la livraison est encore finalisé ici, dans une transaction DBAL : la commande passe en Order::EN_TRAITEMENT, puis l'e-mail de confirmation est envoyé, suivi le cas échéant de l'e-mail d'accès du compte créé pour un invité ; un échec d'envoi est journalisé sans bloquer. Enfin le panier et checkout_order_id sont supprimés de la session.

Route : /payment-success/{order} (toutes méthodes), nom payment_success. Accès public sous réserve du contrôle de propriété.

It manages the checkout form, creates a new user if one does not exist, and delegates to the appropriate payment processing method based on user selection.

Traite l'intégralité du tunnel de commande. Le panier est normalisé puis réhydraté ; s'il est vide, l'utilisateur est renvoyé à l'accueil. Lorsqu'un utilisateur est connecté, le formulaire CheckoutType est prérempli avec son nom (découpé en prénom/nom sur le premier espace), son e-mail et son téléphone. À la soumission valide, l'e-mail, le prénom et le nom sont exigés, puis le total est recalculé côté serveur à partir des prix en base : une ligne sans produit valide ou de quantité nulle interrompt le processus. Les options de couleur et d'impression ne sont retenues que si elles sont actives et rattachées au produit. Si aucun utilisateur n'est connecté, un compte existant portant le même e-mail est réutilisé, sinon un compte ROLE_USER est créé avec un mot de passe aléatoire et un jeton de réinitialisation, les indicateurs checkout_new_user et checkout_new_user_email étant placés en session. Les OrderItem sont ensuite construits (le fichier de design prime sur le design textuel) et un Payment en PENDING_STATUS est rattaché à la commande. Seules les méthodes djomy et cash_on_delivery sont acceptées ; pour djomy, le téléphone du formulaire est utilisé comme numéro du payeur et validé avant toute écriture. La persistance a lieu dans une transaction DBAL explicite : cash_on_delivery valide la transaction, envoie l'e-mail de commande puis vide le panier, et djomy place la commande en attente de paiement, ouvre la transaction Djomy via DjomyCheckoutService::start() et redirige vers sa page de paiement ; le panier de session est vidé dès que la transaction est ouverte et la commande enregistrée, checkout_order_id étant conservé. Toute exception provoque un rollBack(), un message flash adapté (e-mail déjà utilisé, paiement indisponible, ou erreur générique, sans détail technique) et une journalisation ; un try/catch externe rattrape les erreurs restantes et redirige vers l'accueil.

Route : /paiement (toutes méthodes), nom procede_to_payment. Accès public (les invités sont pris en charge).

Supprime l'entrée dont la clé correspond à l'identifiant fourni, sans vérifier son existence : une clé inconnue n'a aucun effet et ne produit aucun message.

Route : /panier/supprimer/{id} (POST, GET), nom app_remove_cart. Accès public.

L'accès exige un utilisateur connecté propriétaire de la commande. Une commande déjà en Order::EN_TRAITEMENT redirige vers son détail, et toute commande dont le statut n'est pas Order::EN_ATTENTE_PAIEMENT est refusée. Un formulaire construit à la volée, protégé par un jeton CSRF propre à la commande, propose le paiement en ligne Djomy (choix par défaut, avec le téléphone du payeur prérempli) et le paiement à la livraison. Le montant est recalculé depuis le total de la commande via PaymentController::parseMoney() : s'il est nul ou négatif, la commande est directement confirmée en Order::EN_TRAITEMENT. Un paiement en attente existant est réutilisé, sinon un nouveau Payment est créé et rattaché. En paiement à la livraison, la méthode est enregistrée et l'utilisateur est renvoyé vers payment_success qui se charge de la suite (statut, e-mails) ; en paiement en ligne, le téléphone du payeur est validé, puis DjomyCheckoutService::start() ouvre une transaction Djomy (description « Commande BCard # ») et l'utilisateur y est redirigé. Un échec est journalisé et ramène sur cette même page avec un message générique.

Route : /paiement/reprendre/{order} (GET, POST), nom app_resume_order_payment. Utilisateur connecté et propriétaire de la commande.

Affiche le détail d'une commande. Contrairement à ce que suggère la description historique ci-dessus, aucune donnée n'est modifiée et le panier n'est pas vidé. Le contrôle d'accès est double : un utilisateur connecté doit être le propriétaire de la commande, tandis qu'un visiteur non authentifié n'y accède que si l'identifiant checkout_order_id conservé en session correspond à la commande demandée. Tout écart provoque un message flash d'erreur et un retour à l'accueil.

Route : /my-order/{order} (toutes méthodes), nom app_my_order_show. Accès public sous réserve du contrôle décrit ci-dessus.

Les nouvelles quantités sont lues dans le tableau de requête quantity, indexé par la clé de la ligne du panier. Les lignes absentes de ce tableau sont laissées inchangées, et chaque quantité est ramenée à un minimum de 1. Aucune suppression n'est effectuée : mettre 0 revient à mettre 1.

Route : /panier/mettre-a-jour (POST), nom app_update_cart. Accès public.