Branch
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260813 01
PR State:
merged
[FIX] pos_sale: assert every sale picking is cancelled, not a single one test_settle_order_with_multistep_delivery_receipt reads sale_order.picking_ids.state, assuming the order carries exactly one delivery picking. With the foreign-trade export flow installed, the NL test partner makes the order route its delivery through the customs zone, so two chain pickings exist by the time the POS settles the order — both correctly cancelled — and the singleton access raises "Expected singleton: stock.picking(588, 587)". Assert the actual intent of the test instead ("all the picking are cancelled", per its docstring): the order has pickings and every one of them is cancelled. Still passes on a bare community stack.
PR:
[FIX] pos_sale: assert every sale picking is cancelled, not a single one
PR State:
merged
[FIX] hr_holidays: freeze the date of the accrual-levels leave test test_hr_leave_after_adding_accrual_plan_levels (introduced upstream by 55f89ed97965) books a leave covering today + 2 to today + 3 without freezing time. On a Monday-to-Friday calendar any run on a Thursday makes that window fall entirely on the weekend, so the leave counts zero days and action_validate() raises "The following employees are not supposed to work during that period". A bare community checkout of the same commit fails identically, and upstream has not fixed it yet. Freeze the test on a Monday so the leave always lands on working days, the same way 34f6bbfbaf1c already did for another test of this file.
PR:
Merge from upstream 18 20260812 01
PR State:
merged
Merge remote-tracking branch 'odoo/18.0' into 18.0
PR:
Merge from upstream 18 20260812 01
PR State:
merged
Merge remote-tracking branch 'odoo/18.0' into 18.0
PR:
Merge from upstream 18 20260812 01
PR State:
merged
Merge remote-tracking branch 'odoo/18.0' into 18.0
PR:
Merge from upstream 18 20260808 01
PR State:
merged
[FIX] point_of_sale: adapt tour helper to integer quantity display Commit c63e34ff56fa backported the Odoo 19 behavior of displaying whole-number quantities without a decimal part, but the tour helper still compared the raw expected quantity string ('1.0'/'1.00') against the rendered '1', breaking every orderline check step across the POS test suites. Normalize the expected quantity the same way upstream does in 456a7428f8e3 (order_widget_util.js).
PR:
[FIX] point_of_sale: adapt tour helper to integer quantity display
PR State:
merged
[IMP] point_of_sale: hide decimals for integer quantities on receipts Quantities were always formatted with the global 'Product Unit of Measure' decimal precision, so a quantity of 1 was displayed as 1.000 (with a 3-digit precision) on the order screen and the printed receipt, even for countable units such as Units/Piece. Backport the Odoo 19 behavior: whole-number quantities are displayed without a decimal part, while fractional quantities (e.g. 1.5 kg) keep the standard precision-based formatting.
PR:
[IMP] point_of_sale: hide decimals for integer quantities on receipts
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260724 01
PR State:
merged
[FIX] account_edi_ubl_cii: skip predictive test when account_accountant feature is absent test_partial_import_product_invoice_predictive needs the Enterprise-only invoice-history predictor (account_accountant); on Viindoo's Community stack it is absent, so the predictive path no-ops and the test asserts a product_id it cannot resolve. Guard by the SAME condition production code uses (payment_state_before_switch field absence) rather than a module name, so it stays correct regardless of which account module is installed. Upstream 9365822e (18.0-only) removed the original ensure_installed('account_accountant') guard as collateral of an unrelated settings-toggle sweep; master still carries a guard. Kept minimal to limit divergence from odoo/odoo.
PR:
Merged from upstream 18 260722 01
PR State:
closed
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260722 01
PR State:
closed
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260716 01
PR State:
closed
[FIX] point_of_sale: add deterministic tiebreaker to limited product loading get_limited_products_loading ordered candidate products by is_favorite, service type, last stock move date and write_date, with no final tiebreaker. When products tie on all of those keys (e.g. non-favorite consumable products with no stock moves created in the same transaction, sharing an identical write_date = transaction_timestamp()), the LIMIT result fell back to PostgreSQL's unspecified physical scan order, making the loaded product set non-deterministic. It surfaced as an intermittent pos_loyalty test_product_loading failure on large installs. Add product_product.id as a final ascending tiebreaker so limited product loading is stable and reproducible.
PR:
[FIX] point_of_sale: add deterministic tiebreaker to limited product loading
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260812 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260722 01
PR State:
merged
[IMP] mail: improve the systray performance
PR:
[IMP] mail: improve the systray performance
PR State:
merged
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 2x
PR State:
closed
[FIX] stock: avoid O(n²) move-line scan when reserving serial products _update_reserved_quantity searches for an updatable move line per reserved quant via `next(l for l in self.move_line_ids if l._reservation_is_updatable(..))`. This scans the (growing) move_line_ids for every quant → O(n²) on a move of n serial units. But stock.move.line._reservation_is_updatable returns False unconditionally for tracking == 'serial', so the scan can never find a candidate and is pure waste.
PR:
[FIX] stock: avoid O(n²) move-line scan when reserving serial products
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260615 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260512 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260428 01
PR State:
merged
Merge branch '16.0' into 16_survey_translate
PR:
[16.0][I18N] survey: translate template certificate
PR State:
open
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260403 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260319 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260305 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260228 01
PR State:
merged
[I18N] purchase_stock: correct Vietnamese translation
PR:
[I18N] purchase_stock: correct Vietnamese translation
PR State:
to_merge
[FIX] test_base_automation: deflake custom reference field tour Switching the trigger from on_stage_set to on_tag_set swaps the relation of trg_field_ref through an onchange round-trip. The tour could open the autocomplete dropdown before that round-trip completed: it then listed the records of the previous model and never refreshed, because the (empty) field value did not change so the AutoComplete never closes it. The guard added by ca1c63e363ce does not help: its descendant :not() selector matches any child element and passes immediately. Retry the second dropdown assertion: close (Escape) and reopen the dropdown until the relation switch has landed, with a 10s cap. Reproduced deterministically by delaying _compute_trg_field_ref by 500ms; the reworked tour passes under the same delay.
PR:
[FIX] test_base_automation: deflake custom reference field tour
PR State:
merged
[FIX] point_of_sale: write the country id, not the record, in tests common TestPoSCommon.setUpClass writes the company country as a res.country record instead of its id. The ORM tolerates it, but every res.company write override that inspects vals['country_id'] then receives a record where any other caller passes an id or False. An override comparing that value against an id trips the reflected BaseModel.__eq__, which emits an "unsupported operand type(s)" py.warnings for every test class derived from TestPoSCommon, and the comparison silently evaluates to False. Write the id, as done everywhere else in the test suite.
PR:
[FIX] point_of_sale: write the country id, not the record, in tests c…
PR State:
merged
[FIX] website: deflake edit_menus tour when menu items overflow the dialog The final drag section of the edit_menus tour operates on rows the tour itself appends at the bottom of the menu editor list. The drag helper (drag_and_drop_native) computes viewport coordinates from getBoundingClientRect() without scrolling the target into view first, so when installed modules add enough top-level menu items (e.g. to_runbot adds 'Runbot' and 'Runbot Standalone'), the rows to drag overflow the fixed-height dialog body (~490px at 1366x768) and the pointer events silently miss, failing the tour at: Check if 'nested_menu' and 'Modnar !!' is nested under 'new_menu' Scroll the dialog body to the bottom right before the drag section so the dragged rows are always within view. Reproduced and verified on a database where the tour-time list reaches 14-18 rows: failed 6/6 before, passes 3/3 (14 rows), and still passes at 18 and 10 rows after the fix.
PR:
[FIX] website: deflake edit_menus tour when menu items overflow the dialog
PR State:
merged
Merge remote-tracking branch 'odoo/17.0' into 17.0
PR:
Merge from upstream 17 20260808 01
PR State:
merged
[FIX] point_of_sale: adapt tour helper to integer quantity display Commit bf677a9c7e08 backported the Odoo 19 behavior of displaying whole-number quantities without a decimal part, but the tour helper still compared the raw expected quantity string ('1.0'/'1.00') against the rendered '1', breaking every orderline check step across the POS test suites (runbot 223649). Normalize the expected quantity the same way upstream does in 456a7428f8e3 (order_widget_util.js).
PR:
[FIX] point_of_sale: adapt tour helper to integer quantity display
PR State:
merged
[FIX] website: deflake snippet_empty_parent_autoremove tour The customize panel is rebuilt asynchronously (behind the edition mutex) after every selection change or removal, and the stale panel of the previous selection has the same shape as the fresh one. The bare :nth-last-child(3) trigger of 'Remove selected block' can match the stale panel while its editor is being destroyed; the click is then silently swallowed, the column stays in place and the tour times out on 'Check that #wrap is empty' on loaded hosts. Scope the remove trigger to a panel actually showing the Column options (every use of the helper removes a Column block and the stale panel of its parent snippet has no such block), and wait for the second column to leave the iframe DOM before selecting the first one - the column and its options panel are removed in the same synchronous block of removeSnippet, so this guarantees the stale panel is gone. Reproduced on a stock database under host load (2/3 failures with stepDelay=0); consistently green with this change.
PR:
[FIX] website: deflake snippet_empty_parent_autoremove tour
PR State:
merged
[IMP] point_of_sale: hide decimals for integer quantities on receipts Quantities were always formatted with the global 'Product Unit of Measure' decimal precision, so a quantity of 1 was displayed as 1.000 (with a 3-digit precision) on the order screen and the printed receipt, even for countable units such as Units/Piece. Backport the Odoo 19 behavior: whole-number quantities are displayed without a decimal part, while fractional quantities (e.g. 1.5 kg) keep the standard precision-based formatting.
PR:
[IMP] point_of_sale: hide decimals for integer quantities on receipts
PR State:
merged
Merge remote-tracking branch 'odoo/17.0' into 17.0
PR:
Merge from upstream 17 20260722 01
PR State:
closed
Merge remote-tracking branch 'upstream/17.0' into 17.0
PR:
Merged from upstream 17 260722 01
PR State:
merged
[FIX] pos_loyalty: earn loyalty points on POS orders paid online Steps to reproduce: - Install pos_loyalty + pos_online_payment. - Configure a nominative "loyalty" program (trigger=auto, applies_on=both) that awards points, and an online payment method. - In the POS, add a first-time eligible customer + a product, then pay the order with the online payment method and let the customer pay. Issue: The customer earns no loyalty points (no loyalty.card is even created for a first-time buyer). Cash orders work. The loss is intermittent for customers whose card is already cached. Cause: After a successful online payment the order is rebuilt from the server data, which does not carry the client-side `couponPointChanges`, then re-selected. `set_order` schedules an async `_updateRewards()` recompute but does NOT await it, and `afterPaidOrderSavedOnServer` immediately calls `postPushOrderResolve`, so `confirm_coupon_programs` reads an empty `couponPointChanges`. A first-time buyer additionally needs an async `fetchLoyaltyCard` RPC, so the recompute can never win the race. Fix: - `_updateRewards`: return the mutex promise so it can be awaited. - `afterPaidOrderSavedOnServer`: await the reward recompute before confirming the coupon programs.
PR:
[FIX] pos_loyalty: earn loyalty points on POS orders paid online
PR State:
merged
Merge remote-tracking branch 'upstream/17.0' into 17.0
PR:
Merge from upstream 17 260708 01
PR State:
merged
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 2x
PR State:
closed
Merge remote-tracking branch 'odoo/19.0' into 19.0
PR:
Merge from upstream 19 20260519 01
PR State:
merged
Merge remote-tracking branch 'odoo/19.0' into 19.0
PR:
Merge from upstream 19 20260512 01
PR State:
merged
[FIX] stock: 'stock.move.line' object has no attribute 'outermost_result_package_id'
PR:
Rebased from upstream 19 260312 01
PR State:
merged
[FIX] stock: 'stock.move.line' object has no attribute 'outermost_result_package_id'
PR:
Rebased from upstream 19 260312 01
PR State:
merged
[I18N] account*: fix i18n (#1198) * [I18N] account*: fix i18n Forward-Port-Of: #1196 * Update vi.po --------- Co-authored-by: quyen <duyquyencnt55@gmail.com> Co-authored-by: Roy Le <43790414+royle-vietnam@users.noreply.github.com>
PR:
Rebased from upstream 19 260308 01
PR State:
closed
Merge remote-tracking branch 'odoo/19.0' into 19.0
PR:
Merge from upstream 19 20260305 01
PR State:
closed