Friday, September 5, 2025
41 changes · saas-18.4
Resolved issues and error corrections
The window used to create a new website now displays the title "Add Website." This small fix makes the action clearer for users and improves consistency in the website setup experience.
Original PR description
The modal used to create a new website was missing a title. This commit fixes the issue by setting its header to "Add Website". Forward-Port-Of: odoo/odoo#225387 Forward-Port-Of: odoo/odoo#225302
Welcome messages in direct chats and channels now use more natural wording. This small correction improves readability and makes the first message users see in conversations less confusing.
Original PR description
Description of the issue this PR addresses: Some welcome messages in direct chats and channels contain minor grammatical errors, making them less natural and slightly confusing for end users. Current behavior before PR: Direct chat message: "This is the start of direct chat with %(userName)s" Channel message: "This is the start of #%(channelName)s channel" Desired behavior after PR is merged: Direct chat message: "This is the start of your direct chat with %(userName)s" Channel message: "This is the start of the #%(channelName)s channel" This improves readability and ensures the welcome messages are grammatically correct. task-4952480 Forward-Port-Of: odoo/odoo#223324
This update brings the embedded spreadsheet engine up to its latest maintenance version and fixes several issues affecting imports, exports, charts, pivot data, formulas, and borders. Business users should see more reliable spreadsheet handling, especially when working with Excel files, pivot tables, and charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a26187362 [REL] 18.4.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a26187362 [REL] 18.4.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a9afde995 [FIX] menu_items: fix sequence calculation for pivot data sources [Task: 5025230](https://www.odoo.com/odoo/2328/tasks/5025230) https://github.com/odoo/o-spreadsheet/commit/90d1bb354 [FIX] evaluation: fix operation with empty matrices [Task: 5001658](https://www.odoo.com/odoo/2328/tasks/5001658) https://github.com/odoo/o-spreadsheet/commit/0b84fb5d9 [FIX] xlsx: make import verbose [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c0f001d94 [FIX] xlsx: cannot import CF with formulas [Task: 4945945](https://www.odoo.com/odoo/2328/tasks/4945945) https://github.com/odoo/o-spreadsheet/commit/ebb8c9556 [FIX] full_screen_chart: prevent fullscreen chart from closing on drag-out [Task: 5005933](https://www.odoo.com/odoo/2328/tasks/5005933) https://github.com/odoo/o-spreadsheet/commit/1ee20185f [FIX] figures: fix xlsx export [Task: 4755779](https://www.odoo.com/odoo/2328/tasks/4755779) https://github.com/odoo/o-spreadsheet/commit/497c8183f [FIX] GaugeChart: Update config upon sheet renaming [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971) https://github.com/odoo/o-spreadsheet/commit/4123c854c [FIX] OT: fix missing transformations [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971) https://github.com/odoo/o-spreadsheet/commit/331cc7d49 [FIX] Range: Clean-up of plugins `adaptRange` [Task: 4868971](https://www.odoo.com/odoo/2328/tasks/4868971) https://github.com/odoo/o-spreadsheet/commit/f7721afc9 [FIX] pivot: handle vectorized formula [Task: 5043187](https://www.odoo.com/odoo/2328/tasks/5043187) https://github.com/odoo/o-spreadsheet/commit/be9b20b7a [FIX] composer: fix import from lib [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f4607eaaf [FIX] borders: Recompute borders on `SET_BORDERS_ON_TARGET` [Task: 5024825](https://www.odoo.com/odoo/2328/tasks/5024825) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The Discuss welcome screen now uses a shared application state instead of temporary screen state to decide when it appears. This prevents inconsistent display behavior caused by page or component lifecycle timing, giving users a steadier experience when opening Discuss.
Original PR description
Before this commit, whether to display the welcome view was based on a component state, so it was dependent on the lifecycle of components This commit changes the condition so that it relies on the store which should prevent inconsistent state. https://runbot.odoo.com/odoo/error/111051 Forward-Port-Of: odoo/odoo#225486 Forward-Port-Of: odoo/odoo#225325
The website editor now shows custom black-to-white color options correctly when dark mode is enabled. This prevents users from accidentally applying the opposite color than the one they selected, improving confidence when editing page designs.
Original PR description
In the html builder, colorpickers belong to the global window (backend), while the elements they target belong to an inner iframe (frontend). When the dark theme is toggled on in the backend, it doesn't affect the frontend. However, given how it works, until this commit, custom black to white color tints were switched visually, but still applied the opposite color (i.e. clicking on the black tint applied white). This commit makes sure that, in such an environment where the colorpicker and the targeted element are not in the same DOM, the color swatches are properly displayed.
This fix prevents website pages created through Studio from failing when they include SVG images. Users can now navigate to generated website pages without hitting an image conversion error, improving reliability for affected HR and website workflows.
Original PR description
Steps to reproduce ================== - Install `hr_contract_salary,web_studio,website` - Go to Employees - Open studio - Click on "Model pages" - Create a new record - Save it - Click on "Go to Website" Error while render the template ValueError: Non-image binary fields can not be converted to HTML Cause of the issue ================== It crashes because the svgs are not supported in the pillow library: https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#fully-supported-formats Solution ======== Skip the image verification if the image is an svg opw-4820322 Forward-Port-Of: odoo/odoo#221936
This fixes a display issue in inherited templates where added text could disappear when nearby content was removed with branding enabled. Business users benefit from more reliable page and view customizations, reducing unexpected missing text in customized Odoo screens.
Original PR description
With the inherit branding activated, have a xpath in an inherited view that removes a node, and adds some text afterwards in the parent of the removed node Before this commit, the text of the spec was not output. This was because it was appended to the removal ProcessingIntruction that was removed later on After this commit, a spec can add text in a node from which a child has been removed 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#223576
Creating a debit note now records only one clear message in the document chatter instead of two overlapping notices. This reduces confusion for users reviewing accounting document history and keeps audit trails easier to read.
Original PR description
* PROBLEM: install account_debit_note module, add a debit note -> check the log at chatter we will see 2 message, one is 'This entry has been duplicated from ...' and another is 'This debit note was created from..' * Fix by only keep one message log in that case * This continue work of https://github.com/odoo/odoo/pull/214302 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#224762
This fix ensures many-to-many checkbox fields pass the relevant context when looking up available records. This helps related records, such as attachments, appear correctly when special business rules or filters are needed.
Original PR description
**Description of the issue/feature this PR addresses:** When `name_search` is called, the `context` is not passed to the method. In some cases, this is necessary, for example, if the field is related to `ir.attachment` and you want to pass `skip_res_field_check` in the context (see https://github.com/OCA/social/pull/1672). **Current behavior before PR:** The `context` is not passed to `name_search`. **Desired behavior after PR is merged:** Ability to pass `context` to `name_search`. From #215420 Forward-Port-Of: odoo/odoo#225438 Forward-Port-Of: odoo/odoo#216588
The employee organizational chart zoom button now opens the correct public employee view for users without HR access rights. This prevents an error and lets limited-access users navigate the chart as intended.
Original PR description
Steps to Reproduce: 1. Install the HR module and log in with a user account that has no access rights. 2. Open the employee form view and click on the zoom button in the organizational chart. 3. A traceback error will occur. Cause: The action associated with this button is intended for the `hr.employee` model, which the user does not have access to. Fix: Use the action created for public employees to open the organizational view correctly. Task-5039925
This fixes an issue where Swiss companies could not see domestic taxes when choosing replacement taxes for a new tax. The domestic fiscal position is now recognized even when it is defined through a country group, ensuring the expected Swiss tax options appear.
Original PR description
#### Issue: No taxes appear in the replace field when creating a new tax in a company based in Switzerland. #### Step to reproduce: - In a company based in Switzerland (l10n_ch) - Create a new tax -…
#### Issue: No taxes appear in the replace field when creating a new tax in a company based in Switzerland. #### Step to reproduce: - In a company based in Switzerland (l10n_ch) - Create a new tax - Add a Fiscal position other than "Switzerland national (+ Liechtenstein)" - Click on the "Replace" field #### Current behavior: - No records are found #### Expected behavior: - Taxes from the "Switzerland national (+Liechtenstein)" fiscal position should appear #### Cause of the issue The Replace field display domestic taxes. Domestic taxes are part of the same fiscal position which is computed as domestic. In the l10n_ch module no fiscal position is computed as `domestic_fiscal_position_id`. Indeed in `account.fiscal.position-ch.csv` the fiscal position we want to be domestic is linked to a `country_group_id`, but no `country_id`. However the domestic fiscal position is computed from `country_id` only. Therefore Switzerland has no `domestic_fiscal_position_id`. #### Solution: This issue already happened [once](https://github.com/odoo/odoo/pull/208810) for an other localization. To avoid the situation to happen again in the future this commit adapts the `_compute_domestic_fiscal_position_id` to include fiscal position with no `country_id` but a `country_group_id`. opw-5011527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224599
This fixes an issue where users could lose the ability to save task description edits after navigating away from the description tab and returning. The editor now keeps the full set of tracking IDs needed to match the server record, preventing confusing save errors and preserving a smoother task editing workflow.
Original PR description
Problem: When editing a task description, if changes are made and then the tab is switched before returning to the description tab and making further edits, saving raises a record ID mismatch error. Cause: Switching tabs destroys the editor. On reset, the editor retrieves IDs locally from the record and strips them down to the last one. This causes the loss of the last ID known by the server. Solution: On reset, append all IDs from the content instead of only the last one, since the server ID might not be the most recent. Steps to reproduce: 1. Open a task. 2. Change the description. 3. Switch to another tab and return to the description. 4. Make further changes. 5. Save. - An error occurs due to record ID mismatch. opw-5012949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225366
Duplicated mega menu links are now preserved as separate items when a page is saved, even if they point to the same destination. This prevents website editors from losing repeated menu entries and keeps navigation layouts consistent after editing.
Original PR description
Before this commit, if the user clicks the "Duplicate" button on a mega menu link and saves the page without changing the href of the newly generated link, the new link is merged with the previous one. This doesn't happen in 18.3. The problem origins from the normalize handler of `FormatPlugin`. The function `mergeAdjacentInlines` merges the links if they are found to be identical. This commit introduces an `unsplittable_node_predicates` in `MegaMenuOptionPlugin` which prevents the mega menu links from being merged, even if they are consecutive and have the same href. How to reproduce the problem: 1. Create a new mega menu (click on navbar link -> edit menu -> add mega menu item) 2. Open the mega menu, click on a link, click on "Duplicate" at least twice 3. Save 4. PROBLEM: after saving, the new links have been merged with the previous Task-4367641
This fixes a Point of Sale issue where starting a new order with a default preset, such as takeout, did not ask for the customer name when required. Staff will now see the expected name prompt, helping restaurants capture needed order details consistently.
Original PR description
Steps to reproduce: - go to the setting of your pos.config - set the default preset as takeout (or any other that require the name) - open your pos - click on new order - the slot selection opens (only if set so it's ok) - but then no dialog to enter the name of the client Issue: The handleSelectNamePreset method in the POS Restaurant module attempts to access the selected preset through the order, but the preset has not yet been set on the order at that point. Fix: Make sure the preset is set on the order before calling handleSelectNamePreset. Task-5030520 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#225304
Fixed an issue where redirected cart URLs could cause the checkout page to fail with a server error. Customers can now reach checkout normally even when the website uses URL rewrite rules, helping avoid interrupted purchases.
Original PR description
Steps: - create a 308 rewrite from /shop/cart to /test/cart - go to /shop/cart Result: An error 500 is shown with this traceback in server log: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'current_step' Template: website.step_wizard Path: /t/div/div[1]/div/div/a/span Node: <span t-field="current_step.name"/> Cause: The code of website()._get_checkout_step_values doesn't take into account possible URL rewrite, so we get an error when showing website.step_wizard template that expect to have found a current_step. Fix: use url_rewrite to match the current URL to the current step and use the step_href of the step as current_website_checkout_step_href to have it not rewritten. Note: without the fix, the added test fail with the error shown above. opw-5037289 Forward-Port-Of: odoo/odoo#224480
This fix prevents an unexpected system error when checking company compatibility for records that use multiple companies instead of a single company field. Users now receive a clear business error explaining which records belong to incompatible companies, helping them correct configuration issues faster.
Original PR description
`_check_company` can be called on models that don't have a `company_id` field, but they might have a `company_ids` one. In this case the message logged as the user error should be able to handle that…
`_check_company` can be called on models that don't have a `company_id` field, but they might have a `company_ids` one. In this case the message logged as the user error should be able to handle that scenario.
Example on how to reproduce the error in accounting:
```py
company_a, company_b
tax_group self.env["account.tax.group"].create(
{
"name": "Tax Group",
"company_id": company_a.id,
}
)
tax = self.env["account.tax"].create(
{
"name": "30% - Loan Tax",
"type_tax_use": "sale",
"tax_exigibility": "on_payment",
"amount": 30,
"amount_type": "percent",
"tax_group_id": tax_group.id,
"company_id": company_a.id,
}
)
account = self.env["account.account"].create({
...,
"company_ids": [Command.link(company_b.id)]
})
account.tax_ids |= tax
```
Error raised
```
AttributeError: 'account.account' object has no attribute 'company_id'
```
After the PR the following message appears:
```
odoo.exceptions.UserError: Incompatible companies on records:
- “Loan Principal” belongs to company “BE Company Loan Tests” and “Default Taxes” (tax_ids: '30% - Loan Tax') belongs to another company.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225177The USB device interface now handles cases where a connected device does not provide a valid product name. This prevents unexpected crashes and helps keep IoT hardware connections more reliable.
Original PR description
Before this commit, if a USB device did not provide a valid product string, the USB interface would crash trying to access it. After this commit, we wrap the access in a try/except to prevent the crash. task-5060062 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225564
Fixes an issue where Point of Sale loyalty discounts for specific products could disappear after scanning an unknown barcode. This keeps eligible discounts available and reapplicable, preventing checkout disruption for cashiers and customers.
Original PR description
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion…
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion program that grants a discount on a specific product category * Open PoS * Add to the order a product that triggers the discount * Scan an unknown barcode * (Try to reapply the discount) > Observation: The discount disappears and cannot be reapplied Why the fix: ------------ In v18.0, the method used `reward.update(...)` to apply the computed list of discountable products, ensuring proper handling by the reactive OWL model. In v18.2, a direct assignment was used instead, which did not properly set the internal state. When the filtered product list was empty, the resulting structure `[['link']]` became invalid, causing the discount to disappear and preventing it from being reapplied. opw-4923687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222892 Forward-Port-Of: odoo/odoo#222017
The accounting invoice menu now triggers the correct action when users refresh outgoing e-invoice statuses. This prevents the system from accidentally running the incoming invoice fetch action instead, helping users keep e-invoice status information up to date.
Original PR description
[FIX] account: add refresh_out_einvoices_status to fetch_einvoices_cog The fetch_einvoices_cog OWL component was missing the trigger for button_refresh_out_einvoices_status, as it always called button_fetch_in_einvoices. Now the function will call a getter to allow easier customization by overriding buttonAction, and it now supports the missing flow for button_refresh_out_einvoices_status. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225417
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change default company for "marc demo" user to `(AR) Responsable Inscripto` - login with "marc demo" , go to shop page, and change site language to sapnish - add a product e.g, three set sofa to cart and goto checkout page - proceed and you will be directed to "Address management page" Observatio
Original PR description
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change…
Step to reproduce: - install `l10n_ar` , `website_sale` and `payment_demo` - Add a language e.g. : spanish (AR) - switch to `(AR) Responsable Inscripto` and create a website for this company - change default company for "marc demo" user to `(AR) Responsable Inscripto` - login with "marc demo" , go to shop page, and change site language to sapnish - add a product e.g, three set sofa to cart and goto checkout page - proceed and you will be directed to "Address management page" Observation: "Identification Type " and "AFIP Responsibility" are not translated Cause: After this commit [1], module l10n_ar_website_sale was dropped and address logic was mooved to l10n_ar and l10n_latam_base but the following pot files were not updated, this caused missing of tranlation in following modules [1] https://github.com/odoo/odoo/commit/5a93da8e9220ecbf664b26445b04717a9245ef5e Fix: Add missing translations in respective po and pot files Before: <img width="903" height="517" alt="image" src="https://github.com/user-attachments/assets/f1e265bd-e976-4698-b83b-9de821073b8c" /> After: <img width="806" height="374" alt="image" src="https://github.com/user-attachments/assets/a04dfde9-8e5d-4699-a1a4-1a8c36339f63" /> opw-5000512 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224260
Adds a test to ensure contact tag searches return the expected format. This helps prevent a traceback when users add tags to contacts, improving reliability without changing user workflows.
Original PR description
Add basic test case for PR https://github.com/odoo/odoo/pull/221866 to ensure that the _search_display_name method on res.partner.category returns a list domain Forward-Port-Of: odoo/odoo#222165
An unstable automated test in the website module has been skipped because it was causing inconsistent validation failures. This helps keep the release process reliable by avoiding false alarms while the underlying test issue can be addressed separately.
Original PR description
Test seems dodgy to start with (cf odoo/odoo#224814 disabling it), and apparently #225034 made it mostly but not entirely broken: that PR did manage to pass in [140299] but broke two stagings before that ([140290], [140291]), and then broke the 4 stagings afterwards (one PR got flagged but was apparently an innocent victim). [140299]: https://runbot.odoo.com/runbot/batch/2119196/build/88387072 [140290]: https://runbot.odoo.com/runbot/batch/2119088/build/88383126 [140291]: https://runbot.odoo.com/runbot/batch/2119112/build/88383656
Website editors can now remove a background image from the Floating Blocks snippet without triggering an error. This makes page editing more reliable and avoids interruptions while customizing ecommerce website content.
Original PR description
Steps to reproduce: - Open a website in edit mode - Drag & drop the "Floating Blocks" eCommerce snippet - Remove the background image of the second block - A traceback is raised Cause: The `editingEl` was `undefined` when calling `showMainColorPicker`, leading to an error. Solution: Use `useDomState` to safely compute the value of `showMainColorPicker` based on the current `editingEl`.
Chatbot conversations now keep channel history cleaner by avoiding unwanted blank lines when a message has no content. This prevents confusing or cluttered chat transcripts for users and support teams reviewing conversations.
Original PR description
When a chatbot conversation contains messages with empty body, this empty body would be converted into a newline which is not desired. This commit ensures that empty messages are not converted into newlines in the channel history. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225455 Forward-Port-Of: odoo/odoo#225001
The website builder now shows the right label for the color setting when configuring hover animations, such as displaying “Overlay” for the Zoom Out effect. This reduces confusion for users editing website images and restores expected behavior from the previous builder.
Original PR description
The commit 80b5db99a3c26c3dd4fb5c55e04b8813dddb5b8d brought the options for "on hover" animations into the new website builder. The label for the "Color" option used to change depending on the current effect, and this was lost in the new builder. This commit brings it back Steps to reproduce: - Open website builder - Add an animation "On Hover" (this can be done on images) - Set the "Effect" to "Zoom Out" - Bug: the label for the color is "Color" instead of "Overlay" task-4367641