Cash payment not working again

[Paul-Eraman-CoopCycle]

Describe the bug Clicking on the cash payment option and then clicking on "pay" refreshes the page but does not create an order.

To Reproduce Steps to reproduce the behavior:

1. Go to https://libelubike.coopcycle.org/es/forms/KMyGYdaO96XN
2. Fill out formula, click next
3. cllick on the cash payment icon, then pay
4. See refresh without order creation

Expected behavior an order should be created

Screenshots

[lucasferraro]

Can not reproduce the bug. Orders FP and FO created using CASH as payment method.

https://github.com/coopcycle/coopcycle-web/assets/4819244/2211d2ae-70df-42a9-b213-5c0aeaad32e7

[Paul-Eraman-CoopCycle]

We tried it with brave and it worked, but now it doesnt again :/

https://github.com/coopcycle/coopcycle-web/assets/77277854/23fe6332-7f7e-4154-97bf-cb1949fcce70

[alexsegura]

I am able to reproduce it, and the form is invalid because of the following error:

The delivery date is expired

So it's not linked to the payment method, but with validation of the timeslot. This explains why it works "sometimes". As the timeslot is very large on Libelubike (9AM - 9PM), it happens a lot.

To reproduce it:

• Create a timeslot 4PM - 6PM
• Try ordering at 5PM

---

It has always been like this: if the slot has begun, it is considered invalid. Changing this would impact a lot of things (like what choices are shown to users in food deliveries)

https://github.com/coopcycle/coopcycle-web/blob/f9587f460500957f9e40dad3e63c85723192de32/src/Validator/Constraints/ShippingTimeRangeValidator.php#L57-L64

---

It happens in this form, but NOT on a delivery form using the same timeslot configuration, because the creation/validation of the order is not performed exactly the same way.

[lucasferraro]

Thanks Mex, nice catch of the reason.

So, maybe the first step is to handle this kind of validations and show the errors in the screen? https://github.com/coopcycle/coopcycle-web/blob/f9587f460500957f9e40dad3e63c85723192de32/src/Controller/EmbedController.php#L273-L320 Adding an else clause here and rendering same page

else {
    return $this->render('embed/delivery/summary.html.twig', [
        'hashid' => $hashid,
        'delivery' => $delivery,
        'price' => $price,
        'price_excluding_tax' => ($order->getTotal() - $order->getTaxTotal()),
        'form' => $paymentForm->createView(),
        'payment' => $order->getLastPayment(PaymentInterface::STATE_CART),
        'order' => $order,
        'submission_hashid' => $request->query->get('data'),
    ]);
}

Then, I don't know if we want to change the existing behaviour that is causing the error. At a first glance, I think it's a bit annoying cancel a delivery just because the timeslot has begun.

[Paul-Eraman-CoopCycle]

I have spoken to carmena, for the moment i believe we can make a workaround to make the platform viable while we figure out this problem

[Paul-Eraman-CoopCycle]

For the moment I have explained this to them, and now they are using 1 hour intervals. We should keep this in mind for when we re-attack pricing and time concepts on the platform for when we make the needs analysis

if we could make that an error instead of a random breaking issue, that would be a fix for the moment and I can close this issue

[lucasferraro]

With the current version of the platform I'm not able to reproduce this issue anymore, I don't know if anything has changed and fixed it.

BTW, making a test in my local env (timeslot 14:30 to 17:30 and creating a delivery at 16:20) with an old version of the code I was able to reproduce it to see if we can send the error (show error message) detected in the server when we check if the timeslot is valid:

https://github.com/coopcycle/coopcycle-web/assets/4819244/b0d6da68-a01a-49b5-8bb2-9ca12d38d875

The existing translation of the error may not be so clear for the user, but at least it shows an error message related to the error. @Paul-Eraman-CoopCycle Let me know if it's ok and I'll push the change.

But again, maybe something has been changed in the code and this error described above by mex has been fixed already.

[Paul-Eraman-CoopCycle]

I think mex's thing fixed it but it was hard to be sure (who knows if i tested enough things) so i think with the potential fix and an error message i think we can call it good to go, and see if i can break it again in live or not

[Paul-Eraman-CoopCycle]

[Paul-Eraman-CoopCycle]

We need to test its implementation in:

• [ ] shops
• [ ] formulas

[alexsegura]

The initial error about expired timeslot seems to have been fixed here

[alexsegura]

The error in this comment seems to be something else than the initial issue reported. The initial issue happened at the next step, when paying, and was showing no error message.

[Paul-Eraman-CoopCycle]

this link in your second to last comment doesnt lead me anywhere

[Paul-Eraman-CoopCycle]

honestly im also a bit confused about what is going on, maybe i needed to make a new issue but the current complaint is that comment you have linked to in your last message where you cant make an order inside of a time slot range

can we fix that?

[Paul-Eraman-CoopCycle]

was resolved doing something else! 🥳