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>
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 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>
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>
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.
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>
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>
Eskaera shop cards now display the standard website_sale ribbon
(variant_ribbon_id or website_ribbon_id, e.g. "Novedad") in addition
to the dynamic stock ribbon. Stock ribbons move to the right so they
coexist with user-defined ribbons (which default to the left).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Replace old pickup_day/pickup_date display with the slot-based logic
(pickup_slot_ids) on the checkout page, consistent with the shop page.
Falls back to legacy pickup_day if no slots are configured.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add hardcoded fallback translations for es/eu when PO-based translation
returns the source string unchanged. Expand labels dict with all keys
needed by the frontend. Fix JSON response parsing in template
(data.result || data). Add js_translations keys. Add pot file for
stock_picking_batch_custom.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The checkout home-delivery checkbox had a fixed checked="checked"
attribute, so it always rendered checked even when the delivery
product was not in the cart. Remove it and let checkDeliveryInCart()
mark it only when the delivery product is actually present.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three bugs prevented home_delivery from reaching sale.order:
1. #home-delivery-btn (shop sidebar) had no JS handler — clicking it did
nothing. Now it toggles active state and persists choice to sessionStorage.
2. _executeSaveCartAsDraft (Save Cart button) never included is_delivery in
the request body. Now reads the toggle button state (or the page-level
data-home-delivery-enabled fallback) and sends is_delivery correctly.
3. #home-delivery-checkbox on checkout page was unchecked by default and
always shown. Now it is pre-checked when group_order.home_delivery is
True, wrapped in t-if to hide it when delivery is not configured, and
synced bidirectionally with sessionStorage so the shop-page toggle state
carries over to checkout.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Make group.order.home_delivery a computed stored field that is True
whenever delivery_product_id is set, eliminating the manual checkbox
that could be forgotten. This fixes sale.order.home_delivery not being
set when the delivery product was configured but the boolean was left
unchecked.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Antes: si el slot tenía label, solo se mostraba el label (sin día ni hora).
Ahora: siempre se muestra día + rango horario (09:00–13:00), con el label
entre paréntesis como información adicional opcional.
Aplicado en eskaera_order_card_meta (tarjeta compacta) y en la vista
detalle de la tienda (group_order.pickup_slot_ids).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
El operador | en expresiones t-if de QWeb es el OR bitwise de Python,
no un filtro Jinja2. Como 'length' no existe en el contexto QWeb, evaluaba
recordset | None y lanzaba TypeError. Simplificado a solo pickup_slot_ids
(recordset vacío ya es falsy en Python).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Añadir reglas de acceso para group.order.slot en ir.model.access.csv
- Añadir pestaña "Pickup Slots" en el formulario de group.order con lista
editable (handle de secuencia, día, etiqueta, hora inicio/fin, activo)
- Corregir valores del campo weekday: de dígitos numéricos a nombres de día
(Monday...Sunday) para mejor usabilidad
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add sequence field (default 10) to product.category with _order = "sequence, name"
- Inherit product.category tree view to add drag-handle widget
- Sort category hierarchy and available categories by sequence in controller
- Migration 18.0.1.9.0: add sequence column to product_category table
- Bump version to 18.0.1.9.0
- Backend: Agregar método _validate_items_for_group_order() para validar que los productos históricos sigan siendo disponibles en la orden de grupo actual
- Backend: Modificar load_order_from_history() para filtrar solo items disponibles antes de pasar al template
- Backend: Generar mensaje de aviso traducido cuando hay productos no disponibles
- Template: Pasar información de productos no disponibles y warnings al JavaScript
- Frontend: Mostrar notificación de advertencia si hubo productos excluidos durante la carga histórica
- Notas: Esto evita cargar productos que ya no existen en la orden actual debido a cambios en categorías, proveedores o listas negras
Añade botón 'Clear Cart' (fa-trash) en el header y footer del sidebar
del carrito en la página de lista de productos.
Cambios:
- views/website_templates.xml: botón clear-cart-btn en card-header y
clear-cart-btn-footer en card-footer del sidebar
- controllers/website_sale.py: nuevo endpoint POST /eskaera/clear-cart
que cancela el sale.order borrador del usuario si existe
- static/src/js/website_sale.js: método _clearCart(), listeners para
ambos botones (header + footer)
- models/js_translations.py: nuevas cadenas clear_cart, clear_cart_confirm,
cart_cleared, draft_cancelled
- i18n/es.po, i18n/eu.po: traducciones ES y EU de los nuevos labels
- Create eskaera_order_card_meta template for cleaner code
- Simplify layout: horizontal meta-grid instead of table
- Fix t-if conditions on container elements
- Show only relevant fields: cutoff, pickup, delivery
- Add meta-grid CSS styles for compact horizontal display
- Home delivery badge only shown when enabled
- Add consumer_group_id to sale.order for tracking the consumer group
- Fix stock.picking consumer_group_id to use sale_id.consumer_group_id
- Add group_ids inverse relation in res.partner for bidirectional access
- Remove auto-calculation of consumer_group_id, data comes directly from group_order.group_ids[0]
- Add debug logging for consumer_group propagation
- commitment_date propagates directly from group_order (no recalculation)
- Añadidos ribbons 'Sin Stock' (rojo) y 'Pocas Existencias' (amarillo)
- Nuevo campo configurable: umbral de stock bajo (default: 5.0)
- Campos computed en product.product:
* is_out_of_stock: True cuando qty_available <= 0
* is_low_stock: True cuando 0 < qty_available <= threshold
* dynamic_ribbon_id: ribbon automático según nivel de stock
- Ordenamiento mejorado: productos con stock primero, sin stock al final
- Template actualizado:
* Muestra ribbon de stock en tarjeta de producto
* Deshabilita botón add-to-cart cuando producto sin stock
* Cambia icono a 'fa-ban' en productos sin stock
- Vista de configuración: campo 'Low Stock Threshold' en Settings > Shop Performance
- Solo aplica a productos type='consu' (almacenables)
- Tests: 112 pasados, 0 fallos
- Replace dependency from product_origin to product_origin_char
- Update product card template to show origin_text field instead of country_id/state_id
- Simpler and more flexible: free text origin per supplier instead of structured fields
- Version: 18.0.1.6.0 -> 18.0.1.7.0
The new field is more suitable for creative product origins like 'Valencia, Huerta de...'
or 'Región de Murcia, cooperativa XX' which don't fit the rigid country/state structure.
- Add comprehensive test suite for excluded_category_ids
- 9 tests covering: single category, recursive subcategories,
parent exclusion, direct product override, unrelated categories,
empty blacklist, multiple exclusions, combined blacklists,
available_products_count validation
- Update UI to show excluded_category_ids in 'Productos Excluidos'
- Bump version to 18.0.1.6.0
- Update CHANGELOG with category blacklist documentation
Technical notes:
- Category blacklist was already implemented in model/logic
- This commit adds missing tests and documentation
- Recursive exclusion via get_all_excluded_descendants()
- Blacklist has absolute priority over all inclusion sources
- Add excluded_supplier_ids field for supplier exclusion
- Filter products by main_seller_id (from product_main_seller addon)
- Blacklist has absolute priority over all inclusion sources
- Products with blacklisted main supplier never appear in orders
- Update _get_products_for_group_order() with supplier blacklist logic
- Add excluded_supplier_ids to 'Productos Excluidos' section in form view
- Add comprehensive test suite (TestSupplierBlacklist class with 9 tests):
* Test exclusion by main_seller_id
* Test multiple supplier exclusion
* Test products without main seller not affected
* Test blacklist with direct product inclusion
* Test blacklist priority over supplier inclusion
* Test combined product and supplier blacklist
* Test available_products_count with supplier blacklist
- Add Spanish and Euskera translations
- Update available_products_count computation to include excluded_supplier_ids
- Version bump to 18.0.1.5.0
Use case: Exclude all products from specific supplier (e.g., temporary unavailability)
Example: Category with 100 products, exclude supplier X → all products from X excluded
Workflow: Bulk inclusion via categories + supplier-level exclusion + product-level exclusion
- Add excluded_product_ids field for explicit product exclusion
- Blacklist has absolute priority over all inclusion sources (product_ids, category_ids, supplier_ids)
- Update _get_products_for_group_order() with blacklist filter logic
- Rename 'Associations' section to 'Catálogo de Productos' with subsections:
* Productos Incluidos (whitelist: suppliers, categories, direct products)
* Productos Excluidos (blacklist: explicit exclusions)
- Add comprehensive test suite (TestProductBlacklist class with 7 tests)
- Add Spanish and Euskera translations
- Update available_products_count computation to include excluded_product_ids
- Version bump to 18.0.1.4.0
Use case: Bulk inclusion via categories/suppliers + fine-grained exclusion via blacklist
Example: Select a category with 100 products, exclude 5 unwanted → 95 available
- Add sequence field to group.order model with default value 10
- Update _order to sort by sequence first, then start_date desc
- Add sequence field to tree view with handle widget for drag-and-drop reordering
- Add sequence field to form view for manual editing
- Orders in website list will now be ordered by sequence field
Portal users cannot read uom.uom model due to ACL restrictions (1,0,0,0 permissions).
This caused products sold by weight (kg) to have incorrect quantity step (1 instead of 0.1).
Solution:
- Calculate quantity_step in Python controller using product.uom_id.sudo()
- Check if UoM category contains 'weight' or 'kg' -> use step=0.1
- For other products, use default step=1
- Pass quantity_step to template via product_display_info dict
- Update XML input attributes (value, min, step) to use dynamic quantity_step
This maintains proper UX for bulk products while respecting security permissions.
