It's simpler if there is just one place to add a new product. Closes#6650
This removes the 'creating directly from the new product path' test scenario because we have another 'assigning important attributes' scenario above which provides enough coverage.
It's simpler if there is just one place to add a new product. Closes#6650
This removes the 'creating directly from the new product path' test scenario because we have another 'assigning important attributes' scenario above which provides enough coverage.
This makes it possible to deploy it without releasing it to users since
the toggle is not enabled for anyone.
It aims to make the balance calculation consistent across pages.
We only care about non-cart orders and skipping carts, saves PostgreSQL
query planner to go through thousands of records in production use cases
(my food hub).
We go from
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12049.45 rows=152002 width=15) (actual time=0.015..11.703 rows=13867 loops=1)
```
to
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12429.46 rows=10802 width=15) (actual time=0.025..17.705 rows=9954 loops=1)
```
It's simpler and many orders of magnitude more efficient to ask the DB
to aggregate the customer balance based on their orders. It removes
a nasty N+1.
The resulting SQL query is:
```sql
SELECT customers.*, SUM(spree_orders.total - spree_orders.payment_total) AS balance
FROM "customers"
INNER JOIN "spree_orders"
ON "spree_orders"."customer_id" = "customers"."id"
WHERE "customers"."enterprise_id" = 1
AND (completed_at IS NOT NULL)
AND (state != 'canceled')
GROUP BY customers.id
ORDER BY email;
```
I am not sure why this was passing without these stubbed requests for
the second order, but now they were correctly failing. This commit fixes
the spec.
For some reason the process is now working correctly, the authorization step succeeds and a redirect link is stored in the payment with state pending. The payment state is correctly left at pending. Here we add a check for the redirect path sent by stripe and fail the authorization if there is one (it means the payment would need an extra auth step only available in the frontoffice now and probably through email to customer at some point in the future). For some reason the flash with the authorization failure message is not showing up for the user
