Thursday, June 4, 2026
25 changes · saas-19.1
Enhancements to existing features
This update adjusts the order of the Obox app within the Odoo homepage. By increasing its sequence number, Obox is now displayed at the end of the app list, improving organization. This change ensures a cleaner and more intuitive user experience.
Original PR description
We set the sequence of the app to 250 so that it moves to the end of the apps in the homepage. task-6275407
This update adjusts the Obox application's placement within the main menu. The app is now positioned at the end of the list, just before 'Apps' and 'Settings'. This change improves user discoverability and simplifies navigation for Obox users.
Original PR description
This commit changes the Obox menu sequence so that the app appears at the end of the apps list by default (just before Apps and Settings). task-6275407
Resolved issues and error corrections
This update fixes a technical problem in Odoo related to how ordered sets are copied in Python 3.14. The change ensures that the set copy operation is performed reliably, preventing errors that could impact data consistency. This improves the stability of the system.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
Features or functions removed from Odoo
This update simplifies the Point of Sale system by removing a QR code print option that was only used in specific self-ordering restaurant setups. This change streamlines the configuration and reduces complexity for most users. The removal also eliminated a redundant link within the Point of Sale module description.
Original PR description
In this commit, --- - pos_self_order: removed the QR code print option from the pos config list view, as printing QR codes is only relevant for restaurants with self-order enabled and is already available in the configuration settings. - point_of_sale: removed the anchor tag from the Point of Sale module description, since the module header already provides the link. task-6222663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265472
This update ensures all date displays in the Point of Sale module consistently use Odoo's standard date format. Previously, receipts and reports used device-specific date formats, leading to potential inconsistencies. This change improves clarity and accuracy for users.
Original PR description
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already…
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69). As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. After this commit: --- <img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" /> All date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266770 Forward-Port-Of: odoo/odoo#259112
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to the beginning of the moved content, preserving the user's selection and ensuring a smoother editing experience.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267549 Forward-Port-Of: odoo/odoo#264264
This update optimizes the styling of Kanban dropdowns, specifically addressing slow loading times. By simplifying the CSS, we've significantly improved the responsiveness and speed of this key feature. This change focuses on performance and user experience.
Original PR description
This commit removes several expensive CSS selectors. After reviewing all usages, we found that `.o_kanban_card_manage_settings` always contains `div` elements with `col-*` classes as direct children. We also found that the border behavior depends on the available screen width rather than the bottom sheet itself: it is only needed when the elements are displayed side by side and should be removed when they are stacked vertically. An ´!important´ declaration was also added to compensate for the reduced selector specificity. 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#267979
This update optimizes the website's styling process, making it faster and more efficient. By switching from a complex selector to a simpler class on the body, the system now recalculates styles more quickly, particularly when dealing with large tables or during website resizing. This results in a smoother user experience.
Original PR description
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#267969
This update resolves an issue where the HTML editor toolbar remained active when selecting text within Code or Table of Content blocks. The fix ensures the toolbar is disabled when selecting protected content, providing a more consistent and intuitive user experience. This improves editor stability and usability.
Original PR description
Problem: The toolbar is disabled when selecting text inside Code or Table of Content blocks, but it remains active when selecting the block itself through the “⋮⋮” handle, leading to inconsistent behavior. Cause: `_updateToolbar` does not check whether `targetedNodes` contains only protected nodes. In such cases, the toolbar should be closed. Solution: When `targetedNodes` contains only protected nodes, prevent the toolbar from opening. Steps to reproduce: - Insert a Table of Content block. - Click on the “⋮⋮” handle while hovering the block. - Observe that the toolbar opens, while it should remain closed. task-6250028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266661
This update prevents unwanted translation changes from being saved to the system when a translation dialog is closed without confirming the updates. Previously, edits made to placeholder text within the dialog would persist across language selections. This ensures data consistency and prevents unexpected behavior for users.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459 Forward-Port-Of: odoo/odoo#264052
This update resolves an issue where negative line items in Mexican CFDI invoices were incorrectly distributed. The change addresses a conflict introduced by new features and removes a previous check that was no longer relevant. This ensures accurate CFDI invoice generation.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119254
This update corrects a technical problem affecting how the `pdp_verification_display_state` field is calculated. The change replaces a problematic setting with a new method, ensuring proper functionality within the partner merge wizard and preventing potential errors. This ensures accurate data processing for French-specific features.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update addresses a minor issue with how Odoo updates modules, resulting in faster and more reliable updates. The change mirrors a recent update in the main Odoo version (19.3) and includes a rollback mechanism to ensure correct translation of user error messages. This improves the overall user experience and stability.
Original PR description
Add a small lock timeout when updating modules just like it is done in master (19.3). Also add rollback so that translation of user errors work (in case we need to fetch the language from the database). runbot-234930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267698
This update resolves an issue where Mollie payments failed when customers didn't provide a fully populated billing address. Mollie now requires all necessary address fields (street, postal code, city, and country) to process payments, ensuring compliance with Mollie's requirements and preventing payment failures.
Original PR description
Steps to reproduce: 1. Setup a Mollie online payment method. 2. Make a payment with a customer that has an incomplete* billing address. Expected behaviour: The payment request is initiated. Actual behaviour: Mollie rejects the payment request. *: Mollie will either accept no billing address, or a full address (must include street, postal code, city and country). If only some of these fields are present, Mollie will reject the payment request. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where alert content was misaligned within the Odoo portal. The change was a result of a previous alignment adjustment, and the original styling causing the misalignment has been removed. This ensures alerts display correctly for all users.
Original PR description
The alert content is misaligned these changes are side effects of commit[1], the `h5` and `p` in the alert have margin that creates whitespace in the alert. Commit[2] addressed a misalignment issue and alignment issue due to nested `row` but these became irrelevant with commit[1]. This is why we remove the styling. task-5262108 [1]: odoo/odoo@513931a5e540f22f37e317f80fd131701cbbc8f0 [2]: odoo/odoo@d64dbaadcb1bef27d89a89e9d42bdb38890c73e0 | Before | After | |--------|--------| | <img width="1029" height="523" alt="image" src="https://github.com/user-attachments/assets/ff3f827b-652a-4a84-ad7e-205200cf3256" />| <img width="1022" height="486" alt="image" src="https://github.com/user-attachments/assets/b86163d8-bedd-4cb6-a950-ba36a6b401ee" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a flaw in the interval inversion function, ensuring accurate results across a wider range of scenarios. The fix addresses inconsistencies in how intervals were handled, particularly at the edges of the specified limits. This improves the reliability of calculations related to time ranges and date intervals.
Original PR description
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. [commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c Forward-Port-Of: odoo/odoo#267917
This update corrects a technical problem in the stock barcode module that was only reproducible within the community version of Odoo. The fix ensures accurate linking between stock packages, preventing errors related to unavailable links. This improves the reliability of barcode scanning and product tracking.
Original PR description
Reproducible only in community **Observation** outermost_result_package_id is a enterprise variable in stock_barcode: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L27 It's computed from result_package_id.outermost_package_id: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L29-L33 That variable is available in stock community : https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock/models/stock_package.py#L48 runbot-241085 Forward-Port-Of: odoo/odoo#267653
This update fixes an issue where excessively long addresses during credit card payments via Authorize.net would cause errors. The system now automatically truncates address fields to comply with the Authorize.net API's length restrictions, ensuring smoother payment processing. This improves payment reliability and prevents potential transaction failures.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
This update fixes a reporting issue where service sales from European companies to Northern Ireland were incorrectly included in the EC Sales List report. The change ensures that only goods and triangular transactions are reported, aligning with regulations. The update was specifically tested and implemented for the Belgium localization.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
This update resolves an issue where setting a non-numeric value for the 'next check number' in the accounting module would cause an error. The change ensures the system validates the input as a number before attempting conversion, preventing the error and allowing users to correctly set check number sequences.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
This update resolves an issue where Instagram videos wouldn't display correctly as background images in Odoo's website builder. The problem stemmed from an unnecessary addition of a URL parameter that Instagram's code rejected. This change removes that addition, ensuring Instagram videos now function as expected.
Original PR description
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is…
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is broken (iframe shows nothing / error). Cause: ======= Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render. The unconditional append is itself a regression from the public-widget → interaction refactor in [2]. The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram. Solution: ========= remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction [1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492 [2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4 opw-6233081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267016
This update corrects a technical issue preventing invoices with long product names, descriptions, or notes from being correctly processed for Romanian E-Factura submissions. The system now enforces character limits (100, 200, and 300 characters respectively) to ensure compliance with Romanian regulations. This resolves rejection errors and allows for proper E-Factura generation.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name…
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name longer than 100 chars - Confirm the invoice - Send E-Factura to SPV - Fetch E-Factura status **Issue:** The invoice is rejected with the following error: "[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100." **Similar issue with the product description:** "[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200." **Similar issue with the note (i.e. Terms and Conditions):** "[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300." **Solution:** Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300. opw-5964904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267850 Forward-Port-Of: odoo/odoo#265811
This update fixes a visual issue where Polish and Vietnamese characters appeared differently on Android Edge browsers due to font rendering differences. The fix ensures consistent character display across browsers by providing additional font subsets for older Edge versions that don't support Unicode ranges. This improves the user experience for international content.
Original PR description
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and…
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and vietnamese characters are using different font and are visually different than latin character. Cause: google fonts is serving for nearly all browsers font configuration with woff2 files and unicode-range so the user only loads the part of the font that will be used on the website. For Edge browser on android, based on the user-agent chrome is serving only a TTF file without unicode-range because it is thinking that unicode-range is not supported. These files only contain basic latin characters, so extended latin and vietnamese characters are being rendered with fallback "Odoo Unicode Support Noto" that has a different weight and style for the same weight. Fix: For the browser not supporting unicode-range (desktop edge before 2020, Edge on android, …), in addition to latin we ask google fonts to provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if available. For other subset (hebrew, arabic, cyrillic, …) the intent is to fallback on "Odoo Unicode Support Noto" since they should usually not be mixed with latin characters. Note: Edge on android in reality support unicode range, so this would be solved if google fonts just served the unicode range font configuration for that user-agent. [1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets opw-4642242 Forward-Port-Of: odoo/odoo#267798
This update resolves an issue where the Timesheet Assistant wouldn't function correctly when rules were created without a specified template. The fix ensures that all rules require a template, allowing the assistant to accurately build display names for key events. This improves the reliability of the timesheet tracking process.
Original PR description
## [FIX] timesheet_grid: make template field required in AW rule Before this commit, the template field in AW rule was not required and if one rule without any template is set, timesheet assistant will not be able to work correctly to build the display name for the key events found. This commit makes sure the template field is required. ## [FIX] timesheet_grid: ignore rules without template defined Before this commit, when the user creates a rule without any template set, the timesheet assistant will no longer work because it assumes the template is required. This commit adds a condition in the domain when we fetch all AW rules, to ignore the ones without template set.
This update resolves an issue where credit notes couldn't be created if the system encountered an archived bank account. The fix ensures that the system explicitly checks for inactive bank accounts during credit note creation, preventing validation errors and allowing invoices to be confirmed. This improves the reliability of credit note processing.
Original PR description
When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it…
When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message: > The recipient bank account linked to this invoice is archived. So you cannot confirm the invoice. The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team: > In practice, a compute method cannot expect active_test to have > a particular value. It may be invoked with any context. There is no > "context purge" done by the ORM. The computation may be "prepared" > with a context (the one of modified()) and actually done with another > context (code accessing the field before some explicit flush). In > other words, if the compute method searches for a record that matches > some conditions, and if that record cannot be inactive, then this > condition must be explicit in the search domain (or in the context). opw-6229286 Forward-Port-Of: odoo/odoo#267398