|
|
|
merged
[FIX] test_base_automation: deflake custom reference field tour
|
[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.
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX] point_of_sale: write the country id, not the record, in tests c…
|
[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.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] website: deflake edit_menus tour when menu items overflow the dialog
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260808 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.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 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).
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] website: deflake snippet_empty_parent_autoremove tour
|
[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.
|
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
|
|
|
|
|
|
closed
Merge from upstream 17 20260722 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
Merged from upstream 17 260722 01
|
Merge remote-tracking branch 'upstream/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] pos_loyalty: earn loyalty points on POS orders paid online
|
[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.
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 260708 01
|
Merge remote-tracking branch 'upstream/17.0' into 17.0
|
Failed
|
|
|
|
|
|
|
|
closed
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 1.5x
|
[MISC] odoo/service: scale up by one worker when all workers are busy,
the total number of workers is limited to 2x
|
Killed
|
|
|
|
|
|
|
|
closed
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 1.5x
|
|
Killed
|
|
Not finished
|
|
|
|
|
|
closed
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 1.5x
|
|
Killed
|
|
|
|
|
|
|
|
closed
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 1.5x
|
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] stock: soft correct unsynch between quant and stock.move.line
|
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] stock: soft correct unsynch between quant and stock.move.line
|
[FIX] stock: soft correct unsynch between quant and stock.move.line
It happens due to many reasons that the `stock.quant` object and
`stock.move.line` loose their synchronisation and it could have a
difference between the sum of `stock.move.line` and the
quantity/reserved
quantity on the `stock.quant`
It's important to keep tracking why the desycnh happens and to fix all
the root causes of it.
However, it's hard for the user to clean the data himself or even worst
to lock him when it happens (as before 18.0).
For quantity: It's not a big deal to have a huge difference between the
quantity and all the long time history. As in real life, the inventory
adjustement can help to clean the data.
For reserved quantity: It's a bigger problem since the user can't edit
it. A first step would be to never write it to a negative value (since
it should never happen). That way when the user empty the stock, it will
also probably clean the reserved quantity. But in case where there is
more reservation than on `stock.move.line`. We should also clean it to
be able to reserve them. Currently, we will try in the scheduler for
that part
A last step, could be to create a constraint during test that ensure
the synch is never broken and it could raise directly if the developer
made a mistake
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] stock: soft correct unsynch between quant and stock.move.line
|
[FIX] stock: soft correct unsynch between quant and stock.move.line
It happens due to many reasons that the `stock.quant` object and
`stock.move.line` loose their synchronisation and it could have a
difference between the sum of `stock.move.line` and the quantity/reserved
quantity on the `stock.quant`
It's important to keep tracking why the desycnh happens and to fix all
the root causes of it.
However, it's hard for the user to clean the data himself or even worst
to lock him when it happens (as before 18.0).
For quantity: It's not a big deal to have a huge difference between the
quantity and all the long time history. As in real life, the inventory
adjustement can help to clean the data.
For reserved quantity: It's a bigger problem since the user can't edit
it. A first step would be to never write it to a negative value (since
it should never happen). That way when the user empty the stock, it will
also probably clean the reserved quantity. But in case where there is
more reservation than on `stock.move.line`. We should also clean it to
be able to reserve them. Currently, we will try in the scheduler for
that part
A last step, could be to create a constraint during test that ensure
the synch is never broken and it could raise directly if the developer
made a mistake
closes odoo/odoo#188201
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
[FIX] pos_loyalty: keep reward lines on a finalized order
|
[FIX] pos_loyalty: keep reward lines on a finalized order
Steps to reproduce:
- Install pos_loyalty + pos_online_payment.
- Configure an automatic discount program (e.g. 1% off the order) and an
online payment method.
- In the POS, add a customer eligible for the program and a product so
the
discount reward line is added automatically.
- Pay the order with the online payment method and let the customer pay.
Issue:
The receipt printed right after the online payment is missing the
loyalty
discount line: the total is shown without the discount while the amount
actually paid is the discounted amount, so the ticket looks underpaid.
Re-printing the order later shows the correct total. With a loyalty
program
that also gives points, confirming the order additionally raises:
ValueError: invalid literal for int() with base 10: 'false'
Cause:
After a successful online payment the order is rebuilt from the data
saved
on the server and selected again. Selecting an order triggers
`_updateRewards`, which calls `_updateRewardLines` to refresh the
applied
rewards. On this rebuilt order the reward lines reference a coupon that
is
no longer in the local cache (its `coupon_id` comes back as `false` for
"current" programs that don't persist a coupon), so `_updateRewardLines`
removes them and cannot re-apply them. The order then displays a wrong
total, and `_postPushOrderResolve` sends that `false` coupon id to
`confirm_coupon_programs`, which fails when casting the key to an int.
The order is already paid and saved: its reward lines are authoritative
and
must not be recomputed.
Fix:
- `_updateRewardLines`: do nothing on a finalized order
(paid/done/invoiced)
so the rewards saved on the server are kept as-is.
- `_postPushOrderResolve`: skip reward lines that have no coupon, so no
invalid coupon id is sent to `confirm_coupon_programs`.
|
Failed
|
|
|
|
|
|
|
|
merged
[FIX] pos_loyalty: keep reward lines on a finalized order
|
[FIX] pos_loyalty: keep reward lines on a finalized order
Steps to reproduce:
- Install pos_loyalty + pos_online_payment.
- Configure an automatic discount program (e.g. 1% off the order) and an
online payment method.
- In the POS, add a customer eligible for the program and a product so
the
discount reward line is added automatically.
- Pay the order with the online payment method and let the customer pay.
Issue:
The receipt printed right after the online payment is missing the
loyalty
discount line: the total is shown without the discount while the amount
actually paid is the discounted amount, so the ticket looks underpaid.
Re-printing the order later shows the correct total. With a loyalty
program
that also gives points, confirming the order additionally raises:
ValueError: invalid literal for int() with base 10: 'false'
Cause:
After a successful online payment the order is rebuilt from the data
saved
on the server and selected again. Selecting an order triggers
`_updateRewards`, which calls `_updateRewardLines` to refresh the
applied
rewards. On this rebuilt order the reward lines reference a coupon that
is
no longer in the local cache (its `coupon_id` comes back as `false` for
"current" programs that don't persist a coupon), so `_updateRewardLines`
removes them and cannot re-apply them. The order then displays a wrong
total, and `_postPushOrderResolve` sends that `false` coupon id to
`confirm_coupon_programs`, which fails when casting the key to an int.
The order is already paid and saved: its reward lines are authoritative
and
must not be recomputed.
Fix:
- `_updateRewardLines`: do nothing on a finalized order
(paid/done/invoiced)
so the rewards saved on the server are kept as-is.
- `_postPushOrderResolve`: skip reward lines that have no coupon, so no
invalid coupon id is sent to `confirm_coupon_programs`.
|
Killed
|
|
Not finished
|
|
|
|
|
|
merged
Merge from upstream 17 20260615 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] pos_online_payment: allow closing sessions with restricted payment provider access
|
|
Killed
|
|
|
|
|
|
|
|
merged
[FIX] im_livechat: prevent crash and stale window when leaving session
|
[FIX] im_livechat: prevent crash and stale window when leaving session
Closing a livechat conversation fails when the visitor's guest context is
no longer available (the `dgid` cookie expired, was cleared, is blocked as
a third-party cookie on an embedded livechat, or the visitor is in private
browsing).
`/im_livechat/visitor_leave_session` resolves the visitor's
`discuss.channel.member` through the `is_self` domain and calls
`_rtc_leave_call()` on the result. Without a guest context the lookup
returns an empty recordset, so `_rtc_leave_call()` hits `ensure_one()` and
raises `Expected singleton: discuss.channel.member()`, returning a 500.
The exception also prevents `_close_livechat_session()` from running, so
the conversation stays open server-side.
In addition, `LivechatService.leaveSession` removed the saved session from
the storage in a `finally` block, after awaiting the
`visitor_leave_session` RPC. When the visitor leaves the page right after
closing the chat, the in-flight request is aborted and the page is torn
down before the `finally` runs, so the stale session is restored on the
next page load.
Only call `_rtc_leave_call()` when a member is found, always close the
livechat session afterwards, and clear the saved session synchronously
before notifying the server.
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 17 260605 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260519 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260512 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
closed
Merge from upstream 17.0 (2026-04-30)
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
# Conflicts:
# addons/account/i18n/vi.po
# addons/hr_expense/i18n/vi.po
# addons/mail/i18n/mail.pot
# addons/mrp_account/i18n/vi.po
# addons/sale/i18n/vi.po
# addons/web_unsplash/i18n/vi.po
# addons/website/i18n/vi.po
# odoo/addons/base/i18n/vi.po
|
Failed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260428 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260403 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Failed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260319 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260319 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Failed
|
|
|
|
|
|
|
|
closed
[MISC] odoo/service: scale up by one worker when all workers are busy, the total number of workers is limited to 1.5x
|
[MISC] odoo/service: scale up by one worker when all workers are busy,
the total number of workers is limited to 1.5x
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260305 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
Merge from upstream 17 20260228 01
|
Merge remote-tracking branch 'odoo/17.0' into 17.0
|
Killed
|
|
|
|
|
|
|
|
merged
[I18N][17.0] account*: fix i18n
|
[I18N] account*: fix i18n
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 17 260218 01
|
|
Killed
|
|
|
|
|
|
|
|
merged
Merged from upstream 17 260216 01
|
Merge remote-tracking branch 'upstream/17.0' into 17.0
|
Failed
|
|
|
|
|
|
|
|
merged
Merged from upstream 17 260211 01
|
Merge remote-tracking branch 'upstream/17.0' into 17.0
|
Failed
|
|
|
|
|
|
|
|
merged
[I18N] purchase: SyntaxError: invalid syntax
|
[I18N] purchase: SyntaxError: invalid syntax
|
Killed
|
Not started
|
Not finished
|
|
|
|
|
|
merged
[I18N][17.0] point_of_sale: fix i18n
|
[I18N] point_of_sale: fix i18n
|
Killed
|
|
|
|
|
