Daily updates from Odoo
Wednesday, November 12, 2025
27 changes · saas-18.3
Enhancements to existing features
This change speeds up how Odoo calculates invoice and journal entry amounts, especially when there are many lines to process. It reduces waiting time and memory usage, which makes large accounting operations noticeably faster and more efficient.
Original PR description
Currently performance on `_compute_amount()` is bottlenecked by `__get__()` calls on fields on `line_ids`. We tackle this bottleneck by warming the cache with `fetch()` Benchmark on reconciling 2 account moves with ~70k lines each | |Total Time|Allocated Memory|Queries| |----------|----------|----------------|-------| |Before |43.23s |2GB |993 | |After |18.60s |1GB |693 | opw-5098543 Forward-Port-Of: odoo/odoo#234656
The point-of-sale opening flow no longer checks whether blackbox drivers are up to date. This streamlines session start, while outdated drivers will still trigger an error when a blackbox feature is actually used, so users are protected without an extra startup step.
Original PR description
When introducing the blackbox queue service, we added a check at the opening of the POS to ensure that the blackbox drivers were up to date. This check is done at the start of session opening. It is now not necessary anymore, if the drivers are not up to date, an error will also be shown to the user when they try to use a blackbox functionality.
This update adds a simpler way to select elements by their exact text in Hoot test selectors. It replaces a more complex matching pattern with a clearer option, making tests easier to read and maintain without changing business behavior.
Original PR description
This commit adds the ':text()' pseudo-class to the list of supported pseudo-classes in Hoot selectors. Its purpose is the same as ':contains()', with the specificity of being an *exact* match instead of a *partial* one. It effectively replaces ':contains(/^<expression>$/)' by ':text(<expression>)', improving the readability and making the developer experience a bit nicer. Enterprise: https://github.com/odoo/enterprise/pull/98772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234989 Forward-Port-Of: odoo/odoo#234331
This update switches some internal test checks to a more precise text-matching method. It helps keep automated tests stable and reduces the chance of false matches when checking on-screen text.
Original PR description
This commit replaces all found occurrences where ':contains' (with an exact match regular expression) could be replaced by ':text'. Community: https://github.com/odoo/odoo/pull/234331 Forward-Port-Of: odoo/enterprise#99130 Forward-Port-Of: odoo/enterprise#98772
The point of sale now shows clear error messages when the fiscal device is disconnected or when the social security number is missing. It also tells users what to do next, which should reduce confusion and help staff resolve issues faster.
Original PR description
We now display an error when the FDM is disconnected, or when the user needs to fill in the social security number. We also advise what to do in such cases.
Resolved issues and error corrections
Users will now see inbox messages directly in the top messaging menu, including notifications like signature requests that were previously hidden there. This makes important messages easier to find and reduces confusion when a notification badge was shown but the message itself was not visible.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228740
This update corrects how date and work-time intervals are combined so the system always normalizes them before merging. It prevents inconsistent results and errors in planning-related operations, improving reliability when different interval types are used together.
Original PR description
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`.…
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#234352
Livechat on mobile devices now keeps the message input at a size that prevents the browser from zooming in when it is tapped. This keeps the send button visible and makes it easier for visitors to chat without having to pinch back out.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#235150 Forward-Port-Of: odoo/odoo#234967
When a pivot table with date or date-time columns was inserted into a spreadsheet, its sort order could be lost. This fix keeps the original date-based sorting so spreadsheet pivots display in the expected order.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#96508
This change fixes an issue where installing the Argentina withholding demo data created duplicate tax records. As a result, users will now see a clean, single set of taxes instead of repeated entries with copy labels.
Original PR description
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo…
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo data. 2. Take position in "(AR) Responsable Inscripto" company. 3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 4. Delete the filter "Sale or Purchase". 5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"]. 6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). **Current behavior before PR**: Duplicated taxes are created when demo data is installed. <img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" /> **Desired behavior after PR is merged**: No duplicated taxes are created when demo data is installed. _Task latam side_: 1360. _Task Adhoc side_: 57627. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226992
This update adjusts an automated purchase test so it works correctly with PostgreSQL 18. It prevents the test suite from failing due to a database error code change, helping maintain reliable validation in ongoing development and releases.
Original PR description
Apparently in pg18 a standard-compliance fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted…
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.
Forward-Port-Of: odoo/odoo#235119The dashboard upload button can no longer be moved by dragging it. This keeps the interface stable and avoids accidental changes to the button’s position while users work.
Original PR description
Issue: - In the dashboard, the upload button (purchase journal and others) could be dragged. - This caused unintended movement of the upload UI element. Fix: - Added `draggable=false` to the upload button element. - Ensures the button remains fixed and cannot be dragged around. TaskID-5114617 Forward-Port-Of: odoo/odoo#235086 Forward-Port-Of: odoo/odoo#229013
This update fixes Swiss ISO 20022 payment files so banks receive the expected XML structure again. The change only forces SEPA-specific nodes when an explicit configuration is enabled, which helps avoid bank rejections caused by mixed or unsupported file formats.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99005 Forward-Port-Of: odoo/enterprise#98918
This update fixes two issues on the careers page. Visitors who are not logged in will now be redirected to the correct country more reliably, and job opening counts will display correctly even when grouped by different office or location fields.
Original PR description
This commit fixes 2 bugs: When you are not logged in and geolocalized, we don't redirect the visitor to the right country because the visitor cannot read hr.job, so the count will always be 0. Now we use sudo to have the count whether you are logged in or not. Another bug is in compute_filter_selection_counters: in case you provide a key_getter that is not the same as the grouping_field, when we count, we only keep the last count in case of duplicates. Eg, if you group by address_id and count the address_id.country_id, you will get the count of hr.job open in the last office you iterate over.
This update prevents the website editor from crashing when someone presses Delete without an active text selection. It improves stability during normal editing so users can remove content without triggering an error message.
Original PR description
If the selection of the document is not set and the user presses the delete key, the delete handler of the list plugin throws an error. Steps to reproduce (in 19.0, where the issue was discovered): - Open website builder - Drop the video inner snippet in the header - Double-click & drag from the video to just outside the video - Click once on the video - Press "delete" - Bug: Traceback task-5186954
The website now uses the same tax display rules in its structured data as it does on the page itself. This keeps the price shown to search engines consistent with the price customers see, especially when the website is configured to show taxes included.
Original PR description
## Version
18.2+
SEO Schema refactoring from task-3866937
## Issue
The markup always contains the price without taxes, no matter the website settings for pricing display (with or without taxes).
## Steps to reproduce
- Go to Website settings:
- Choose "Taxes Included" for "Display Product Prices".
- Got to the shop and select any product on which taxes apply (e.g. Customizable Desk):
- Open console and execute `JSON.parse(document.querySelectorAll('[type="application/ld+json"]')[1].innerHTML)[0]['hasVariant'][0]['offers']['price']`;
- The found price and the displayed price (visible on the page) are different
## Fix
Allow tax inclusion based on parameter to mimic template's behavior on variants too depending on the website.
https://github.com/odoo/odoo/blob/52a6d88a188d5456262428847aed229f117da8ed/addons/website_sale/models/product_template.py#L377-L430
opw-4923780
Forward-Port-Of: odoo/odoo#225577This fix prevents a table placed inside another table from growing beyond its parent cell when resized. As a result, nested tables remain visible and editable, avoiding a frustrating editing issue for users.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
The website SEO optimization dialog now waits for the page preview to finish loading before opening. This prevents occasional crashes when users open the dialog immediately after reloading a page on a slow connection.
Original PR description
Steps to reproduce: - Open Website app and enter edit mode on any page. - Reload the page with a slow connection. - Immediately open "Optimize SEO" from the navbar menu. Before this commit, the dialog accessed the preview document while the iframe was reloading, so reading location.origin raised a TypeError. After this commit, the dialog waits for the iframe to finish loading or returns immediately when it is already complete, preventing crashes. task-5104033 Forward-Port-Of: odoo/odoo#230820
This change resolves an error that could occur in Odoo Studio during automated testing. It helps ensure Studio behaves reliably and avoids interruptions in validation workflows.
Original PR description
Forward-Port-Of: odoo/enterprise#98881
This fix prevents the point of sale from raising an error when a pro forma request finishes after the related order has already been deleted. It checks that the order still exists before using it, which avoids interruptions for users and keeps the flow stable.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback.
The website editor now correctly displays overlay borders and snippet options when the site uses a right-to-left language such as Arabic. This prevents the editing tools from appearing misplaced or hidden, improving the experience for teams managing multilingual websites.
Original PR description
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are…
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are not in the correct place 4. Open the snippet dialog => The snippets are not visible. __Cause__: Since [this commit][1], `lang` in `session.bundle_params` is (correctly) set to the `request.lang.code`. Consequently, `website.assets_all_wysiwyg_inside` is fetched with the frontend language code in the `searchParams` which shouldn't be the case especially if the website language direction is not the same as the backend one. __Description of the fix:__ The `getBundle` method from outside the iframe is used instead of the frontend one to retrieve the URL of the bundle that matches the language direction of the builder. Backport and adapt the test from [this commit][2]. [1]: https://github.com/odoo/odoo/commit/e10852a45f10c55a833c33a51956e5f [2]: https://github.com/odoo/odoo/commit/7bcd56c07852b77849b05184200c48a task-5246916 opw-5214703 Forward-Port-Of: odoo/odoo#234991 Forward-Port-Of: odoo/odoo#234782
This fix stops event ticket products from being changed into a product setup that breaks online registration and checkout. It ensures tickets keep the right tracking rules, so customers can register for events and complete payment without errors.
Original PR description
Steps ----- 1. Have `sale_renting` but not `sale_stock_renting` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- > AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- By making it a rental product, it creates a rental order, but as registering for an event via website doesn't have any way to add rental dates, rental lines cannot be processed & rendered as expected. Solution -------- Prevent users from changing the `service_tracking` away from `'event'` by adding an `api.constrains` to `product.product` on `service_tracking` and `event_ticket_ids`. opw-5207045 Forward-Port-Of: odoo/odoo#234705
This update removes leftover unused code from the reconciliation model after a previous redesign. It does not change how users work, but it keeps the codebase cleaner and easier to maintain.
Original PR description
In the PR (odoo/enterprise#80787) the reconciliation model was refactored in order to be easier to use for users. However, some dead code was forgotten and not removed.
This change prevents an access error that could occur when creating a purchase order in a company that shares an unrestricted analytic account with another company. It ensures budget information is checked safely so users only see budget lines they are allowed to access, avoiding interruptions during purchasing.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
Sales order lines now correctly refresh their cost after an order has been canceled and set back to draft. This prevents outdated margin and pricing information from sticking around when the pricelist or currency changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This update corrects how spreadsheet form fields are displayed so missing or invalid values are clearly marked again. It also prevents dark mode styling from interfering with the spreadsheet’s default layout, helping keep the interface consistent and readable.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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#235236 Forward-Port-Of: odoo/odoo#234517
This change cleans up a complicated visual styling rule in the spreadsheet side panels. It makes the stylesheet easier to maintain while keeping the same behavior for users.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#99240 Forward-Port-Of: odoo/enterprise#98876