Monday, September 8, 2025
26 changes · saas-18.4
Resolved issues and error corrections
This update prevents an error when Saudi e-invoicing processes bank address information. It ensures the system uses the right address data source for each record type, improving reliability for affected invoicing workflows.
Original PR description
Issue: Prior to this commit, when the model was res.bank, some fields were not defined on that model, which resulted in a traceback. Fix: Define the way to retrieve the data based on the model. opw-5013477
Website builder previews for header and footer visibility now behave correctly without opening the Invisible Elements panel or triggering unnecessary saves. This makes page editing smoother and reduces confusing interface changes while users test visibility settings.
Original PR description
With the [re-introduction of preview on checkboxes], the visibility option on the footer was made previewable, and this causes issues with the "Invisible Elements" panel and excessive saving. The issues were fixed by skipping updates of "Invisible Elements" panel during previews, and also not setting the dirty flag. These changes are sufficient to make the preview for the visibility option of the header work, so it is enabled as well. Steps to reproduce: - Open website builder - Click on the footer - Hover the checkbox of "Page Visibility" - Bug: the "Invisible Elements" panel appears (and stays) [re-introduction of preview on checkboxes]: 6cc63c31378b8acfdb419727a71f38fd00ea37dd task-4367641
This fixes an issue in the website builder where product variant options could appear at the wrong time when configuring an Add to Cart button. It makes the editor behavior more reliable for users building online shop pages.
Original PR description
### [FIX] html_builder: avoid recomputing item value equal to undefined With initial [website builder refactor], state of `useGetItemValue` is recomputed too often if it is equal to undefined. This commit fixes to comparison to check if the key is in the map. [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 ### [FIX] html_builder: fix add to cart button options With 4e25350bde07ca4267887aa612b538bac0b3c6eb, `useDomState` became async, thus reading it in `getValue` in a dependency definition became incorrect. With this commit, `BuilderMany2One` uses only the synchronous part for the dependency value computation Steps to reproduce: - Open website builder (with website_sale) - Drop the inner snippet "Add to Cart Button" - Choose a "Product" that has variants (for example "Conference Chair") - Bug: the option for the variant is not shown - Remove the choice - Bug: the option for variant now appears task-4367641
A website editor test was adjusted to wait longer when loading image-based options. This reduces random test failures caused by slower network image loading, helping keep the release process more stable.
Original PR description
`test parallax zoom` failed non-deterministically, because it fetches images from the network to render the values in the options. The later tests were not affected because they had the image in cache. The non-determinism is "fixed" by allowing a longer timeout when waiting on the element that should appear. task-4367641
This fixes a website menu display issue where submenus could become invisible when using a dark sidebar header. Menu colors now adapt correctly to the selected theme, helping visitors and editors clearly see navigation items.
Original PR description
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Save the dialog. - Enter edit mode. - Click on the header. - Choose a dark background in the header options. - Choose the "Sidebar" template in the header options. - Open the submenu. - Bug: The submenu is not visible because the background and text have the same light color, so nothing can be seen. The bug was introduced by commit [1], which made visual improvements to the menu. This commit fixes it by making sure the colors of the problematic elements adapt to the theme colors. [1]: https://github.com/odoo/odoo/commit/dc1a15539227c4c21837a7bce3fc4d81858d60b9 opw-5043010 Forward-Port-Of: odoo/odoo#224610
Creating an invoice from a Point of Sale order could fail when the product had no taxes and the customer used Singapore e-invoicing. The fix treats missing tax as zero, allowing the invoice to be created normally and avoiding disruption at checkout reconciliation.
Original PR description
Currently, an error occurs when a user creates the invoice for a POS order. Steps to Reproduce: - Install the `point_of_sale` module. - Start a `Point of Sale session`. - Go to `Products` > create a…
Currently, an error occurs when a user creates the invoice for a POS order. Steps to Reproduce: - Install the `point_of_sale` module. - Start a `Point of Sale session`. - Go to `Products` > create a product without `Sales Taxes and Purchase Taxes`, and in the `Point of Sale` tab, select your `POS session category`. - Go to `Customers` > `create a customer` and In the `Invoicing tab` of the customer, select `Singapore BIS Billing 3.0 SG` in the `eInvoice format` field. - Go to the Point of Sale session and validate an order with the newly created product. - Go back from the session, open the newly created order in Orders and select the newly created customer in the Customer field, and click the `Invoice button`. `AttributeError: 'NoneType' object has no attribute 'amount'` This error occurs after [this commit](https://github.com/odoo/odoo/commit/840bd1832edcc7815b8df70ec52dca10ef978fae), When a user creates an invoice for a POS order, the system calculates the tax_category_code [1], and if the product does not have any type of tax, then an error occurs here [2]. This commit ensures that if the tax is not present, it treats the tax amount as 0 as in [3] and returns the tax_category_code safely. [1]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L432 [2]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_sg.py#L23 [3]- https://github.com/odoo/odoo/blob/9ea122e605366d076a2d6798dce63f1011a579da/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L434-L435 sentry-6814145551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the website editor where pressing Enter inside a tabs image slide description created a new tab/list item instead of a normal line break. This keeps content editing predictable and prevents accidental layout changes for website editors.
Original PR description
Following the [refactoring] of the `html_builder` we had a problem when instead of a new line in the slide description we had a new list item. Steps to reproduce the issue: - Open website and start editing - Drop the .s_tabs_images snippet - Click on any slide description - Press 'Enter' -> It adds a new list item because it treats it as a regular list. Related to task-4367641 [refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Fixed an issue where event pages with non-Latin titles, such as Chinese, could identify the wrong event when editing or registering. This ensures website event links work reliably for international event names.
Original PR description
Issue: The Website Event page uses a matching regex to get the event id from the url. URLs are formatted like: '/event/[event-title]-[event-id]/register' The event-id is recovered from the url by matching on the first number that is not followed by a word character. However, for non-latin event titles (e.g. Chinese), the characters are converted using '%' characters and numbers (e.g. '%E6%88%91%E'). The regex consistently fails to get the event id in this case, and returns incorrect IDs. Steps to reproduce: 1. Install `website_event` and go to the website view of any event. 2. Edit the event, to add a Chinese title 3. Save, and try to edit again the same title. Solution: The regex is modified to look for the first number that is followed by either a "/" or the end of a String. opw-5038334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224164
The ecommerce product page now hides the Buy Now button when zero-priced products are not allowed for sale. This avoids showing customers an action that cannot be completed, creating a clearer shopping experience.
Original PR description
**Steps to reproduce:** 1. Install the `Ecommerce` module. 2. Enable the following settings: * `Settings → Website → Shop - Checkout Process → Buy Now` * `Settings → Website → Shop - Products → Prevent Sale of Zero-Priced Product` 3. Create a product with a selling price of `0`. 4. Open the product page on the website. **Observed behavior:** - Even with `Prevent Sale of Zero-Priced Product` enabled, the `Buy Now` button remains visible on the product page, but clicking it does nothing. **Root cause:** - In `saas-18.4`, there was no condition controlling the visibility of the `Buy Now` button based on the `Prevent Sale of Zero-Priced Product` setting. **Solution:** - Added the `Buy Now` button inside `add_to_cart_wrap` so that it behaves consistently with the `Add to Cart` button which is hidden when the `Prevent Sale of Zero-Priced Products` setting is enabled. opw-4984680
Website editors can now drag and rearrange links inside mega-menus even when the eCommerce app is not installed. This fixes an editing issue that made menu management inconsistent across websites and removes an unnecessary dependency on website_sale.
Original PR description
Before this commit, mega-menus links were draggable only if `website_sale` was installed. This happened because the `dropzone_selector` resource was defined in the `WebsiteSaleMegaMenuOptionPlugin` instead of`MegaMenuOptionPlugin`. This commit moves the `dropzone_selector` resource to `MegaMenuOptionPlugin`, making mega-menus links always draggable, regardless of `website_sale`. How to reproduce the problem: 1. Start Odoo on a database without `website_sale` installed 2. Create a mega-menu (click on navbar element -> Edit Menu -> Create a Mega Menu Item) 3. Open the mega-menu 4. Click on a link in the mega-menu 5. PROBLEM: The link is not draggable (only the column is) 6. Install the `website_sale` app 7. The links are now draggable Task-4367641
Argentina-localized checkout forms now keep a required tax responsibility value available even when it cannot be edited. This prevents an error when customers update their billing address during ecommerce checkout, helping purchases continue smoothly.
Original PR description
Scenario: - setup company with Argentina L10N - do a sale order from partner to Argentinian company and confirm it (to make the vat not editable) - do a checkout from ecommerce from same partner to same company, and at the checkout "address" step, click to edit the billing address - click to confirm the billing address change Result: a "Cannot read properties of undefined (reading 'classList')" error happen in customerAddress._onSaveAddress because the field l10n_ar_afip_responsibility_type_id is missing from the view. Solution: similarly to c10e77ac636243025004d9ebca61af0076691f2b, add the field as hidden if it is readonly. opw-5019253 Forward-Port-Of: odoo/odoo#225579
This change re-enables an automated check for website hover animations after making it more reliable. It helps ensure animation behavior in the website builder is consistently tested, reducing the chance of regressions reaching users.
Original PR description
The test was disabled in f540b0f342d46592099b0d515df1da91fa716a9f because of non-deterministic failures This commit fixes by waiting for the dom state updated signal *after* the operation is over. task-4367641
Users can now enter an ampersand character in filter values without causing the search or domain selector to crash. This prevents errors when applying custom filters and keeps filtering behavior reliable.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281 Forward-Port-Of: odoo/odoo#224664 Forward-Port-Of: odoo/odoo#224567
Installing the online course sales feature no longer fails if the default Services product category was previously deleted. This prevents setup interruptions and lets users continue installing the module in customized Sales configurations.
Original PR description
Currently a `ParseError` arises when the user installs the modules after deleting the `Service` Category in Sales. **Steps to produce:-** - Install `Sales` module (without demo data). - Go to `Sales…
Currently a `ParseError` arises when the user installs the modules after deleting the `Service` Category in Sales.
**Steps to produce:-**
- Install `Sales` module (without demo data).
- Go to `Sales > Configuration > Products > Categories`.
- Delete `Services` category.
- Try to install `website_sale_slides` module.
**Error:-**
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/website_sale_slides/data/product_data.xml:2, somewhere inside <record id='default_product_course' model='product.product'>
<field name='name'>Course Access</field>
<field name='standard_price'>99.99</field>
<field name='list_price'>99.99</field>
<field name='type'>service</field>
<field name='service_tracking'>course</field>
<field name='invoice_policy'>order</field>
<field name='is_published' eval='True'/>
<field name='image_1920' type='base64' file='website_sale_slides/static/img/default_course_product.jpg'/>
<field name='categ_id' ref='product.product_category_services'/>
</record>
```
- The error occurs because the user deleted the category, and then installed the modules, that reference the missing product category.
- This commit resolves the error by providing a False value for the field if the product category is missing.
**sentry-6823596992**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225745
Forward-Port-Of: odoo/odoo#223669Users can no longer create an activity assigned to someone else without linking it to a record. This prevents an access error and makes the activity creation flow clearer and more reliable.
Original PR description
An `AccessError` occurs when a user tries to schedule an activity assigned to another internal user without linking it to a record. **Steps to reproduce**: 1) Install a module 2) Click on the `View…
An `AccessError` occurs when a user tries to schedule an activity assigned to another internal user without linking it to a record. **Steps to reproduce**: 1) Install a module 2) Click on the `View all activities` from activities (Top right corner) 3) Create a new activity without setting a "Link to" record, and assign it to another user. **Issue**: An AccessError will be raised. **Cause**: When the activity has no res_model, the `_action_schedule_activities_personal` method is triggered: https://github.com/odoo/odoo/blob/8e1e4f68763af141c97647fd3e3a2d3a64654a13/addons/mail/wizard/mail_activity_schedule.py#L400-L402 https://github.com/odoo/odoo/blob/8e1e4f68763af141c97647fd3e3a2d3a64654a13/addons/mail/wizard/mail_activity_schedule.py#L415-L424 In this method, both `res_id` and `res_model_id` are passing False, and since `activity_user_id` is not the current user, this leads to an `AccessError` when trying to create the activity. **Solution**: Make res_model required when the assigned user (activity_user_id) is not the current user. opw-5032100 Forward-Port-Of: odoo/odoo#224565
This fix ensures that blank links created in the website builder are removed when a page is saved. It prevents invisible or empty button links from remaining on published pages, keeping website content cleaner for visitors and editors.
Original PR description
The commit f65ac79631180e77aca5a53fc557b3e1acfcbd65 added the class `o_translate-inline` on links created in the website. The link plugin only removes empty links if it has no significant classes or attributes, but that class was not in the list of non-significant classes. Thus, empty links created in website were not removed by the link plugin. This commits patch the link plugin to add that class to its list of non-significant classes.o Steps to reproduce: - Open website builder - Create a new link - Make the link appear as a button to easily see it - Delete its label (but not the link itself) - Save - Bug: the empty link has not been removed task-4975547
Analytic line amounts now use the company's currency precision instead of incorrectly following a foreign currency's rounding settings. This prevents displayed analytic amounts from being rounded too broadly, improving financial accuracy for accounting users.
Original PR description
Steps to reproduce: - set the rounding of a foreign currency to 1.0 - have you company currency's rounding to 0.01 - create a move with a line with an analytic distribution - post it - go to analytic line Issue: The amount will be displayed with a rounding of 1.0 and not 0.01 opw-4997047 Forward-Port-Of: odoo/odoo#225503
Fixes an issue where Spanish Veri*Factu invoice users could not select a required regime key because the dropdown appeared empty. The hidden supporting field is now included in the invoice view so the available choices are calculated correctly, helping users complete compliant invoices without manual workarounds.
Original PR description
### Issue: The dropdown for the regime key doesn't show any value, even when it's supposed to. ### Steps to reproduce: - Install "l10n_es_edi_verifactu" and switch to a Spanish company - Create an invoice for a Spanish partner with the tax "21% G (Goods)" for example - In the page "Veri*factu" the field "Veri*Factu Regime Key" has a dropdown but no values to choose from ### Cause: This field uses the widget `dynamic_selection` which applies a filter on the possible values of the selection. This filter is simply the field `l10n_es_edi_verifactu_available_clave_regimens` which is computed from the list of possible values and the tax_ids on the invoice. As this field is computed and non stored but do not appear in the view, it is never recomputed, so the dropdown shows no values. ### Solution: Add the field in the view, and make it invisible. opw-5039271 Forward-Port-Of: odoo/odoo#225478
Point of Sale now loads updated extra prices for product attribute values configured without creating separate variants. This prevents outdated option pricing from appearing during sales, helping ensure customers are charged the correct amount.
Original PR description
Before this commit, when changing the extra price of a ptav with the no variant creation mode, the updated price was not loaded. After this commit, the updated extra price is correctly loaded. opw-5015868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224772 Forward-Port-Of: odoo/odoo#224091
Invoices for sales between companies now correctly show the related lot and serial numbers when that setting is enabled. This ensures inter-company customers receive the same traceability information as other customers, improving invoice accuracy and compliance with tracking processes.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223455 Forward-Port-Of: odoo/odoo#222492
Fixes an error that could prevent users from enabling the Calendar view in Studio for Employees. The system now avoids unsuitable date fields when automatically creating calendar views, improving reliability without changing user workflows.
Original PR description
**Steps to reproduce:** - Install `hr` and `web_studio` - Go to Employees → click Studio icon. - Click on Views → try to activate Calendar view. **Observation:** - You will get a traceback…
**Steps to reproduce:** - Install `hr` and `web_studio` - Go to Employees → click Studio icon. - Click on Views → try to activate Calendar view. **Observation:** - You will get a traceback `ValueError: Cannot convert hr.version.date_end to SQL because it is not stored ` **Issue:** - Since saas-18.4, the `hr_version` model introduced `date_start` and `date_end` fields, which are non-stored computed fields. https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/addons/hr/models/hr_version.py#L139-L140 - These field names overlap with the default date field names (`date_start` and `date_end`) used when generating Calendar views. So, the Calendar view tried to use a non-stored field, and it caused the error. https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/odoo/addons/base/models/ir_ui_view.py#L2591-L2630 **Solution:** - Add an extra check in `set_first_of` to ensure that only stored fields are considered when selecting the default date field for Calendar views. opw-4967654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event registrations created from Point of Sale now correctly keep the company name entered during ticket purchase. This prevents missing company details in the backend and helps staff maintain accurate attendee records.
Original PR description
Steps to reproduce: 1. Add a question to an event with type 'Company'. 2. Sell a ticket for that event in a POS, making sure to fill in the company question. 3. Validate the sale 4. In the backend, check the new event registration that was created. EXPECTED: The company name you filled in is saved to the registration. ACTUAL: The company name is blank. There were three things that needed to be fixed in order for the company name to work: 1. Use `company_name` instead of `company` on the JS side 2. Add `company_name` to the list of loaded POS fields 3. Tell the POS that `company_name` is not computed (this was already being done for name, email, phone) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225699 Forward-Port-Of: odoo/odoo#225534
This fix ensures that when the same contact is linked to employees in different companies, a vehicle is assigned to the employee from the vehicle's company. It prevents incorrect driver records in fleet vehicles and assignment logs for multi-company setups.
Original PR description
There is a bug when multiple employees from different companies are linked to the same contact. Steps to reproduce: - Create two employees, in two different companies that relate to the same contact (partner) - In one of the two companies, create a vehicle and assign it to the partner created - The field driver_employee_id in the vehicle and assignation log will be assigned to one of the two employees, without taking care of the company of the car To fix this, the domain should also contain the company of the car, and must match the company of the employee. task-4978443 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#221154
This fix adds a log warning when automatic bank statement reconciliation is started with a time limit but no batch size, a setup that previously caused the time limit to be ignored. This helps administrators detect misconfiguration that could make large bank statement imports run longer than expected.
Original PR description
When calling `_cron_try_auto_reconcile_statement_lines` with a limit_time argument but without a `batch_size`, the time limit was silently ignored. With this commit, we display a warning in the logs, because this is probably not the desired behavior. Besides that, when the amount of statement lines become large, it might hang the import of bank statements longer than the expected 3 minutes. Task-id: None Forward-Port-Of: odoo/enterprise#93565
Disabled Urban Piper delivery providers now remain disabled when a point of sale session is resumed. This prevents unwanted provider reactivation and avoids unnecessary update requests, helping staff continue selling with the correct delivery setup.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969 Forward-Port-Of: odoo/enterprise#93119 Forward-Port-Of: odoo/enterprise#90987