The email template had "Carte de crédit" hardcoded regardless of the
actual payment method. The address blocks were also missing the
``address2`` and ``name`` fields.
- Add ``mode_paiement``, ``livraison_nom``, ``facturation_nom``,
``livraison_adresse2``, ``facturation_adresse2`` to
``ConfirmationCommande`` Mailable
- Migration to replace hardcoded payment label with
``{{mode_paiement}}`` and add ``address2`` fields in DB template
- Migration to add ``name`` fields before each address block
When an order has status 0 ("En attente") and payment type is check
or wire transfer, the customer-facing order list now displays
"En attente de règlement" instead of the generic "En attente".
Display a tailored confirmation message when the customer pays by
check or wire transfer, including a warning about the 30-day
cancellation policy. The payment type is passed as a query parameter
so the message survives page reloads.
- Add ``getOrderConfirmedByCheckContent()`` and
``getOrderConfirmedByWireContent()`` to ``Contents`` repository
- Flash ``payment_type`` through redirect query parameter
- Add migration inserting content rows (id 10, 11)
- Update confirmed view with green checkmark and warning icon
``getArticlesToSell()`` returned ``false`` when no articles matched,
causing ``collect(false)`` to produce ``[false]``. The view then
iterated over that single-element array and tried to access array
offsets on a boolean value.
The forcing is useless, we are forcing links through many other
ways. I need to test aspects of deployments on my laptop to mimic
production deployment without this hassle.