Eskaera carried its own pricing path: a `website_sale_aplicoop.pricelist_id`
setting resolved inside the Eskaera controllers, plus a local reimplementation
of the tax and discount maths. The pricelist part meant /shop and Eskaera could
quote different prices on the same website, and the maths part had drifted from
the original it was copied from.
Pricing is now the standard one. The setting is gone (a migration drops the
parameter, which would otherwise linger looking like live configuration) and
`_resolve_pricelist` is `request.website.pricelist_id`. Scoping a pricelist to
a website is already core's job through `product.pricelist.website_id`, so
running the plain shop on one website and the co-op on another needs no code
here.
Taxes are applied by `product.template._apply_taxes_to_price`, which fixes a
real defect: it calls `_get_tax_included_unit_price_from_price` first, and this
module did not. With a fiscal position remapping a tax-included tax, a product
at 121 (100 + 21%) was displayed at 121 instead of 110, because the price was
handed to the mapped tax as if it were already that tax's gross amount. The
helper is a no-op without a remapping, so ordinary pricing is untouched. It
also means the website's `show_line_subtotals_tax_selection` is respected
rather than overridden with a hardcoded tax-included display.
Listing a page now costs one `_compute_price_rule` call instead of one per
product, which matters on the lazy-loading path.
Two smaller things found on the way. `_get_product_price_rule` was being passed
`target_currency=`, which is not one of its arguments: it fell into **kwargs
and was ignored, so the conversion never happened. And `_compute_price_info`
resolved `product.product_variant_ids[0]`, but it receives variants, so a
multi-variant template was priced from its first variant rather than the one
asked for.
The delivery display price loses its hardcoded 5.74 fallback and reuses the
same helpers as everything else.
Kept local, because none of it is pricing: the /Kg and /L suffixes, the 0.1
quantity step for bulk goods, the base unit price and the supplier name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dead-code cleanup dropped 11 test files that were never wired into
tests/__init__.py. Reviewing what they covered turned up real holes, so the
worthwhile ones come back, rewritten against the current schema.
Blacklists were the serious gap: product, supplier and category exclusions
have absolute priority over product discovery and nothing exercised them.
The old file had two separate defects. Its supplier fixtures wrote
`main_seller_id` directly, but product_main_seller computes that field from
`variant_seller_ids`, so the compute reset it to False and the blacklist had
nothing to exclude; they now create real supplierinfo records. Worse, four
whole classes asserted against `group_order.product_ids` -- the m2m *input* --
instead of the discovery result, so they set `category_ids` and then checked a
field they never touched. Those go through `_get_products_for_group_order`
now, and three tests that had no assertions at all got some.
The remaining three failures were test bugs too, all Odoo 17->18 leftovers:
* Date cases assumed `pickup_date` derives from `start_date`. The chain is
cutoff -> pickup -> delivery, and a recurring order whose start date has
passed rolls forward to the current cycle, so a 2024 order has no 2024
pickup. The new file anchors on future dates and finds the next 29 February
dynamically, with a class documenting the roll-forward itself.
* `/eskaera/labels` is `type="json"`; the old test hit it with a plain GET and
read the resulting 400 as a bug. It is called over JSON-RPC now, and a test
pins the 400 so nobody repeats it. Also `uom.uom.categ` -> `uom.category`.
* `price_include` is computed in 18.0, so fixtures must set
`price_include_override`. On top of that `_get_price` filters taxes by
company and defaults to `env.company`, not the fixture's, which left the
tax list empty -- `tax_included` was False for the wrong reason.
Two of the portal tests were passing for the wrong reason as well: the access
guard bounced them to /eskaera, which also answers 200. Membership has to be
set from the member side with `is_group`, and a new test checks the final URL
rather than the status alone. Each fixture that can silently build the wrong
thing now carries a guard test.
Left out on purpose: three files were unimplemented placeholders, and
test_draft_persistence still deserves recovering (see the notes file).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The OCA sources living outside this repo were mounted from a hardcoded
/media/snt/data/odoo in a local, untracked docker-compose.override.yml.
The host root now comes from ODOO_SRC in .env (gitignored, .env.example
added), so the mounts can live in docker-compose.yml itself and be shared.
Also parameterized: the published ports (ODOO_HTTP_PORT /
ODOO_LONGPOLLING_PORT) and the in-container addons path
(ODOO_ADDONS_PATH), the latter being the single source of truth for the
`command` and for manual `docker-compose run odoo odoo ...` invocations.
Missing variables fail with an explicit message instead of mounting empty
paths. `docker-compose config` resolves exactly as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Duplicate _translate_labels fallback, unreachable /eskaera/add-to-cart and
/eskaera/save-cart routes (the frontend cart is localStorage-only and uses
save-order), redundant pickup wrappers, unused pagination/count helpers and
fields, deprecated JS shims, and the already-empty checkout_summary.js and
i18n key/init leftovers.
Also drops 11 tests/*.py never wired into tests/__init__.py: three were
unimplemented placeholders (setUp with no assertions), and the other eight
had real assertions but were bit-rotted against the current schema (e.g.
res.partner.is_supplier no longer exists) — wiring them in surfaced 43
failures unrelated to this cleanup. Verified 0 failed/0 errors of 270 tests
both before and after.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
The tags row was reserved (empty, aria-hidden) on every product card so
prices stay aligned across a grid row regardless of which cards have tags.
But when no product in the current batch has a published tag, that row was
still a fixed, permanent gap on every card for a feature nobody was using.
any_product_has_tags is now computed once per batch (controller-side, per
CLAUDE.md's no-logic-in-QWeb rule) from the already-filtered published_tags,
and the template skips the row entirely when it's False across all three
render paths (initial page, load-more, infinite-scroll AJAX).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Quantity control layout: changed from wrapping flex to deliberate two-row
grid so the add-to-cart button sits full-width underneath the stepper,
avoiding accidental line breaks and giving the primary action more pulsing
area. Also removed the /Kg suffix's redundant font rules.
Order card delivery row: reordered to badge-then-date (visually centred),
removed the "Delivery" label, and swapped bg-primary to text-bg-primary for
proper contrast on the home-delivery badge (3.13:1 minimum).
Tooltip translations: moved hardcoded static tooltips from data-bs-title
(untranslatable) to title (QWeb-translatable). Handled the edge case of
"Save Cart" and "Back to Cart" which had translations but no model_terms
reference in the POT, causing the merge to discard them — added the view
reference so translations now apply.
Load-from-history page: added accessibility: a visible status message
("Loading your order…"), a <noscript> fallback with link to the group
order, lang and viewport meta tags, and localised strings for all three
languages. Gave the page a minimal inline style block since it does not
inherit the token system (no website.layout).
Translations: 11 new entries (es/eu/ca) for new/reworded UI strings, plus
two code catalogue entries (products found, Close) that needed the
#. odoo-python comment for _() resolution. Documented the silent-failure
pattern in docs/TRANSLATIONS.md: the POT merge, untranslatable attributes,
and missing code comments.
Tests: 246 passing. Pre-commit: clean.
Co-Authored-By: Claude Haiku 4.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).
Add ca.po for both addons, matching the existing es/eu coverage
(378 and 4 entries respectively). Add the missing "ca" fallback block
in website_sale_i18n.py alongside the existing es/eu ones, and correct
the i18n README, which falsely claimed complete pt/gl/fr/it coverage
that was never actually present.
- create(): slugs were only checked against the database, so records created
in the same batch (duplicating several orders from the list view, importing
rows sharing a name) collided on group_order_slug_uniq. _generate_unique_slug
now also skips the slugs already handed out in the batch.
- _redirect_to_slug_url(): `post` is passed as a dict instead of splatted, so a
query parameter named `suffix` no longer binds to the keyword argument of the
same name (HTTP 500 on /eskaera/<id>/checkout?suffix=x, and a corrupted path
on the shop route).
- post-migrate: the backfill runs with tracking_disable, `slug` is tracked and
the upgrade posted a chatter message on every pre-existing order.
Tests for the two reachable cases: batch create and query parameters kept
across the legacy redirect.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Group order pages were published under their database id (`/eskaera/1`), which
says nothing to the member opening the link. `group.order` gains a `slug` field
and the public pages move to `/eskaera/<slug>` (e.g. `/eskaera/escola-fructuos`).
The slug is generated from the order name on creation, is unique, and can be
edited under the name on the form; emptying it regenerates it from the current
name. Values that would make the order unreachable are rejected: a plain number
(the legacy numeric URLs win that match) and the static routes served under
`/eskaera/` (`labels`, `save-order`, `i18n`, ...).
`/eskaera/<id>` and `/eskaera/<id>/checkout` are kept as redirects to their slug
URL, so the links already shared with members keep working. The AJAX endpoints
(`load-page`, `save-order`, `confirm`, ...) stay numeric: they never show up in
the address bar. Consequently the frontend now reads the order id from the
`data-order-id` attribute only, as the URL no longer carries it.
The post-migration script fills the slug of the orders that already existed.
Renaming the `/eskaera` prefix itself (`/escolas` for a schools deployment)
needs no code: a *308 Redirect / Rewrite* rule per public route in Website >
Configuration > Redirects serves the pages on the new prefix, rewrites the
links in the templates and redirects the old URLs, per website. Documented in
`readme/CONFIGURE.rst`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Joins `.claude/`, `.vscode/` and `.github` in the .gitignore. The file stays on
disk, only out of version control, so its contents (including the path to the
OCB and OCA sources) are now local to each machine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The 18.0 migration of `pos_payment_method_cashdro` (OCA/pos@6a4c251d) kept
three uses of APIs removed in 18.0. The module has no tests nor tours and needs
a physical drawer to be exercised, so the OCA CI can't catch them:
* `_cashdro_url()` reads `order.selected_paymentline`, so `.payment_method` on
the resulting `undefined` throws a TypeError on every payment, swallowed into
a generic "An error occurred while connecting to the cashdro" dialog.
* The `add_paymentline()` patch checks `line.payment_method`, renamed to
`payment_method_id`, so the line keeps the default due amount instead of
waiting for the amount the customer inserts.
* `_loader_params_pos_payment_method()` is the 17.0 loading API, replaced by
`_load_pos_data_fields()`. Dead code, so the CashDro credentials never reach
the front end.
Patched from the outside, as OCA sources are not to be modified. Written to
stay harmless once fixed upstream: the Python override only adds the missing
fields and the JS patches are idempotent against the fixed code.
`upstream/pos_payment_method_cashdro-18.0-fixes.patch` holds the same fixes as
a ready to send `git format-patch`, verified with `git apply --check`. This
module is temporary and should be removed once that lands in OCA/pos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrated from the 17.0 branch (4fbf328). APIs that no longer exist in 18.0:
* `order.selected_paymentline` -> `order.get_selected_paymentline()`
* `ErrorPopup` + `env.services.popup` -> `AlertDialog` + `env.services.dialog`
* `/** @odoo-module */`, implicit in `.esm.js` since 17.0
The rounding itself needed a different approach: `get_rounding_applied()` now
reads `taxTotals.order_rounding`, only computed over payments that are already
`is_done()`. The CashDro line is still `waiting` when the amount is requested,
so a literal port would always have added 0. `getDefaultAmountDueToPayIn()` is
the 18.0 equivalent: it applies `getRoundedRemaining()` honouring both
`cash_rounding` and `only_round_cash_method`, and is what core itself uses for
the default amount of a payment line.
Only `_cashdro_payment_url()` is patched now, instead of duplicating the whole
`cashdro_send_payment_request()`, so the request flow, the acknowledge, the
polling and the error handling stay in the base module. With no cash rounding
configured the patch delegates to `super` and changes nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The "shop as a read-only catalog" behaviour lived inside website_sale_aplicoop,
so every site that wanted the eskaera flow also lost the standard cart. It now
ships as its own installable addon, with the redirect target configurable
instead of hardcoded to /eskaera.
- website_sale_disable_cart: hides the cart UI (12 header styles + the product
card quick-add) and overrides the standard cart endpoints. Redirect URL is
configurable in Website settings (default /shop); only site-internal paths are
accepted, so a misconfigured value cannot turn the shop into an open redirect
nor loop back into a disabled route.
- Fixes carried over from the original code: /shop/cart/quantity is the Odoo 18
path (it was /shop/cart_quantity, which never matched), the boxed, sidebar and
sales two/three/four headers were not covered (the cart link stayed visible on
them), and the routes now override the standard methods instead of registering
duplicate ones.
- website_sale_aplicoop 18.0.1.12.0: drops the view file and the four redirect
routes; installing it no longer touches the standard shop.
Upgrade order matters: update website_sale_aplicoop first, then install
website_sale_disable_cart in a second Odoo run — both use the same XPaths and
obsolete records are only cleaned up at the end of a run.
Tests: 8/8 in website_sale_disable_cart, aplicoop unaffected (its 2 failures
predate this change). Verified live on a DB clone: /shop/cart returns 303 to the
configured URL and no cart markup remains on /shop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TicketBAI maintains independent chains per invoice series (INV, RINV, etc).
When building the chain for a new invoice, ensure it links to the previous
valid document from the same series, not just the last document regardless
of series.
Fixes error "time data '' does not match format '%d-%m-%Y'" when previous
document's XML is missing or when wrong series document is used for chaining.
- Override _get_sale_values to validate series match
- Add _get_last_chained_document_by_series to filter by series+state+xml
- Skip cancelled documents and documents without valid XML
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
El precio por unidad de las tarjetas usaba el campo nativo base_unit_price
(list_price sin impuestos), mostrando un importe distinto al precio
principal de la tarjeta, que sí incluye IVA. Ahora se calcula a partir del
precio ya impositado. Además se extiende el sufijo de precio por unidad
("/L") a productos vendidos por litro, que ya tenían el step de 0.1 pero
no el indicador visual.
Allow removing stock.move.line records from the Basket Assembly operator
view (select + Delete action) instead of forcing quantity to zero, which
caused issues for operators. Also expose the picking reference field
(hidden by default) before the contact column.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Group orders are not confirmed until the cutoff date, so draft/sent
sale.order lines never generate stock.moves and are invisible to
virtual_available. This change makes the shop aware of that demand.
- group.order._compute_draft_sale_demand: queries sale.order.line in
draft/sent state (mirroring sale_stock forecasted report logic) and
returns pending demand per product.id in the product's own UoM.
- _get_products_for_group_order: delegates to new _apply_stock_filter_and_sort
which excludes storable products whose forecasted net qty
(virtual_available − draft demand) <= 0, unless allow_out_of_stock_order.
- _compute_stock_ribbons: reads draft_demand_by_product from ORM context
so is_out_of_stock / is_low_stock / dynamic_ribbon_id reflect net qty.
- Controller: new _prepare_draft_stock_data helper calculates demand once
per request, injects context, and builds product_max_qty dict. Applied
in eskaera_shop, load_eskaera_page and load_products_ajax.
- Template: qty input gets max and data-max-qty from product_max_qty.
- JS: blocks add-to-cart if requested quantity exceeds data-max-qty.
- Fixes type check: type=='consu' → is_storable=True (Odoo 18 semantics).
- 21 new tests in test_forecasted_stock.py covering demand calculation,
ribbon logic with context, and group order filtering.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add action_sync_purchase_price_from_supplierinfo on product.template:
iterates variants, applies discount chain from main supplierinfo
(according to last_purchase_price_compute_type), writes net price to
last_purchase_price_received, recomputes theoretical sale price.
Skips manual_update variants and products without a supplier.
Returns a display_notification with updated/skipped counts.
- Register it as ir.actions.server bound to product.template list view.
- Add test_sync_action.py: 10 tests covering all discount types, skip
cases, theoretical price recompute, notification type, idempotency,
and bulk multi-template execution.
- Fix test_no_update_with_zero_quantity: update assertion to reflect that
PO confirmation now syncs the cost via supplierinfo (intended behavior).
965c5c2 stored the cart as {cutoff_date, items: {...}} in
eskaera_<id>_cart. That broke every other reader of the same key:
- checkout_labels.js iterates Object.keys() expecting product IDs and
rendered "cutoff_date" / "items" as ghost rows → users on the
checkout page saw their cart as empty.
- home_delivery.js read/wrote the cart in place; the in-place mutation
destroyed the wrapper.
- _saveOrderDraft serialised the same object straight to the server,
POSTing "cutoff_date" and "items" as productIds.
Split the schema: eskaera_<id>_cart keeps the plain {productId: {...}}
shape every other JS file already relies on; the cycle marker moves to
eskaera_<id>_cart_cycle. _loadCart migrates browsers still holding the
v18.0.1.10.0 wrapped value on the next read.
Also make eviction strictly opt-in: drop the cart only when we know
the current cycle AND the stored cycle disagrees. Missing data on
either side (check-status didn't run, XHR failed) → preserve. This
restores the checkout page where check-status isn't called.
Version bump triggers the in-tab auto-reload added in 6e6d1e5 for
clients already on that build.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
When we ship a JS-only fix, users with a long-lived tab keep running
the old code until they hard-refresh — there is no clean way to push
new code to an already-loaded page. Now /eskaera/check-status returns
the module's installed_version as client_version, and the eskaera
page embeds the same version in data-build-version on the cart
container. The JS captures the page's build version at init; on every
check-status response it compares them and triggers window.location.
reload() on mismatch. A sessionStorage timestamp guards against
reload loops if the versions stay disagreeing (cached HTML upstream).
The version bump in __manifest__.py also invalidates the asset bundle
URL hash, so even users without this signalling path get fresh JS on
their next navigation.
This is forward-looking: clients on the old JS (no check) still need
one manual refresh today, but every future deploy will auto-recover.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The cart was reappearing on stage with ghost items that had never been
saved as drafts on the server. Root cause: the localStorage cart had no
cycle awareness. Users who added items but never clicked Save left the
items in localStorage forever, and the only existing eviction path
(_clearCurrentOrderCartSilently via _checkGroupOrderStatus) only fires
when cutoff_passed flips true — which it rarely does, because the
stored cutoff_date is normally in the future for an active cycle. On
the next visit, _loadCart happily rehydrated the stale items and
_autoLoadDraftOnInit short-circuited because the cart was no longer
empty.
Stamp every cart written to localStorage with the cutoff_date it
belongs to and reject on cycle mismatch in _loadCart. The cutoff_date
is captured from /eskaera/check-status (which already returned it).
Legacy unstamped values and corrupt JSON are also dropped, so existing
browsers self-heal on first reload after the deploy.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
