|
|
|
merged
Merged from upstream 18 261002 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
open
[FIX] stock_account: let a product without stock change category without valuation access
|
[FIX] stock_account: let a product without stock change category without
valuation access
Changing the category of a product to one with another cost method or
valuation empties and replenishes its valuation layers. Since
61782d7163be ("[PERF] stock_account: prevent MemoryError in
_svl_empty_stock"), `_svl_empty_stock()` reads `stock.valuation.layer`
up front for every impacted product to collect the lots of lot-valuated
ones, even when no product holds any stock. Users allowed to edit
products but not Inventory/Administrator (every other manager group)
therefore got "You are not allowed to access 'Stock Valuation Layer'"
right after creating a product and changing its category.
Return early when no impacted product holds stock, and only collect lots
of lot-valuated products holding stock, the only ones whose lots are
used. A product with stock still creates layers, and that stays refused
for those users, exactly as before.
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260919 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
|
[FIX] website_sale: a garbage ?category= on a product page must not answer 500
SQL-injection scanners request product pages with payloads in ?category=
(e.g. "1' AND 1=1 UNION SELECT NULL-- -"): int(category) raised
ValueError in _prepare_product_values and the page answered 500 - 1,031
times in one week on a production 16.0 shop. The earlier guard only
covered the shop listing. The category only drives the breadcrumb and the
back link here, so an invalid one is ignored, as upstream 19.0 does.
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] tests, project: stabilise the browser tests that fail on the runbot
|
[FIX] project: wait for quick-create to enable before editing
The "Second task" step in project_update_tour ran right after the
prior quick-create ("New task") was validated, while
KanbanRecordQuickCreate was still in its post-validate disabled
window (o_disabled, pointer-events: none) held until web_save ->
web_read -> onchange -> model.load resolve. Under network/CI latency
the tour's click, aimed at that inert input, resolved to the ancestor
`.o_kanban_group` instead (pointer-events: none excludes the input
from hit-testing), and the following edit step then failed with
"target should be editable".
This reproduced 3/3 on retry within a single Viindoo runbot build
but was intermittent across separate builds, consistent with a
latency-dependent race, and reproduced locally on demand by
injecting 150ms of CDP network latency.
Guard the step's trigger to wait until the quick-create leaves
o_disabled before interacting. The earlier "New task" edit step is
left unchanged: it runs right after opening a fresh quick-create,
not inside any post-validate disabled window.
Verified on this fix: one 0ms-latency run and two 150ms-latency runs,
two tours succeeded and none failed in each run. Without the guard
the same 150ms latency fails the tour at this step. Live users are
unaffected: focus stays in the quick-create input during the save.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] tests, project: stabilise the browser tests that fail on the runbot
|
[FIX] tests: park the mouse out of the viewport before browser tests
Seven `web` module HOOT/browser tests were deterministically red on
the Viindoo runbot (18.0): four in WebSuite.test_hoot, three in
WebSuite.test_unit_desktop (autocomplete and sortable).
On the Viindoo runbot, the failure signature is byte-identical to a
mouse cursor resting inside the viewport at test-page load. The
runbot's own OS-level cursor position was never directly observed -
only the in-page mechanism is proven: a known cursor position lets
Blink dispatch a genuine TRUSTED pointerover/mouseover event into
whatever element sits under that point on the next focus/scroll/
layout change, corrupting hoot-dom fixture assertions, AutoComplete's
mouseover handlers, and sortable's edge-scroll math.
Add ChromeBrowser._park_mouse_outside_viewport(), which sends CDP
Input.dispatchMouseEvent {type: 'mouseMoved', x: -100, y: -100}
(defensive: logs and never raises on failure). Call it from
HttpCase.browser_js right after _wait_ready succeeds and before
test code runs.
Add addons/web/tests/test_browser_harness.py
(BrowserHarnessCursorHygieneTests) as a guard: a permanent
sensitivity proof plus the actual regression guard, both authored
test-first (RED, confirmed failing before the fix, confirmed green
after).
Verified by a prior debug run's toggle on Chrome for Testing
150.0.7871.114 (the runbot's exact build): 7/7 failures reproduced
then cleared, byte-identical output both directions. Re-confirmed
on the finished fix with an integrated run on a fresh ephemeral
Odoo 18.0 instance (core-only, web module), same Chrome build:
0 failed, 0 error(s) of 4 tests - both new guard-test methods
green, WebSuite.test_hoot 199/199, and
WebSuite.test_unit_desktop[@web/core/autocomplete,@web/core/utils/sortable]
33/33, the exact previously-failing set. No existing test, hoot, or
hoot-dom file was touched.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
closed
[FIX] project: wait for quick-create to enable before editing
|
[FIX] project: wait for quick-create to enable before editing
The "Second task" step in project_update_tour ran right after the
prior quick-create ("New task") was validated, while
KanbanRecordQuickCreate was still in its post-validate disabled
window (o_disabled, pointer-events: none) held until web_save ->
web_read -> onchange -> model.load resolve. Under network/CI latency
the tour's click, aimed at that inert input, resolved to the ancestor
`.o_kanban_group` instead (pointer-events: none excludes the input
from hit-testing), and the following edit step then failed with
"target should be editable".
This reproduced 3/3 on retry within a single Viindoo runbot build
but was intermittent across separate builds, consistent with a
latency-dependent race, and reproduced locally on demand by
injecting 150ms of CDP network latency.
Guard the step's trigger to wait until the quick-create leaves
o_disabled before interacting. The earlier "New task" edit step is
left unchanged: it runs right after opening a fresh quick-create,
not inside any post-validate disabled window.
Verified on this fix: one 0ms-latency run and two 150ms-latency runs,
two tours succeeded and none failed in each run. Without the guard
the same 150ms latency fails the tour at this step. Live users are
unaffected: focus stays in the quick-create input during the save.
Signed-off-by: David Tran <david.tran@tvtmarine.com>
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
closed
V18 fix tour tests
|
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260910 01
|
[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>
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260910 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260908 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260906 01
|
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX] pos_restaurant: wait for the order sync instead of racing it
|
[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).
|
Killed
|
|
|
|
|
|
|
|
closed
[FIX] pos_restaurant: wait for the order sync instead of racing it
|
[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).
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 260826 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260824 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260813 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] pos_sale: assert every sale picking is cancelled, not a single one
|
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
merged
[FIX] pos_sale: assert every sale picking is cancelled, not a single one
|
[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.
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
merged
Merge from upstream 18 20260812 01
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260812 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260812 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
Merge from upstream 18 20260808 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] point_of_sale: adapt tour helper to integer quantity display
|
[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).
|
Killed
|
|
|
|
|
|
|
|
merged
[IMP] point_of_sale: hide decimals for integer quantities on receipts
|
[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.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
Merged from upstream 18 260724 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260722 01
|
[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.
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260722 01
|
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260722 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merged from upstream 18 260716 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX] point_of_sale: add deterministic tiebreaker to limited product loading
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260707 01
|
|
Failed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260615 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
closed
Merge from upstream 18 20260519 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260512 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260312 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 18 20260312 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0
|
Failed
|
|
|
|
|
|
|
|
merged
[FWD][18.0][I18N] account*: fix i18n
|
Update vi.po
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260218 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 18 260216 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0
|
Killed
|
|
|
|
|
