Tuesday, August 26, 2025
9 changes · saas-18.4
Enhancements to existing features
The website builder now preserves customization options when users switch between sidebar tabs or when certain saved changes reload the builder. This reduces repeated selections and makes editing pages smoother and less disruptive.
Original PR description
This PR introduces two changes. 1. In the website builder, when the user clicks on some element of the website, it opens several customize options in the "Customize" tab of the sidebar. Previously,…
This PR introduces two changes. 1. In the website builder, when the user clicks on some element of the website, it opens several customize options in the "Customize" tab of the sidebar. Previously, if the user switched to either the "Block" tab or the "Theme" tab, once he would come back to the "Customize" tab, all the options would be gone. This commit changes this behavior by keeping the options enabled. This allows to avoid to have to reselect snippets in order to see the desired customize options after switching to another tab. 2. Some actions are automatically saved and trigger a reload of the builder. When this happens, we want to keep as many options as possible open in the "Customize Tab". This can only be done with option containers associated with a selector only matching one element on the page. TODO: remaining selectors to check: - .o_record_cover_container - .o_facebook_page - .listing_layout_switcher - .o_mega_menu - .o_wblog_post_page_cover[data-res-model='blog.post'] - .o_wcrm_filters_top - .o_wsale_product_images task-3103768
This update improves electronic invoice validation and data generation so invoices better meet local PINT requirements in Australia, New Zealand, Malaysia, and Singapore. It helps prevent invoices with missing tax or address information from being sent in a format that authorities or recipients may reject.
Original PR description
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain…
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain rules (e.g. the tax totals of tax category code 'O' should have amount of zero, but current code can set this value to something other than zero). The change focuses on edge cases when VAT of partner is not set. Changes are not related to the Q2 2025 release changes. - MY: Added fallback for <cac:PartyTaxScheme> to always have <cbc:CompanyID>. Currently breaks if the partner does not have VAT set. Changes are not related to the Q2 2025 release changes. - JP: No changes are made. - SG: Invoice with taxes of certain tax category codes must have seller and buyer street address and post code. Added constraint to make sure they are set. New PINT SG rule adds one more tax category code (Standard Rate, SRRC). New code is added to `ubl_cii_tax_category_code` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222737
Xendit payment forms now report token creation errors immediately, such as invalid card or payment details. This prevents incorrect data from continuing through the payment process and gives users faster feedback when something needs to be corrected.
Original PR description
Previously, if error was found during token creation (i.e. invalid input) , it's not immediately reported but instead invalid data will be used for further process. Now, any errors caught early will be reported immediately back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224036
Resolved issues and error corrections
Restricted website editors can now save allowed website content without triggering an access-rights pop-up caused by hidden technical page elements. The change ensures only full website editors can edit underlying website templates, reducing confusion while preserving access limits.
Original PR description
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival"…
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival" - user is able to edits is footer contents,make a change - try to save. Observation: A pop-up for access right appears Cause: after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , we allow website to be editable for restricted user if, user can modify other models, which are editable from website,like event. And, if website is editable, we brand the ir.ui.views nodes, https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94 but restricted user do not have access to ir.ui.view model, causing access issue Note: if a node is branded, that means it is editable Fix: Brand ir.ui.view nodes only if user has full access to website editor opw-4659114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224038 Forward-Port-Of: odoo/odoo#221202
Saudi electronic invoicing no longer blocks invoices when a branch company differs from the journal company. This helps businesses using branch structures generate the correct QR code for the appropriate company while staying aligned with invoicing requirements.
Original PR description
This commit removes the previously enforced restriction in https://github.com/odoo/odoo/commit/d6175d0552c18006913e969eac7006666164609c that required the company specified on an invoice to match the company specified on the associated journal and makes sure that the company used to create the QR is the appropriate company whether in a branch or in a main company task-5005477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224024 Forward-Port-Of: odoo/odoo#222935
Customers using Click & Collect can now request a notification when an item becomes available again directly from checkout. This helps avoid lost sales when products go out of stock after they were added to the cart.
Original PR description
## Versions 18.4+ to limit templates impact. ## Issue Users can't choose to be notified when a product becomes available again on the checkout page. ## Steps to reproduce Ensure eCommerce website is…
## Versions
18.4+ to limit templates impact.
## Issue
Users can't choose to be notified when a product becomes available again on the checkout page.
## Steps to reproduce
Ensure eCommerce website is set up with a shop;
- In Settings app:
- Enable "Click & Collect" and click "Configure Pickup Locations":
- Add a company as a warehouse and publish the "Pick up in store" location;
- In Sales app:
- Create a product with the following attributes:
- Name: A;
- Product Type: Goods;
- Track Inventory: enabled;
- Sales: enabled;
- Under Sales tab:
- Out-of-Stock (Continue Selling): disabled;
- On Hand: 1.
- Click "Go to Website":
- Add 1 to cart then go to cart;
- Click the "Checkout" button;
- Under "Choose a delivery method", select "Pick up in store" then "Select a Location";
- Choose a location.
- (In another browser tab) Go to the product's page:
- Set "On Hand" quantity to 0.
- (Back in the checkout tab) Refresh the page:
- The product appears as unavailable under the pick-up location:
- No option is available to request a back-in-stock notification.
## Solution
Apply `website_sale_stock` logic
https://github.com/odoo/odoo/blob/7bc57a49e5bf9061cfb66e179075538cd17bfd2f/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L1-L61 as in `website_sale_stock_wishlist`
https://github.com/odoo/odoo/blob/7bc57a49e5bf9061cfb66e179075538cd17bfd2f/addons/website_sale_stock_wishlist/views/website_sale_stock_wishlist_templates.xml#L7-L45
opw-4979335This fixes cases where dropdown select menus did not receive focus, especially when opened empty or reopened in website, forum, and builder flows. Users can now interact with tag and choice selectors more reliably, improving form usability and reducing friction.
Original PR description
…n later opens in some case tests of interests: - `autofocus in select menu` (there are 2 of them, one in website, one in html_builder) - `Selecting a choice calls onSelect and the displayed value is updated` (in web) - `http://localhost:8069/forum/help-1/ask` (there is the select menu for the tags at the bottom) There is the select menu for tags in the 'new question' page in forum, it never focus the selectmenu in tests with setupHTMLBuilder never focus the selectmenu in tests with setupWebsiteBuilder and the one in web/core only does not focus on first open 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
Fixes an issue where adjusting the checkout time from the weekly Attendance view could accidentally save the current time instead of the selected time. This helps prevent incorrect attendance records when managers or employees edit attendance entries.
Original PR description
Steps to Produce: - Go to the Attendance interface and select week. - Drag the second half of the column to adjust checkout. - Save the change. Issue: - Dragging on half cell deletes the checkout value from the context. - As a result, the system sets the checkout time to the current time instead of the dragged value. - This leads to incorrect attendance records. Fix: - Ensure the checkout value remains in the context when dragging the cell. - Preserve the modified checkout time so it reflects the user's intended change instead of defaulting to the current time. Task-4958060 Forward-Port-Of: odoo/enterprise#91119
This fixes an issue that prevented multiple connected cameras from being used at the same time in Quality IoT setups. Cameras are now identified uniquely and existing camera configurations are preserved, while a related communication error over the websocket is also prevented.
Original PR description
Due to an issue with the `CameraInterface`, the same identifier would be chosen for any connected camera (`camera-2`), meaning only one camera could be used at once. To fix this, the `camera.id`…
Due to an issue with the `CameraInterface`, the same identifier would be chosen for any connected camera (`camera-2`), meaning only one camera could be used at once. To fix this, the `camera.id` property is used as the identifier instead. The `libcamera` documentation says the following: > The camera ID is a free-form string that identifies a camera in the > system. IDs are guaranteed to be unique and stable: the same camera, > when connected to the system in the same way > (e.g. in the same USB port), will have the same ID across both > unplug/replug and system reboots. However, we will also still return the last camera with the `camera-2` identifier, so that existing device configurations in the backend don't get lost. In master we will remove this legacy identifier. You can see the legacy camera with the others in the list below: <img width="801" height="385" alt="image" src="https://github.com/user-attachments/assets/6f3a6408-bcb4-46b0-980e-b5a8881f6df0" /> In addition, another small fix was made to the `CameraDriver` to ensure a string is sent rather than raw bytes, this prevents a traceback when communicating over the websocket. task-4792552 Forward-Port-Of: odoo/enterprise#93076