Tuesday, May 12, 2026
25 changes · saas-19.1
Enhancements to existing features
This update enhances the process of testing Electronic Data Interchange (EDI) files within Odoo's cloud environment. Developers can now use a built-in validator to ensure EDI files meet required standards, streamlining the testing process and improving data accuracy. This change supports the external mode deployment of Odoo.
Original PR description
There is a file validator running on the IAP server which validates different types of XML files using XSD and Schematron files. This commits allows for developers writing edi testcases to have their XML files validated by the file validator by running their tests in EXTERNAL_MODE. task-5955497 Forward-Port-Of: odoo/odoo#254991
Resolved issues and error corrections
This update corrects a UI issue where the `l10n_co_edi_ubl` field in the Unit of Measure form was missing its label, causing user confusion. The fix ensures the field is clearly labeled, improving form usability and data entry accuracy.
Original PR description
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. -…
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. - Navigate to Invoicing > Settings. - Enable `Units of Measure & Packagings`. - Open `Units & Packagings` and click `New`. **Observation:** The `l10n_co_edi_ubl` field appears between the `Quantity` label and its corresponding field, but its own label is not visible. <img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" /> **Root Cause:** The inherited view [1] inserts the field `l10n_co_edi_ubl` before `relative_factor` in the base view [2]. In the base view, `relative_factor` is wrapped inside a `<div>` with a shared label (`Quantity`). Since the new field is inserted inside this structure, it inherits the same layout without having its own label, resulting in the label being hidden. **Fix:** This commit updates the view to ensure that the field `l10n_co_edi_ubl` is properly displayed with its own label, avoiding UI confusion and improving form clarity. **After:** <img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" /> [1]: https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13 [2]: https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34 opw-6180769 Forward-Port-Of: odoo/enterprise#115933
This update ensures the spreadsheet component within Odoo is running the latest version, addressing potential issues and improving its functionality. The changes include fixes related to installation and workflow processes, contributing to a more stable and reliable spreadsheet experience. Multiple developers collaborated on this update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e267f5db92 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1d4311e3d2 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/dfff07841c [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2e87404919 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent update caused the onboarding plan wizard to open without displaying the expected plan badges. This fix restores the correct badge display by reintroducing a key context parameter that was inadvertently removed. Users should now see the plan badges as intended, mirroring previous versions.
Original PR description
Steps to reproduce: 1- Install Employees app 2- Open the app and select any employee 3- In the chatter, click the onboarding plan link Issue: Starting from version 18.4 and onwards, clicking the link opens the 'Launch Plan' wizard without the Offboarding/Onboarding plans Expected behavior: The wizard should contain the plan Badges just like in previous versions or when clicking the 'Activity' button in the chatter Why this happens: One of the changes in the commit ef34950 was removing the following line: `context.params = state` The `state` included the `active_model` value which was passed in the url. As a result, `res_model` attribute in the model 'mail_activity_schedule' is `false`. The `_compute_plan_available_ids` will then return an empty list. So the consequent call which gets the available plans to display as a Badge will not be made. opw-6074918 Forward-Port-Of: odoo/odoo#258349
This update adjusts the default date range for the Lead and Pipeline dashboards to 'Last 30 days'. This change ensures users consistently see the most recent data, providing a clearer and more actionable view of sales performance. It addresses a previous issue with outdated default filters.
Original PR description
This commmit fixes the date filter default value to `Last 30 days`. Task: 5902231 Forward-Port-Of: odoo/enterprise#114560
This update streamlines the process of canceling old invoices in Mexico's EDI system. When a new invoice replaces an older one, the system now automatically cancels the original invoice, eliminating a manual step for users. This improves efficiency and reduces the risk of errors.
Original PR description
Triggers the EDI document cancellation method for the substituted invoice when the substitute document is signed, removing the requirement for the user to go back and click cancel again as well as bypassing calling a wizard with no options for the user to select from. task-5927581 Forward-Port-Of: odoo/enterprise#107541
This update corrects a technical issue where partners with VAT information were incorrectly flagged in the annual VAT listing warning. The fix ensures that these partners are no longer displayed in the warning, improving the accuracy of VAT reporting. This change enhances the user experience and data reliability.
Original PR description
Partners with / in VAT shouldn't be displayed in the warning for the annual VAT listing. task-6081162 Forward-Port-Of: odoo/enterprise#113839
The 'Waiting for Me' filter in the Sign app was incorrectly displaying all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and only shows relevant documents.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#113760This update resolves a visual glitch where the status bar displayed twice for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, preventing a confusing and inconsistent user experience. This improvement enhances the clarity and usability of the project management interface.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970 Forward-Port-Of: odoo/odoo#255319
This update resolves an error in the Luxembourg reports' FAIA XML export, specifically ensuring the required 'TVA' TaxType is used. This was triggered by customer feedback and confirmed by XSD files, preventing export failures. This fix ensures compliance with Luxembourg tax regulations.
Original PR description
This is one of several commits fixing the FAIA xml export. The customer in ticket [opw-5427296](https://www.odoo.com/odoo/unassigned-tasks/5427296) received several errors which mention that the `TaxType` element should be 'TVA'. This is corroborated by one of these elements in the XSD files for the FAIA report. The XSD files can be found at the link below. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-6118272 [link](https://www.odoo.com/odoo/project.task/6118272) *For future techs or functional support agents: updating `l10n_lu_reports` may not automatically apply the fix. You may need to go to the relevant Views model and select ⚙️ > Compare/Reset, then Hard Reset.* Forward-Port-Of: odoo/enterprise#116344 Forward-Port-Of: odoo/enterprise#113720
This update fixes an issue where product variants added through the product matrix on purchase orders weren't displaying the correct product description. The change restores a previous helper function to ensure the full product description, including attributes, is shown. This ensures accurate product information is visible on purchase orders.
Original PR description
From 7e553d25890d1, the `product_label_section_and_note_field` has been split into a mixin in `product` and an override in `account`. In this split. the `get label()` helper has been slightly modified in a way the product template is not extracted from the label to keep only the additional description (usually filled with product attribute values). This lead to having only the product template name displayed on the purchase order line if the product variant was added via the matrix widget. This commit brings back the old `label` helper only for the product matrix widget. Task: 6042382 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#262735
A recent issue caused the first line of product descriptions in quotation templates to be cut off when creating sales orders. This update adds a test to prevent this problem, ensuring that all product descriptions are fully displayed in sales order quotations. This improves the clarity and accuracy of sales order information.
Original PR description
Issue: --- When using quotation template, the first line of description is always removed. Steps to reproduce: 1- Create a quotation template and add a description to the line. 2- Create a SO from quotation template. As you see the first line of description is removed in SO. Cause: --- This regression is introduced after aba778538c2032a2924f99258c5c75e463296d21 which was done under the assumption that the description always starts with product name. This breaking commit is reverted by: a702a4989fc53ccc43f57213e0db3e62e7b69e8f However it's better to have a test in order to prevent this issue being introduced in the future. opw-6178360 Forward-Port-Of: odoo/odoo#262563
This update resolves an issue where the drag-and-drop overlay for moving table rows and columns in email templates appeared misaligned. The fix adjusts the overlay's position calculation to correctly account for the table being rendered within an iframe, ensuring proper alignment and functionality.
Original PR description
Steps to Reproduce: - Navigate to Email Marketing and open any template. - Insert a table into the template. - Long-press on the column or row options. Description of the issue: - The blue overlay used for moving rows/columns appears misaligned. Cause: - The position of the drag-and-drop overlay is calculated without considering the iframe. When the table is inside an iframe and the overlay is rendered outside of it, the position calculation becomes incorrect. Solution: - Update the position calculation logic to account for the iframe. This ensures that when the table is inside an iframe, the drag-and-drop overlay is displayed at the correct position. task-6059715
This update corrects a test failure caused by inconsistent data loading during automated testing. The test incorrectly assumed account reports always loaded the global version, leading to errors when demo data wasn't present. The fix ensures consistent test results by generating account reports within the test itself.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235
This update fixes an issue where the timesheet reporting incorrectly included public holidays from different companies, leading to inaccurate planned hour calculations. The fix ensures that only public holidays associated with the employee's company are considered, improving the accuracy of the planning analysis report.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#116263
This update resolves an issue where Swedish account numbers were incorrectly imported due to a character encoding mismatch. The import process was updated to handle the standard CP437 encoding used in the original Swedish SIE file, ensuring accurate account data is now imported.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408 Forward-Port-Of: odoo/enterprise#116722
This update resolves a bug where pressing backspace in the HTML editor, specifically at the button's edge, would cause an error. The fix ensures backspace correctly deletes characters and prevents the crash, improving the editor's stability and user experience.
Original PR description
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the…
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left. **How to reproduce** In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown. **Why the problem happens** 1. Traceback when backspace is pressed `LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash. 2. No deletion of the character to the left of the cursor `DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp. **Fix** 1. Prevent the crash in `LinkPlugin` `LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns. 2. Fix backspace behavior in `DeletePlugin` `deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left. task-6102282 Forward-Port-Of: odoo/odoo#258858
This update fixes an issue where the Table of Contents (TOC) navigation bar wasn't correctly displaying translated headings after styling them. The fix ensures that translated text is consistently shown in the TOC, regardless of inline formatting applied to headings on the website.
Original PR description
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4.…
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4. Switch to the second language in translation mode 5. Translate the styled heading and save => The TOC navbar entry keeps showing the source text on reload. => Expected: navbar shows the translated heading text, unstyled. Cause: ====== When a TOC heading carries inline markup, the server emits the heading and the navbar entry as two independent translation terms with different `data-oe-translation-source-sha` values, even though their textContent matches. A translation written under the heading's sha therefore never reaches the navbar's slot. `handleToC` was meant to bridge that by aliasing the navbar span's sha to the heading's during translation-mode setup, but two issues prevented it from working in saas-18.4+: - The TOC navbar lives under `.o_not_editable`, so its translation spans were excluded from `findOEditable` and `handleToC` never ran on them. The class `o_translation_without_style` was never added, and the sha was never aliased. Solution: ========= - `prepareTranslation` iterates TOC navbar translation spans explicitly, so `handleToC` reaches them despite `findOEditable` skipping `.o_not_editable`. - `handleToC` always tags the navbar span with `o_translation_without_style` when a matching heading exists. - An `after_replication_handlers` hook flags every replicated unstyled-translation target as `.o_dirty`, so the replicated translation is included in the save. opw-5950228 Forward-Port-Of: odoo/odoo#263161 Forward-Port-Of: odoo/odoo#260378
This update fixes a minor issue where some work entry names were incorrectly spelled within the Odoo HR system. The team corrected the data files to ensure accurate naming conventions, improving the overall consistency and readability of the system. This change was driven by a reported issue (opw-6090081).
Original PR description
Issue: ---------------------------------------- Some work entry names are wrong. Solution: ---------------------------------------- Change the data files. opw-6090081
This update eliminates redundant logging messages within the account_edi_ubl_cii module. Previously, similar log entries were repeated multiple times, which didn't provide useful information. This change streamlines logging for better clarity and efficiency.
Original PR description
Before this commit, we had repeated logs (n-times if we had similar lines) but this doesn't help too much. To avoid this we decided to remove duplicated messages Task-None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263779
This update resolves issues with note replies using the HTML composer, ensuring correct formatting and spacing are maintained. Previously, replies lost formatting and introduced extra line breaks. Now, replies preserve existing formatting and add trailing spaces correctly.
Original PR description
Before this PR, Replying to a note with the HTML composer enabled had several issues. - The mention added did not include a trailing space. - If the composer already contained formatted content, reply action discarded all formatting because the content was overwritten using composerText, which is not formatting-aware. - the composer sometimes showed extra spacing between lines because the base container used a `<p>` tag instead of a `<div>`. This PR fixes these issues by - inserting the mention directly into composerHtml with an editable trailing space instead of mutating composerText. This preserves existing formatting, and correctly adds spacing after mentions. - The base container always use a `<div>`, preventing unwanted line spacing task-[5454785](https://www.odoo.com/odoo/project/1519/tasks/5454785) Forward-Port-Of: odoo/odoo#242748
This update resolves a bug where price changes within the Blackbox POS module didn't consistently apply correctly, depending on the user's language settings (specifically, the decimal separator). The fix ensures accurate price calculations regardless of the user's locale, preventing incorrect order totals.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113341 Forward-Port-Of: odoo/enterprise#113151
This update resolves an issue where subsections remained visible on invoices even after the 'Hide Composition' feature was enabled. The fix adjusts how invoice reports display information, ensuring consistency between invoices and quotations. This improves the user experience by accurately hiding detailed invoice components as intended.
Original PR description
### Steps to reproduce: - Download 'Sales' app and create a product - Create an invoice with a section and a subsection - Set `Hide Composition` on the section - Add a product line under the subsection - Confirm and preview the invoice report > The subsection is still visible _Same issue occurs when activating 'Hide Prices'_ ### Cause of Issue: The `report_invoice.xml` file didn't include the right conditions to display the subtotals and unit prices in case of 'Hide Composition'/'Hide Prices'. Also, taxes were returned in `account_move_line` when they shouldn't be visible in case of 'Hide Prices'. ### Fix: Altered the conditions for sections and subsections, so that the information showing in 'Quotations' and 'Invoices' are consistent. opw-6069334 Forward-Port-Of: odoo/odoo#258628
This update resolves an issue preventing accurate translation exports from the Web Studio interactive editor. A specific code formatting style (backslash and newline) was causing errors in the export process. The fix eliminates this formatting issue, ensuring that code translations are correctly exported and applied.
Original PR description
It seems that the Babel Javascript tokenizer is not able to correctly parse a template string starting with a backslash and a newline. This caused it to extract pieces of code coming after it. The code excerpts would be exported in the POT file, but not applied to the JS code of course. The original message was not exported though, so it was not possible to translate it. This commit rewrites the template string to not use a backslash and a newline. This way the string is properly extracted and the code after it is not. Change was introduced by this commit[^1]. [^1]: https://github.com/odoo/enterprise/commit/56a2d9c4c2cc655af0469038d4c483581ac78864
This update resolves a technical issue where merging restaurant tables could cause a system crash due to an infinite loop. The fix ensures that the system correctly handles table relationships, preventing this error and improving stability when merging tables, even offline.
Original PR description
Before this commit, it could happen that we try to link a restaurant table to another that was already its parent (for example by merging them while offline, we couldn't know that they were in a prent-child relation). This would lead to an infinite loop when trying to get the position of the table since it was computed based on the parent position so when a table is its own grand-parent, we get an active infinite loop. We solve the problem by going through the backend to merge tables. Task-id: 6183779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262509