Monday, July 28, 2025
25 changes · 18.0
Enhancements to existing features
Odoo now keeps database time aligned with simulated application time during tests. This helps make time-based test results more realistic and reliable without affecting normal production use.
Original PR description
[IMP] sql_db: replace now to reflect the time offset When using the faketime lib to test Odoo, only the Odoo processes are affected, so it does not reproduce the reality. With this commit, when an environment variable `ODOO_FAKETIME_MODE` is set, the cursor `now` function is altered the same way faketime alters the Odoo processes. See https://github.com/wolfcw/libfaketime Forward-Port-Of: odoo/odoo#220632 Forward-Port-Of: odoo/odoo#219671
Resolved issues and error corrections
This fixes an issue where mail thread access and existence information could be left out when a request was present but empty. Users and connected features now receive the expected thread access status consistently, reducing confusion and preventing missing information in mail-related workflows.
Original PR description
Even if the request is an empty array, access (and existence of thread) should be sent. How to reproduce: https://github.com/odoo/odoo/pull/220605
Documentation and clarification updates
Nanas Systems Sdn. Bhd. has added its signed Contributor License Agreement. This legal update confirms the company can contribute to Odoo under the project’s contribution terms.
Original PR description
Description of the issue/feature this PR addresses: Signing of CLA by Nanas Systems Current behavior before PR: CLA has not signed Desired behavior after PR is merged: Nanas Systems signed CLA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix moves the affected employee candidate test coverage into the recruitment area where the required candidate functionality is available. It helps prevent nightly build failures caused by tests running without the needed recruitment setup.
Original PR description
Problem: ======== - Nightly build hr.candidate is not installed Solution: ========= - Change test and tour inside hr_recruitment runbot-230304
This fix prevents an error when a website editor changes a button snippet into a regular link and then saves. The editor now correctly hides button-specific options once the item is no longer a button, reducing failed saves and improving content editing reliability.
Original PR description
Problem: Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`. Cause: The button snippet editor should be disabled if the button is changed…
Problem: Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`. Cause: The button snippet editor should be disabled if the button is changed to a link. However, `updateOptionsUIVisibility` is only triggered on click events. In this case, the element type changes through the editor itself, not by clicking, so the UI isn't updated accordingly. Solution: Trigger a `click` event on the link element programmatically to call `updateOptionsUIVisibility` and hide the button snippet editor when the element is no longer a button. Steps to reproduce: - Drop a button snippet - Click inside the button to edit - Notice the Button snippet editor appears - Change the type to "Link" instead of "Primary" - The Button snippet editor is still visible - Click the floppy disk icon (save) in the snippet editor -> A traceback occurs opw-4936796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219660
Event registrations purchased and paid for through Point of Sale are now marked as Registered instead of Attended. This aligns PoS behavior with website purchases and avoids incorrectly recording customers as having already attended the event.
Original PR description
Before this commit, if we buy an event registration from PoS and pay for it, its state will be 'done', i.e. "Attended" [1]. While if we buy the registration from the website and pay for it, its state is 'open', i.e. "Registered" [2]. We want the state of the registration to be 'open' when we buy it. After this commit, we set the state of events bought from PoS to 'open' as well, matching the case where we buy them from the website. [1]: https://github.com/odoo/odoo/blob/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9/addons/pos_event_sale/models/event_registration.py#L14 [2]: https://github.com/odoo/odoo/blob/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9/addons/event_sale/models/event_registration.py#L40 opw-4920574
Fixed a typo in the Peru localization data where Huancayo was incorrectly written with an extra space. This helps ensure city names appear correctly in addresses, reports, and related business records.
Original PR description
The Huancayo has an extra space in the name. Instead of Huancayo it is written Hua ncayo in the csv file. opw-4947526 Forward-Port-Of: odoo/odoo#219888
Users who have permission to manage pricelists can now archive them even if they do not have access to loyalty programs. This removes an unnecessary access-rights blockage and keeps pricelist administration working as expected.
Original PR description
Finetuning of d20b6f6407f49f9bff8cf3677b2fe07cb3588298, if a user had access rights on the pricelist model but not on loyalty programs, he wouldn't be able to archive a given pricelist. Has already been fixed in the aforementionned commit forward-port, starting from 18.2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220608
This fixes an issue where the mail discussion system could ignore records when there were no field values to return. Users and processes can now still detect that a record exists, improving reliability in cases where record presence matters.
Original PR description
Knowing the existence of a record can be desirable, even if no fields need to be returned. How to reproduce: https://github.com/odoo/odoo/pull/220605
Point of Sale session closing messages now show cash differences with the correct number of currency decimal places. This avoids confusing long decimal values in the session chatter and makes cash reconciliation clearer for store staff.
Original PR description
**Issue:** When closing a PoS session with negative balances, the closing difference is displayed in the chatter box with an excessive number of decimal digits. **Steps to Reproduce:** 1. Install the…
**Issue:** When closing a PoS session with negative balances, the closing difference is displayed in the chatter box with an excessive number of decimal digits. **Steps to Reproduce:** 1. Install the Point of Sale app. 2. Navigate to Point of Sale > Open a new session. 3. Set the Opening Cash to 496.45. 4. Add a product priced at 65.86 to an order. 5. Confirm the payment via Payment > Cash > Validate. 6. Close the session and set Counted Cash to 560.40. 7. Navigate to Orders > Sessions. 8. Open the last closed session. 9. Observe that the closing difference is displayed with more than two decimal digits. Expected Behavior: The closing difference should be rounded to two decimal places for clarity. Actual Behavior: The closing difference is displayed with excessive decimal digits. **Root Cause** Floating-point arithmetic in Python causes small precision errors when performing calculations involving monetary values. Since Odoo's Monetary fields are based on float types, operations such as balance calculations retain unnecessary decimal places instead of rounding them correctly to two digits. **Fix** To prevent this from happening, at the moment of crafting the message to display on the chatter, it is explicitly requested to only show two decimal digits of the rounded closing difference. Opw-4483487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199082
This fix prevents an error from appearing when a user leaves a Discuss call before responding to a camera access request. It improves call reliability by safely handling delayed camera permission responses, especially when access is denied.
Original PR description
Before this commit, a traceback would occur of the camera access was rejected after leaving a call that requested it. This race condition could also happen in other cases where the call is left before the camera promise resolves.
This fix prevents an error when creating an Analytic Distribution in a multi-company setup where one company has no fiscal localization configured. Users can now open and create Analytic Distribution records without the screen crashing in this scenario.
Original PR description
Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`. Steps to…
Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`. Steps to reproduce: --- - Install `Accounting` module(without demo) - Enable `Analytic Accounting` - Create a New company and switch to it - Select both companies and Open `Analytic Distribution` and click `New` Traceback: --- `TypeError: 'bool' object is not subscriptable` At [1], we are searching by `account_type`, but if `Fiscal Localization` is not set for the current company, there will be no records in `account.account`. However, due to the multi-company setup, it still return accounts from the first company. In such cases, the `code` field is empty, which causes the `code` to be treated as False. [1]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/account/models/account_analytic_distribution_model.py#L55-L58 sentry-6754820454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps promotional ribbons correctly attached to product images on eCommerce product pages when customers zoom in or out. It prevents a broken-looking layout and helps maintain a polished shopping experience.
Original PR description
<b>Steps to Reproduce:</b> 1. Install Sales and eCommerce modules. 2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon. 3. Navigate to Website → Shop, search for the…
<b>Steps to Reproduce:</b> 1. Install Sales and eCommerce modules. 2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon. 3. Navigate to Website → Shop, search for the product and open its page. 4. Zoom in or out. <b>Issue:</b> - The ribbon on the product image becomes misaligned (shifts away from the image) when zooming in or out on the product detail page. This results in a broken visual layout. <b>Cause:</b> - A previous change in [PR #175473](https://github.com/odoo/odoo/pull/175473) unintentionally replaced the height class (h-100) with width (w-100) on ribbon container, causing layout instability during zoom operations. <b>Solution:</b> - Restore the proper layout by reintroducing h-100 to both the ribbon container and inner image div. This ensures the ribbon stays correctly positioned relative to the image regardless of zoom level. <b>opw-4854217</b> <b>Before FIX :</b>  <b>After FIX:</b> 
This change corrects a company-specific payment account used in an automated course certification test. It helps ensure the test reflects the right company setup and avoids false build failures unrelated to customer-facing behavior.
Original PR description
Steps to reproduce:- - Install `account` module. - Invoicing > Configuration > Payment Providers - Install `Demo` payment provider, check state `Test Mode` and is `Published`. - Run `test_course_certification_employee` test case. Error: “Draft Payment” belongs to company “company_1_data” and “Outstanding Account” (outstanding_account_id: 'Outstanding Receipts') belongs to another company. Cause:- - When `Demo` provider is activated, `account.payment.method.line` is created with `payment_account_id` of company `YourCompany`, but that account was not changed in the test. Solution: In `test_course_certification_employee` test, set outstanding account of company `company_1_data` for `account.payment.method.line` with code `Demo`. Runbot Build Error-229953
Fixes a printing issue where long reception reports could show product rows overlapping section headers on later PDF pages. This makes multi-page reception reports easier to read and more reliable for warehouse and purchasing teams.
Original PR description
## Short functional explanation of the error When printing a reception report containing a lot of products, the top row of the pages after the first one is overlapped with its corresponding header in…
## Short functional explanation of the error When printing a reception report containing a lot of products, the top row of the pages after the first one is overlapped with its corresponding header in the resulting PDF. ## Reproduction Steps 1. Open the settings. In the inventory section, enable "Reception Report". 2. Create a new quotation and add at least 40 different products. Each product should have at least 1 copy in stock, and the quantity to order must be greater than the quantity we have of this product in stock. 3. Confirm the sales order. 4. Create a new purchase order and add the exact same products you added in the quotation. 5. Confirm the order and click on the "Recept" smart button. 6. Click on the "Allocation" smart button and click on the "Assign all" gray button. 7. Click on print and open the PDF once it finishes downloading. ### Expected behavior Each row (corresponding to the reception of a product) and its corresponding header is printed properly, regardless of how many pages constitute the report. ### Unexpected behavior The PDF has more than one page, and on the top of the second page, the product row is overlapped with the header of its corresponding section. ## Origin of the issue It comes from an issue with WKHtmltopdf itself: https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1524 The report uses the "thead" tag for the headers. However, in some cases, when the header is linked to a table dynamically (with for-each, for example), WebKit ignores or breaks the "Thead" behavior. ## Explanation of the fix I override the default behavior of thead, which repeats the header automatically at each new page, with a new style. Now, the "Thead" special behavior is ignored and treated like ordinary lines. The header isn't shown at each new page anymore, avoiding the overlapping of product rows. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215398
Fixes an issue in the website editor where moving the final item from one table of contents block into another could cause an error. This makes page editing smoother and prevents interruptions when reorganizing content blocks.
Original PR description
Since [1], a traceback appears when we drag the last block of a table of content into another one. Drag and drop two tables of content on the website page One by one, drag and drop the blocks from the second table to the first one traceback for the last one... This commit resolves the issue [1]:https://github.com/odoo/odoo/commit/6cd9606e285741b59042b9674bf6682273c43a69 task-4144022 Forward-Port-Of: odoo/odoo#180039
Employee presence now shows the correct work location name immediately when today's planned work location is changed. This prevents the location from appearing as unspecified before the employee record is saved, improving clarity for managers and HR users.
Original PR description
Step to reproduce:
------------------
* Go on Employees
* Click on one Employee
* Change a today worklocation "office" (don't save, you need to have the little cloud)
* Hover over hr presence icon
This title will be "unspecified" and not "office".
Reason:
--------
name_work_location_display is computed but doesn't depends of daily worklocation field (monday_worklocation, tuesday...)
Solution:
---------
Depends of these daily worklocation field
task-4948488
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#219222Italian point-of-sale credit card payments now use a default value that fiscal printers recognize as paid. This prevents valid card payments from being incorrectly recorded as not paid, reducing reporting errors for Italian retailers.
Original PR description
In Italy if a payment method is of type 'Credit card' (type 2), and it's index is 0 the payment made with it is considered as 'Not paid' by the italian fiscal printer. Why the fix: ------------ We change the default index of the payment method to 1, so that it is considered as 'Paid' by the fiscal printer. opw-4963421
Starshipit delivery requests now include the second address line when it is provided. This helps carriers receive complete customer addresses, reducing the risk of delivery errors or manual corrections.
Original PR description
Current behaviour: --- When using Starshipit, street2 is not included in the payload sent to the API. Expected behaviour: --- Street and Street2 should be both included if street2 is set, separated by a space. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method 3. Create an Australian partner 4. Make sure street2 is set 5. Make a new sale order 6. Set the Australian partner 7. Set a product and click on "Add shipping" 8. Set starshipit as the method to use 9. Confirm and validate the delivery 10. Only the first street is sent opw-4907475 Forward-Port-Of: odoo/enterprise#89725
The optional columns menu in bank statement line views no longer shows the “Add custom field” button where it should not be available. This prevents users from attempting unsupported customizations in the bank reconciliation workflow.
Original PR description
`Add custom field` button shouldn't be displayed with `account.bank.statement.line` model. Since c6ade2de937a30a13620a64a4779ebd827088755, we use an action to open the bank reconciliation widget, therefore in the `computeStudioEditable` method, we didn't pass in the first condition `!action.xml_id` anymore and we were returning `true`. With this commit, we return `false` if model is `account.bank.statement.line`. Steps: - Install `accountant` - Go to Accounting dashboard - Click on the `Bank` card title - Toggle the list view - Open the optional columns dropdown -> The `Add custome field` button is displayed opw-4953156
The bank reconciliation list view no longer shows the option to add a custom field. This keeps the screen consistent with Studio being disabled there and prevents users from seeing an action that should not be available.
Original PR description
On the bank matching screen (reconciliation), display the list view. Before this commit, the "Add custom field" button was present in the optional fields dropdown After this commit, it is not anymore because Studio had already been disabled on that view with https://github.com/odoo/enterprise/pull/89146 This commit is a complement to https://github.com/odoo/enterprise/pull/89146 opw-4970587
This change makes an internal tax report test run in a way that better prepares required web assets and avoids random request conflicts. It helps developers get more consistent test results, reducing false failures during maintenance without changing customer-facing behavior.
Original PR description
This test could fail locally when assets are not up to date, or when using faketime. This is mostly because assets are not pregenerated if no http case is run. It can also fail randomly because http requests are not serialized. Forward-Port-Of: odoo/enterprise#90520
This update records that contributor waltonparkman has signed the individual Contributor License Agreement. It supports clear legal ownership and compliance for future contributions to the project.
Original PR description
Adds CLA for waltonparkman
A contributor has added their individual Contributor License Agreement to meet Odoo's contribution requirements. This is an administrative legal update that enables their contributions to be accepted under the project's licensing process.
Original PR description
This pull request adds my individual Contributor License Agreement (CLA) as required by the Odoo contribution guidelines. The file follows the structure described in doc/cla/sign-cla.md.
Luca Policastro's Contributor License Agreement for Camptocamp has been recorded. This supports Odoo's contribution process by confirming the legal permissions needed for future contributions.
Original PR description
This pull request adds my Contributor License Agreement (CLA) as required by the Odoo contribution guidelines for Camptocamp company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr