Branch
[FIX] account_edi_ubl_cii: prevent deferred test crash on Community test_invoice_deferred_dates sets invoice.line fields deferred_start_date/deferred_end_date on the new line's create-vals, but only the Enterprise addon account_accountant defines them. Without it installed, the test crashed on every Community build instead of being skipped. Guard it with ensure_installed("account_accountant"), the same idiom already used four times elsewhere in this file, since the fields belong to the Enterprise deferred-revenue feature and are absent here by design. Signed-off-by: David Tran <david.tran@tvtmarine.com>
PR:
Merged from upstream 18 260910 01
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260910 01
PR State:
merged
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 18 260908 01
PR State:
closed
[FIX] pos_restaurant: wait for the order sync instead of racing it The "Check if order has a server ID" step of the test_book_and_release_table tour sampled the order's id exactly once and threw if it was not yet a number. Nothing sequenced that sample after the syncAllOrders RPC that assigns the id: the preceding waitForLoading() only waits for `body:not(:has(.loader))`, and the step's own `trigger: "body"` matches immediately. Whether the step passed was therefore decided by whether the server happened to answer first. On Viindoo's runbot it does not. Subbuild 407980 shows the step running at 02:05:36,110 and the server logging "created pos.order #563" at 02:05:36,152 - the assertion lost the race by 42 ms and the tour failed, even though the order was created successfully moments later. The margin is small and hardware-dependent, not caused by module load. Measured across 24 runs at four addons-path scales (58, 126, 293 and 1330 installed modules - the last exceeding runbot's own 1089), the server won locally by +50..+93 ms every time, and a 23x growth in installed modules moved the mean by only ~24%. Registry size, POS asset-bundle weight and third-party POS addons were each ruled out as the mechanism; what differs is how fast the machine is. Poll for the id with a deadline instead of sampling once, so the step waits for the sync it depends on rather than racing it. The thrown error is unchanged, so existing log triage still matches. The usual idiom for a non-deterministic tour step is a more specific `trigger`, letting the tour engine's own retry loop do the waiting - see 8cb86ec07ad5 "[FIX] lunch: fix non-determistic tour error". It does not transfer here: the condition is JS model state (posmodel's pos.order id), not a DOM fact, so there is no selector to wait on. Verified by constructing the failure, since the race is won on the development machine and cannot be reproduced there naturally. With a 400 ms sleep injected into pos.order.sync_from_ui, the unfixed tour fails with exactly the runbot signature ("FAILED: [7/10] ... Step Check if order has a server ID" / "Order does not have a valid server ID", delta -360 ms). With that same sleep still in place, the fixed tour passes all 10 steps (delta -320 ms - the server is still slow, the step now waits for it). With the sleep removed the fixed tour passes at +86 ms, back inside the natural baseline band, and the rest of the pos_restaurant suite is unaffected (0 failed, 0 errors; the one skip, test_13_crm_team, needs pos_sale and is pre-existing).
PR:
[FIX] pos_restaurant: wait for the order sync instead of racing it
PR State:
merged
[FIX] pos_restaurant: wait for the order sync instead of racing it The "Check if order has a server ID" step of the test_book_and_release_table tour sampled the order's id exactly once and threw if it was not yet a number. Nothing sequenced that sample after the syncAllOrders RPC that assigns the id: the preceding waitForLoading() only waits for `body:not(:has(.loader))`, and the step's own `trigger: "body"` matches immediately. Whether the step passed was therefore decided by whether the server happened to answer first. On Viindoo's runbot it does not. Subbuild 407980 shows the step running at 02:05:36,110 and the server logging "created pos.order #563" at 02:05:36,152 - the assertion lost the race by 42 ms and the tour failed, even though the order was created successfully moments later. The margin is small and hardware-dependent, not caused by module load. Measured across 24 runs at four addons-path scales (58, 126, 293 and 1330 installed modules - the last exceeding runbot's own 1089), the server won locally by +50..+93 ms every time, and a 23x growth in installed modules moved the mean by only ~24%. Registry size, POS asset-bundle weight and third-party POS addons were each ruled out as the mechanism; what differs is how fast the machine is. Poll for the id with a deadline instead of sampling once, so the step waits for the sync it depends on rather than racing it. The thrown error is unchanged, so existing log triage still matches. The usual idiom for a non-deterministic tour step is a more specific `trigger`, letting the tour engine's own retry loop do the waiting - see 8cb86ec07ad5 "[FIX] lunch: fix non-determistic tour error". It does not transfer here: the condition is JS model state (posmodel's pos.order id), not a DOM fact, so there is no selector to wait on. Verified by constructing the failure, since the race is won on the development machine and cannot be reproduced there naturally. With a 400 ms sleep injected into pos.order.sync_from_ui, the unfixed tour fails with exactly the runbot signature ("FAILED: [7/10] ... Step Check if order has a server ID" / "Order does not have a valid server ID", delta -360 ms). With that same sleep still in place, the fixed tour passes all 10 steps (delta -320 ms - the server is still slow, the step now waits for it). With the sleep removed the fixed tour passes at +86 ms, back inside the natural baseline band, and the rest of the pos_restaurant suite is unaffected (0 failed, 0 errors; the one skip, test_13_crm_team, needs pos_sale and is pre-existing).
PR:
[FIX] pos_restaurant: wait for the order sync instead of racing it
PR State:
closed
Merge remote-tracking branch 'upstream/18.0' into 18.0
PR:
Merged from upstream 260826 01
PR State:
merged
Merge remote-tracking branch 'odoo/18.0' into 18.0
PR:
Merge from upstream 18 20260824 01
PR State:
merged
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
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260911 01
PR State:
merged
Merge remote-tracking branch 'odoo/16.0' into 16.0
PR:
Merge from upstream 16 20260824 01
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
Merge remote-tracking branch 'odoo/17.0' into 17.0
PR:
Merge from upstream 17 20260911 01
PR State:
open
[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 'upstream/19.0' into 19.0
PR:
Merged from upstream 19 260910 01
PR State:
open
[FIX] pos_loyalty: customer-search tours must query the server Four POS tours typed a customer's name into the partner-search box but never pressed Enter, so they only client-side-filtered the preloaded slice of at most 100 partners instead of querying the server, which searches every partner but is only triggered by pressing Enter. This made the tours fail whenever a larger partner set in the target database pushed the fixture partner outside that preloaded slice. Press Enter right after opening the partner-selection screen, using the existing PartnerList.searchCustomerValue(name, true) helper whose true argument triggers the Enter keypress and the server-side search, reusing the pattern already proven elsewhere in this module. Applies to test_not_create_loyalty_card_expired_program, PosOrderClaimReward and PosOrderNoPoints (pos_loyalty_loyalty_program_tour.js) and test_refund_does_not_decrease_points (pos_loyalty_tour.js). Test-only change, no production code touched.
PR:
[FIX] hr_skills_event, pos_loyalty: make two core tours independent of environment
PR State:
merged
[FIX] mail: RST syntax <string>:38: (ERROR/3) Unexpected indentation. <string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
PR:
V19 rebased from upstream 260827 01
PR State:
merged
[FIX] pos_loyalty: stabilize customer loading in tours Keep loyalty browser tours independent from unrelated partner catalogue size by loading all partners before each tour. Add a boundary regression with zero-order partners so the existing customer-selection and refund assertions remain covered.
PR:
[FIX] pos_loyalty: stabilize customer loading in tours
PR State:
closed
[FIX] pos_loyalty: stabilize customer loading in tours Keep loyalty browser tours independent from unrelated partner catalogue size by loading all partners before each tour. Add a boundary regression with zero-order partners so the existing customer-selection and refund assertions remain covered.
PR:
[FIX] pos_loyalty: stabilize customer loading in tours
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