Tuesday, April 29, 2025
23 changes · 18.0
Resolved issues and error corrections
This fix makes Odoo's automated tests more stable by preventing one failed WebSocket-related test from affecting the next test. It reduces random build failures and helps teams trust test results during development and maintenance.
Original PR description
Build error 162704 Will be backported in 16.0 via 207975 (focusing on 18.0->master to start) Follow-up on other WebSocket fixes, this time for the execution of the WebSocket request inside the same test, but not after a Chrome browser. This case is quite specific and is related to a low timeout set on websocket_connect, leading to the request being randomly executed inside the test. This is a problem for the current test (fixed by increasing the timeout), but also for the next test: if the TestCursor rollback fails, the cursor_stack of the TestCursor is not emptied, leading to a case where an existing read-only test cursor in the stack makes the next TestCursor read-only, causing chain failures. This pr adresses the problem by - increasing the timeout - making the TestCursor.close more robust - Ensuring that the cursor_stack is empty at the end of a test.
This fixes an unstable automated test for Odoo's mail messaging area that could fail depending on timing. The change helps keep test results consistent, reducing false alarms during quality checks without changing user-facing behavior.
Original PR description
Before this commit, the test "Message shows up even if channel data is incomplete" would sometimes fail. This happened because it waited for a bus subscription triggered by a call to the `_forceUpdateChannel` method of the bus service. However, this method is debounced, and as a result, the subscription sometimes occurred too late, causing the test to fail. This commit resolves the issue by using `runAllTimers`, which immediately executes the debounced method. fixes runbot-76011
The website page properties test tour was updated so required page elements are visible before the test continues. This helps keep automated quality checks reliable and reduces false failures during development.
Original PR description
Thanks to [1], we can now fix the website page properties tour ensuring that the necessary elements are visible on the page. [1]: https://github.com/odoo/odoo/commit/4e25c13c918382afb34013a6dd30aac4a0ce4e84 runbot-106391 Co-authored-by: Pierre Pulinckx
Event tickets sold through Point of Sale now show the correct sales status. This prevents completed or draft PoS ticket orders from being incorrectly marked as free, giving staff a more accurate view of ticket sales.
Original PR description
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order when the ticket has been sold through the PoS. opw-4584390
This update ensures a loyalty-related automated test only runs when the discount feature it needs is installed. It prevents false test failures in setups that use loyalty features without the separate point-of-sale discount module.
Original PR description
PR #202334 introduced a test in `pos_loyalty` that depends on the field `discount_product_id` that is created in the module `pos_discount`. However, `pos_loyalty` and `pos_discount` does not have dependence, so the fails if `pos_discount` is not installed. This PR only runs it when `pos_discount` is installed. opw-4622428
Printed payslips now respect the payslip structure setting for worked day lines. When worked day lines are disabled on the payslip form, the printed report no longer shows that table, avoiding confusion for employees and payroll teams.
Original PR description
- If the payslip sturct has `use_worked_day_lines = False` the printed payslip shoud not have worked_days_table Task: 4720429
Documentation and clarification updates
This pull request records the corporate contributor license agreement for Ecodica d.o.o. It supports Odoo's legal compliance process by documenting that the company is authorized to contribute code under the required terms.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce the bug: - Use Edge browser with zoom set to 150% (default zoom on Windows installations). - On a screen with a resolution of 1920px (and the browser window set to full width). - Install the Website app and go to the homepage. - The page is displayed in desktop view. - Enter edit mode by clicking the "Edit" button. - The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the
Original PR description
Steps to reproduce the bug: - Use Edge browser with zoom set to 150% (default zoom on Windows installations). - On a screen with a resolution of 1920px (and the browser window set to full width). -…
Steps to reproduce the bug: - Use Edge browser with zoom set to 150% (default zoom on Windows installations). - On a screen with a resolution of 1920px (and the browser window set to full width). - Install the Website app and go to the homepage. - The page is displayed in desktop view. - Enter edit mode by clicking the "Edit" button. - The page width becomes smaller than the mobile breakpoint. As a result , the page switches to mobile view: the navbar turns into a hamburger menu, and the layout changes to mobile style. This should not happen, as the edit mode is designed to remain in desktop view with 150% zoom on 1920px wide screens. The issue is caused by Edge adding a few pixels of border around the browser window, which leads to this problem specific to Edge. To fix this in the stable version, we reduce the sidebar width in edit mode by 5 pixels to ensure the page stays in desktop view. This change is applied only if the browser is Edge and 150% zoom is used. In all other cases, no changes are made. This fix is temporary. In the next redesign of the edit mode sidebar, the sidebar width will be adjusted accordingly so that this workaround will no longer be necessary. Note: The Arc browser has the same issue, but we haven’t fixed it because there’s currently no way to reliably detect it in JavaScript. Since Arc is much less popular than Edge, it’s less critical. task-4587203 Forward-Port-Of: odoo/odoo#205721
When using an intermediate return location, the delivered qty of a returned kit is incorrect To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a location L: - Parent: WH - Type: Internal - Return location: True 3. Create a route: - Applicable on: Main warehouse - Add one rule: - Action: Push To - Operation Type: Internal - From: L - To: WH/Stock 4. Create a kit K 5. Sell and deliver 1 x K 6. Return it to L - It
Original PR description
When using an intermediate return location, the delivered qty of a returned kit is incorrect To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a location L: - Parent: WH -…
When using an intermediate return location, the delivered qty of a
returned kit is incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a location L:
- Parent: WH
- Type: Internal
- Return location: True
3. Create a route:
- Applicable on: Main warehouse
- Add one rule:
- Action: Push To
- Operation Type: Internal
- From: L
- To: WH/Stock
4. Create a kit K
5. Sell and deliver 1 x K
6. Return it to L
- It will create an internal transfer
7. Process the internal transfer
8. Open the SO
Error: The delivered quantity of the kit is -1 instead of 0
Step 6, when returning the kit, the push rule is applied and create
the SM from L to WH/Stock. Since we copy the SM from Customer to L, the
new SM also has the field `sale_line_id` defined.
As a result, step 7, since all SM are done, `moves` contain them
(the delivery, the return and the internal transfer). We then filter
them based on some criteria:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L67-L73
But, for `outgoing_moves` (which is actually the incoming ones, the
name is wrong), since we look at the destination location, both the
return and the internal SM will match. That's why we will decrease
twice the delivered quantity. Hence, the bug.
A fix could be to avoid copying the `sale_line_id` field. That being
said, when looking `sale_stock` side (i.e., same flow with a classic
product), we don't have any issue because the filters are slightly
different:
https://github.com/odoo/odoo/blob/418dc0cc3b3aa1ee2abbdb4852d9cd24fba7636e/addons/sale_stock/models/sale_order_line.py#L274-L278
(Here, we need to look at the `incoming_moves`. Again: the name is just
incorrect on mrp side...)
We see that, for `incoming_moves`, we actually look at the source
location. This explains why we don't have any issue with a non-kit
product.
Therefore, the best fix would be to use the same filters everywhere.
Good news, such a method already exist:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/sale_mrp/models/sale_order_line.py#L115-L116
However, using this method might lead to some other issues (among them:
the override in `sale_subscription_stock` reads a field although the
method is an `api.model` one). So, let's minimize the diff on stable
version and refactor the code (use the same filters everywhere) on
master.
About the filter names, the confusion actually comes from:
https://github.com/odoo/odoo/blob/312572c7b8138a4800350cd7a524a37551a348ef/addons/mrp/models/stock_move.py#L624
There, we should rather talk about positive moves and negatives
moves, since this method can be used either in a SO flow or in a PO
one. This explains why, for now, SO sode, an "incoming move" is
actually an outgoing one. So, on master, another commit will be
added to also clean that part of the code:
\- Improve the expected filter names in `_compute_kit_quantities`
\- Fix the filter names in `_get_incoming_outgoing_moves_filter`
OPW-4625228
Forward-Port-Of: odoo/odoo#207275
Forward-Port-Of: odoo/odoo#206966Steps to reproduce: Using POS configs in french company with l10n_fr_post_cert module installed. - Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment. - Cash desk 2: Prepare an order - Cash-desk 1: Start order payment. - Cash-desk 2: Start order payment while cash-desk 1 is still paying. Issue: When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs
Original PR description
Steps to reproduce: Using POS configs in french company with l10n_fr_post_cert module installed. - Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient…
Steps to reproduce: Using POS configs in french company with l10n_fr_post_cert module installed. - Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment. - Cash desk 2: Prepare an order - Cash-desk 1: Start order payment. - Cash-desk 2: Start order payment while cash-desk 1 is still paying. Issue: When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries. Task-4708543 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207555 Forward-Port-Of: odoo/odoo#205935
When a partner's receivable account is set with a secondary currency, and an invoice is duplicated and its currency is changed, Odoo currently allows the invoice to be validated even though the account's currency no longer matches the invoice currency. that was because the order of calling ```_check_constrains_account_id_journal_id ``` in move line write function. This creates inconsistencies, as the account currency should match the invoice currency when posted. task-4684038 Descrip
Original PR description
When a partner's receivable account is set with a secondary currency, and an invoice is duplicated and its currency is changed, Odoo currently allows the invoice to be validated even though the account's currency no longer matches the invoice currency. that was because the order of calling ```_check_constrains_account_id_journal_id ``` in move line write function. This creates inconsistencies, as the account currency should match the invoice currency when posted. task-4684038 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207430 Forward-Port-Of: odoo/odoo#204164
If the customer display type is remote or proxy, the data goes through JSON serialization before being sent. This causes undefined property to not be send. When we change `this.order.qrPaymentData` from an object to undefined, the useEffect will not be triggered. This is not the case with null. https://github.com/odoo/odoo/blob/2439af09c7586a22822549164b677fa6fb805359/addons/point_of_sale/static/src/customer_display/customer_display.js#L42-L51 Forward-Port-Of: odoo/odoo#207651
Original PR description
If the customer display type is remote or proxy, the data goes through JSON serialization before being sent. This causes undefined property to not be send. When we change `this.order.qrPaymentData` from an object to undefined, the useEffect will not be triggered. This is not the case with null. https://github.com/odoo/odoo/blob/2439af09c7586a22822549164b677fa6fb805359/addons/point_of_sale/static/src/customer_display/customer_display.js#L42-L51 Forward-Port-Of: odoo/odoo#207651
This commit changed the way to give the render_model to the model fleet_vehicle_send_mail (introduced by this commit : #61221b2e6552b21508a6a36ab69352e6793d70c5) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207749
Original PR description
This commit changed the way to give the render_model to the model fleet_vehicle_send_mail (introduced by this commit : #61221b2e6552b21508a6a36ab69352e6793d70c5) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207749
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207210 Forward-Port-Of: odoo/odoo#203254
Original PR description
With this commit; if a template is selected (need to be added in xml view in 16.0 but already display in 17.2) the body and the subject will be rendered. task-4664784 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207210 Forward-Port-Of: odoo/odoo#203254
In 80ff2d2 hooks were added so that we can guarantee currency exchange diff journal entries & items in the proper journal & account- but an accountant doesn't necessarily have a group that permits access to the `Stock.valuation.layer` model (which is checked raw, without sudo, when `stock_account` is installed) -> AccessError So we will always allow access to an SVL record in this context via `sudo()`. Forward-Port-Of: odoo/odoo#207897
Original PR description
In 80ff2d2 hooks were added so that we can guarantee currency exchange diff journal entries & items in the proper journal & account- but an accountant doesn't necessarily have a group that permits access to the `Stock.valuation.layer` model (which is checked raw, without sudo, when `stock_account` is installed) -> AccessError So we will always allow access to an SVL record in this context via `sudo()`. Forward-Port-Of: odoo/odoo#207897
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice for the order; 5. via the delivery form, create & validate a return delivery; 6. create a new invoice for the order. Issue ----- The sales team on the initial invoice is the same one as on the order. The sales team on the second invoice is changed to a default value. Cause -----
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice…
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice for the order; 5. via the delivery form, create & validate a return delivery; 6. create a new invoice for the order. Issue ----- The sales team on the initial invoice is the same one as on the order. The sales team on the second invoice is changed to a default value. Cause ----- The `team_id` gets recomputed on a `move_type` change. The reason the `move_type` changed after creation, is because the `_create_invoices` method first wants to have the final total of the invoice before deciding whether it should be an `out_invoice` or an `out_refund`: https://github.com/odoo/odoo/blob/d7af5c443b03c18e364a74571560b3583969c1d7/addons/sale/models/sale_order.py#L1401-L1407 Solution -------- Knowing that the `action_switch_move_type` method could recompute the `team_id`, protect the field when calling it in `_create_invoices`. opw-4563006 Forward-Port-Of: odoo/odoo#206514 Forward-Port-Of: odoo/odoo#205167
This commit disable both protection upon neutralizing a db by removing the tokens. Manual forward port of #207020 opw-4734555 upg-2759374 Forward-Port-Of: odoo/odoo#207684
Original PR description
This commit disable both protection upon neutralizing a db by removing the tokens. Manual forward port of #207020 opw-4734555 upg-2759374 Forward-Port-Of: odoo/odoo#207684
When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior. While at it, update the NSIS version. Forward-Port-Of: odoo/odoo#207464
Original PR description
When uninstalling Odoo with the NSIS uninstaller, whole install dir is removed when ngingx is not found which is not the desired behavior. While at it, update the NSIS version. Forward-Port-Of: odoo/odoo#207464
Steps to reproduce: - enable qr code - create an invoice with a swiss client - try to print it Issue: An error is raised Cause: There is no reference for a Swiss invoice in draft. If there is no reference, it is not possible to print the qr code in Switzerland. Solution: We prevent QR code generation whenever the invoice is in draft. opw-4585574 Forward-Port-Of: odoo/odoo#204661 Forward-Port-Of: odoo/odoo#198498
Original PR description
Steps to reproduce: - enable qr code - create an invoice with a swiss client - try to print it Issue: An error is raised Cause: There is no reference for a Swiss invoice in draft. If there is no reference, it is not possible to print the qr code in Switzerland. Solution: We prevent QR code generation whenever the invoice is in draft. opw-4585574 Forward-Port-Of: odoo/odoo#204661 Forward-Port-Of: odoo/odoo#198498
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue. - **Focus Issue When Using Keyboard** When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now
Original PR description
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong…
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue. - **Focus Issue When Using Keyboard** When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now doesn’t take focus, so keyboard navigation keeps working smoothly. - **Upload Button & Error Fixes** - The upload button was showing for spreadsheet cell comments but didn’t work. It’s now hidden. - There was also an error when editing a comment because `this.thread` wasn’t always available. Now it falls back to `this.message?.thread` when editing the message. - **Popover Visibility Fix** When posting the first comment and hovering over it, the action buttons (edit, favorite, delete) were partly cut off. This is now fixed by adding some padding to the thread style.  **Task**: [4708400](https://www.odoo.com/odoo/project/2328/tasks/4708400) Forward-Port-Of: odoo/enterprise#83410
…terms Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days" - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled. This occurs because each installment of the payment terms will be a payment term line, an
Original PR description
…terms Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner with the payment term "30% Now, Balance 60 Days" - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Amount shown on lines "Total amount of intra-community operations" and "E. Intra-community sales" is doubled. This occurs because each installment of the payment terms will be a payment term line, and the query retrieving values to compose MOD349 will take the whole move amount for each payment term line. opw-4637439 Forward-Port-Of: odoo/enterprise#83841 Forward-Port-Of: odoo/enterprise#82435
Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to
Original PR description
Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times. Steps to reproduce:…
Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on zebra printer * Create a sale order, using fedex international as shipping * Confirm the SO * Select the delivery * Duplicate the delivery * Validate both deliveries delivery > Observation: I have 4 jobs send for printing instead of 2 Why the fix: ------------ Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1 as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter. https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46 opw-4526013 Forward-Port-Of: odoo/enterprise#82091
When the user tries to reply a whatsapp message, a traceback will appear. Steps to reproduce the Error: - Install ``whatsapp`` and ``contacts`` module - Go to WhatsApp > Configuration > WhatsApp Business Account > create a new account > Default Users: Mitchell Admin > Save - Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp > Send a message with any template - Contact will receive the message > Reply to that whatsapp message Traceback: ``` UniqueViolation d
Original PR description
When the user tries to reply a whatsapp message, a traceback will appear. Steps to reproduce the Error: - Install ``whatsapp`` and ``contacts`` module - Go to WhatsApp > Configuration > WhatsApp…
When the user tries to reply a whatsapp message, a traceback will appear. Steps to reproduce the Error: - Install ``whatsapp`` and ``contacts`` module - Go to WhatsApp > Configuration > WhatsApp Business Account > create a new account > Default Users: Mitchell Admin > Save - Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp > Send a message with any template - Contact will receive the message > Reply to that whatsapp message Traceback: ``` UniqueViolation duplicate key value violates unique constraint "discuss_channel_member_partner_unique" DETAIL: Key (channel_id, partner_id)=(84, 175) already exists. ``` https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to ``partners_to_notify`` multiple times. Channel members should be unique. So, when it tries to create ``channel_member_ids`` with same partners, It will lead to the above traceback. 1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219 2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249 sentry-6252537579 Forward-Port-Of: odoo/enterprise#83908