Members can now pay their eskaera at checkout, through the standard Odoo
payment machinery. Enabled per group order with a new `online_payment`
boolean, off by default: an order without it behaves exactly as before,
members save a draft and the cutoff cron confirms them in bulk.
The flow mirrors website_sale's: the checkout button becomes "Confirm and
pay", saving the cart redirects to a new /eskaera/<slug>/payment step that
renders `payment.form` from `sale`'s `_get_payment_values`, and the standard
/my/orders/<id>/transaction route takes it from there. This addon ships no
provider and configures none; the co-op publishes whichever it wants.
`website_sale`'s `_get_shop_payment_values` is deliberately not reused: it
runs `_get_shop_payment_errors`, which blocks on shippable products without a
delivery method — exactly an eskaera order, collected at the co-op with no
carrier. For the same reason the transaction route stays the portal one,
which does not call `_check_cart_is_ready_to_be_paid()`.
Payment confirms the order, which has three consequences handled here:
* `payment.transaction._check_amount_and_confirm_order` now confirms group
orders with `from_orderpoint=True`, the way the cutoff cron already does.
Without it a product with a broken replenishment route raises inside
`_post_process`, and `/payment/status/poll` rolls back and re-raises: the
member sees a payment error over a `done` transaction and the retry cron
fails forever.
* `_confirm_linked_sale_orders` also sweeps the cycle's already confirmed
orders into the picking batch, scoped by `pickup_date`. Its early return on
"no drafts" ran before any batching, so a fully prepaid cycle produced no
batch at all. `_cron_batch_paid_orders_of_closed_cycles` covers the same
hole for cycles closed by hand.
* A duplicate-order guard answers 409 on save-order, add-to-cart and
load-draft, and shows a notice on the shop, so a member whose order is
already placed cannot build and pay for a second one.
The payment policy lives in the model rather than the controller: there are
three sale.order creation paths and two are live, so `_compute_require_payment`
and `_compute_prepayment_percent` are extended instead of patching five vals
dicts. Orders are also created under the group order's company, which is what
filters the payment providers.
Along the way: eskaera drafts were invisible in /my/orders. The portal rule is
`message_partner_ids child_of` and sale.order only subscribes the customer on
send or confirm, never on a draft create, so the `_prepare_orders_domain`
override that includes drafts never had any effect. Fixed with an explicit
`message_subscribe`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- group.order.home_delivery is a stored compute field with no inverse;
Odoo still lets write() set it directly, so a stray direct write stuck
instead of always being re-derived from delivery_product_id. create()
and write() now strip it from vals, same pattern already used for slug.
- _find_recent_draft_order only bounded drafts by create_date, so a
freshly created draft for a stale/previous pickup_date (but created
"now") was wrongly reused. Fix requires both create_date to fall in
the active window AND pickup_date to match when set — the latter
alone isn't enough either, per the regression already covered by
test_find_recent_draft_excludes_previous_cycle (observed in
production at stage.elikabilbo.eus).
One-time, biweekly and monthly group orders now follow the same cron
confirmation flow as weekly ones (confirm sale orders + batch pickings
when the cycle cutoff passes):
- Biweekly/monthly keep the cutoff_day/pickup_day weekday scheme on a
recurrence grid anchored at start_date (creation date as fallback):
cutoffs advance +14 days / +1 month snapped to cutoff_day, with
catch-up after cron downtime. Previously they behaved as weekly.
- One-time orders (specials/promotions) are driven by end_date
(cutoff_date = end_date); once passed, the cron confirms, batches
and closes the group order.
- end_date keeps its "empty = permanent" meaning for recurring orders.
- Website draft-cart lookup window is now period-aware instead of
assuming a 6-day weekly cycle.
- New cron tests for once/biweekly/monthly cycles; i18n es/eu updated.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The /eskaera/load-draft endpoint was returning previous-cycle drafts when
group_order.cutoff_date was still in the future but group_order.pickup_date
had not yet been recomputed (its compute only depends on pickup_day and
start_date). Both the stale group_order.pickup_date and the old draft's
pickup_date held the same past value, so the exact-pickup-date filter in
_find_recent_draft_order matched the stale draft and the cart was
repopulated with old products immediately after being cleared.
Replace the pickup_date exact-match + current-week fallback with a single
cutoff-anchored window: create_date in [cutoff_date - 6 days, cutoff_date].
Drafts created outside that window belong to a previous cycle and must
not be reused. The change applies to all four callers (load-draft,
clear-cart, save-order, confirm) so the merge/confirm paths also stop
attaching to stale drafts.
Covered by a new regression test that mirrors the production setup
(matching pickup_date, draft create_date backdated 10 days).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
