Wednesday, May 20, 2026
44 changes · saas-19.1
Resolved issues and error corrections
This update resolves a technical bug that prevented users from correctly selecting table headers in the HTML editor. The fix ensures the table plugin now correctly identifies both table data (`td`) and header (`th`) elements, preventing an error that caused the application to crash. This improves the stability and usability of the HTML editor.
Original PR description
### Steps to Reproduce : - Add a table (e.g., /table). - Turn the first row into table header. - Select all the cells of the table header. - Traceback occurs. ### Purpose of this PR: - Selecting a table header row caused a `Cannot read properties of null (reading 'getBoundingClientRect')` error because the table plugin only looked for `td` elements. This PR replaces hardcoded `td` selectors with the `isTableCell` helper to handle both `td` and `th` elements. task-6220287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264670
This update resolves an issue where the 'Create Ticket' action was unexpectedly appearing in the sidebar of WhatsApp conversations within Discuss. This removal prevents users from attempting to create tickets through this method, eliminating a potential error and improving the user experience. The change was implemented as a bug fix.
Original PR description
The 'Create Ticket' action was incorrectly visible in the sidebar actions of WhatsApp conversations in Discuss. Clicking it caused a traceback because `owner.root` is not defined in the sidebar action context. This commit removes the action from sidebar actions. Task-[6220037](https://www.odoo.com/odoo/project/1519/tasks/6220037) Forward-Port-Of: odoo/enterprise#117571
This update ensures that the price comparison strikethrough only appears on product pages when the compare price is higher than the regular sales price. Previously, it incorrectly displayed the strikethrough even when the prices were equal, leading to a confusing user experience. This change improves the accuracy and clarity of pricing information for customers.
Original PR description
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for…
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for the product. Issue: --- - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: --- - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: --- - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. Before: --- <img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" /> After: --- <img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" /> [1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265004 Forward-Port-Of: odoo/odoo#262434
This update fixes a minor issue in the demo order system for point-of-sale and restaurant POS. Now, demo orders automatically generate sequential Order References instead of using a default '/'. This ensures demo orders are more clearly identifiable and consistent, improving the demo experience.
Original PR description
Before this commit: =================== - For demo orders, no proper Order Reference is displayed, by default, it is set to '/'. After this commit: =================== - All default '/' values are replaced with a sequential Order Reference, except for orders in the 'new' state . Task-6004716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253272
This update fixes an issue preventing subcontracted products from automatically generating manufacturing orders during the replenishment process. The change ensures the correct routes are suggested, improving the efficiency of production planning for subcontracted items. This resolves a technical limitation impacting how products are managed.
Original PR description
'product.replenish' default_get/_get_route_domain wrongly states that a manufacturing order can be created from a non-'normal' bill of material. This prevents the 'Manufacture' route from being proposed to subcontracted-only products. task: 6132290 Forward-Port-Of: odoo/odoo#260111
This update resolves an issue where PDFs containing JPG images were no longer readable after an upgrade to the pdf.js library. The team added OpenJPEG support, allowing Odoo to correctly process and display PDFs with JPG content. This ensures consistent PDF viewing functionality for users.
Original PR description
Following the update of pdf.js to v5.4, reading pdfs containing JPG files didn't work anymore: https://github.com/odoo/odoo/commit/5035107ef64a8c1ca1aae3a2b0de5bf8efa246f4 Taken from https://github.com/mozilla/pdf.js/blob/v5.4.394/external/openjpeg/openjpeg.wasm opw-6073568
This update fixes an issue where the displayed weekday for accrual plan levels was sometimes incorrect. The change involved updating the way Luxon handles weekday data to ensure accurate representation of the chosen day of the week, resolving a discrepancy between the stored value and Luxon's expected format.
Original PR description
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and…
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and check the displayed weekday in the accrual plan level **Issue:** The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday). **Cause:** Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved. Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion. https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62 **Solution:** Adjust the value before passing it to Luxon by adding +1 to match ISO format. opw-6112614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259054
This update enhances the account reports feature by adding a confirmation dialog before deleting working files, preventing accidental data loss. It also restricts access to this feature for non-accountant users, improving data security and usability. These changes ensure a more controlled and secure experience for generating and managing account reports.
Original PR description
contains: [FIX] account_reports: Working files delete button: - hide it for non-accountant - add confirmation dialog [FIX] account_reports: Working file should always open in cycle view [FIX] account_reports: Always show embedded actions in Working files task-5880319 Forward-Port-Of: odoo/enterprise#115596
This update fixes a minor error in the data used for Mexican accounting within Odoo. The change corrects a typo in the account group CSV file, ensuring accurate reporting and compliance with Mexican tax regulations. This ensures the system correctly reflects financial data for Odoo users operating in Mexico.
Original PR description
Source: https://www.sat.gob.mx/minisitio/NormatividadRMFyRGCE/documentos2026/rgce/anexos/Anexo24delasRGCEpara2026.pdf opw-6174385 Forward-Port-Of: odoo/odoo#262549
This update fixes an error in the Luxembourg Annual VAT Declaration report that resulted in incorrect calculations for Appendix E 1a. The fix ensures that all necessary tax data is included accurately in the formula, leading to more reliable financial reporting. This improves the accuracy of VAT reporting for Luxembourg businesses.
Original PR description
### Issue: The formula `L10N_LU_TAX_163` in the Luxembourg Annual VAT Declaration was incorrect: - `L10N_LU_TAX_791.year_start` was added twice - `L10N_LU_TAX_993.year_start` was missing As a result, the computed total in Appendix E 1a was incorrect ### Steps to reproduce: - Install `l10n_lu_reports` - Open the `Report: Annual VAT Declaration (LU)` - Go to `Appendix E` - Use the `Start of Financial year` pencil icons to manually set values for fields `791` and `993` - Check the computed value of field `163` After the fix, both values are included exactly once in the formula opw-6158950 Forward-Port-Of: odoo/enterprise#117214
This update resolves an issue where importing XML files with tab characters in their filenames caused download errors. The fix ensures the system correctly handles filenames according to industry standards (RFC 2616), allowing users to import files with properly formatted names.
Original PR description
**Steps to reproduce:** * Upload an XML file whose filename starts with a tab character (e.g. extracted from a ZIP that preserves the tab in the filename). * Go to Accounting > Vendor > Bills and import the XML file. * In the chatter, click the attached XML file to download it. **Observed behavior:** * A JavaScript error is raised in the browser console: `TypeError: invalid parameter format` * The file cannot be downloaded. **Cause:** * `PARAM_REGEXP` in `download.js` defines qdtext as `[\x20!\x23-\x5b\x5d-\x7e\x80-\xff]`, which excludes `\x09 (HT/tab)`. * Per RFC 2616, `qdtext = any TEXT` except `"`, and `TEXT` includes `LWS` which includes HT `(\x09)`, making `filename="\ttest.xml"` a valid Content-Disposition header. * The JS parser was incorrectly rejecting a valid header value. **Fix:** * Add `\x09` to the qdtext character class in `PARAM_REGEXP` in `download.js`, making the parser `RFC 2616` compliant. opw-6052996 Forward-Port-Of: odoo/odoo#265176
This update fixes an issue where freight charges were incorrectly applied to all pickings, particularly with backorders. The change ensures freight costs are accurately reflected only on the initial, confirmed picking, aligning with how delivery costs should be billed to customers.
Original PR description
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are…
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings. 2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself. Solution ----- For the first problem, there are a couple things to keep in mind: - the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer - products can be added and removed from the picking after the SO has been confirmed - actual delivery cost can change between invoice date and actual delivery date - picking can be split into multiple packages at the user's discretion Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders. ----- Ticket: opw-6013387 Forward-Port-Of: odoo/enterprise#117115 Forward-Port-Of: odoo/enterprise#111304
This update ensures that all text within the MRP MPS component of Odoo Enterprise is properly prepared for translation. Previously, placeholder text was not translatable, now it is, allowing for localized versions of the software to be created. This improves the internationalization capabilities of the system.
Original PR description
Forward-Port-Of: odoo/enterprise#117750
This update resolves a visual issue where the SelectCreateDialog's control panel and list headers were disappearing. The problem stemmed from a previous change that removed a scrolling feature, and this fix restores the intended behavior for a better user experience.
Original PR description
This commit fixes an issue where the SelectCreateDialog's control panel and list headers would scroll out of view, restoring the intended behavior introduced in https://github.com/odoo/odoo/pull/206433. The feature was inadvertently broken by https://github.com/odoo/odoo/pull/219972, which removed the `overflow: auto` rule from `o_content` elements outside of actions. To resolve this, the `overflow: auto` rule has been explicitly reapplied to the SelectCreateDialog content area. task-6214232 Forward-Port-Of: odoo/odoo#264965
This update resolves a problem where a production group would disappear after merging MOs, causing errors when creating backorders. The fix ensures production groups are maintained correctly during the merging process, preventing the 'max() iterable argument is empty' error. This improves the reliability of the backorder creation feature.
Original PR description
# How to reproduce - Create 2 MO's A & B, both having the same product_id & bom_id - Split MO A into two MO's A1 & A2 - Merge MO's A1 & B # The issue MO A2 no longer has a production group (visible…
# How to reproduce - Create 2 MO's A & B, both having the same product_id & bom_id - Split MO A into two MO's A1 & A2 - Merge MO's A1 & B # The issue MO A2 no longer has a production group (visible via Studio). If the user tries to partially produce the MO and create a backorder, a traceback popup appears with : "ValueError: max() iterable argument is empty" # Cause The traceback is triggered because we use the `max()` function on `self.production_group_id.production_ids` when creating the backorder, but `production_ids` is an empty recordset since `production_group_id` is also empty. https://github.com/odoo/odoo/blob/0d8eaeeb971f2f670aebb1b72ed03f4a2d5e0105/addons/mrp/models/mrp_production.py#L1936 The production group is empty because when merging two MO's we delete it without paying attention to other remaining links. https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/mrp/models/mrp_production.py#L2555 Note : the production groups were introduced by this commit (https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a) # Proposed solution When merging, we unlink the original MO's from their production group. Then, we check every altered production group : if they are not linked to any MO anymore, we delete them. opw-6055376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256600
This update fixes a test in the HTML Editor that was unreliable due to its dependence on timing and browser behavior. The change makes the test more stable and predictable, ensuring consistent results across our CI systems. This improves the overall quality and reliability of the HTML Editor.
Original PR description
Description of the issue this PR addresses: Previously the test relied on real timers, animation frames and simulateArrowKeyPress(), making it sensitive to browser scheduling, native selectionchange timing and CPU slowness. The test now: - use advanceTime() instead of real setTimeout() - Replace simulateArrowKeyPress() with manual selectionchange dispatch to make debounce scheduling deterministic and avoid relying on the browser's asynchronous native selectionchange dispatch. - Add patchWithCleanup + verifySteps to test actual debounce execution rather than DOM visibility timing, which is sensitive to rendering and brwoser scheduling variance. This removes timing races and stabilizes the test on slow CI workers. runbot-242466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264893
This update resolves a crash during KSeF certificate authentication caused by Odoo's inability to handle different certificate types. The fix automatically determines the correct identifier type, ensuring successful authentication with the KSeF server and enabling proper tax reporting.
Original PR description
### Description of the issue/feature this PR addresses: **Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400…
### Description of the issue/feature this PR addresses: **Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType` **Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught. ### Current behavior before PR: The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature. ### Desired behavior after PR is merged: The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server. Ticket [link](https://www.odoo.com/odoo/project.task/6125243) opw-6125243 Forward-Port-Of: odoo/odoo#264851
This update fixes a regression where the color picker in Odoo was failing to recognize colors defined using the `color()` function. The change restores this functionality, ensuring users can correctly set background colors within the HTML Builder and Editor tools. This resolves an issue impacting visual customization.
Original PR description
Following the website refactoring (commit 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) `BuilderColorPicker` no longer recognizes colors defined using `color()`, introducing a regression. This commit restores support for `color()` values. Steps to reproduce: 1. Add the snippet `s_text_image`. 2. Manually, in the DOM, set the style of the first column to "background-color: color(srgb 0.4 0.2 0.8 / 0.4);". 3. In edit mode, click on the column to observe that the colorpicker does not recognize the background color. The same behavior can also be observed in the custom tab. Task: [5453922](https://www.odoo.com/odoo/project/974/tasks/5453922) Forward-Port-Of: odoo/odoo#265005 Forward-Port-Of: odoo/odoo#255331
This update resolves an issue where Croatian invoices with alphanumeric characters in the business premises label (e.g., 'v1') were causing system errors. The fix modifies a key parsing rule to correctly recognize these labels, ensuring invoices are processed without errors. This improves the reliability of invoice generation for Croatian businesses.
Original PR description
### Description of the issue/feature this PR addresses: The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's…
### Description of the issue/feature this PR addresses: The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's tooltip. However, the regex pattern inside `_get_l10n_hr_fiscalization_number` used to extract the sequence parts strictly expected digits (`\d+`) for the premises label segment. Because of this, if an invoice was generated with an alphanumeric sequence like `INV-2026-0001/v1/1`, the regex failed to match and returned `False`, leading to a traceback when the system attempted to process the fiscalization number. This commit updates the regex to correctly accept alphanumeric characters for the premises label, ensuring the sequence parses successfully. opw-6129009 ### Steps to reproduce: - Settings > Users & Companies > Companies > New > set Address country to Croatia - Select the newly created Croatian company - Apps > Activate l10n_hr_edi module - Accounting > Configuration > Accounting > Journals > click Sales journal > change “Business premises label” to “v1” - Contacts > New > set Address country to Croatia - Accounting > Customers > Invoices > New > select the newly created contact and choose any product > Confirm ### Current behavior before PR: Traceback error when attempting to confirm an invoice when both the company and the customer have their country code set to 'HR'. This is because `_get_l10n_hr_fiscalization_number` does not accept alphabet characters in the premises label section of the regex. ### Desired behavior after PR is merged: - No traceback error when confirming the invoice - `_get_l10n_hr_fiscalization_number` correctly parses the fiscalization number Forward-Port-Of: odoo/odoo#263650
This update resolves an issue where clicking on archived users in channel or group member lists caused errors. By preventing these users from being clickable, we align the behavior with other parts of the system and eliminate the technical problem. This improves the user experience and ensures stability.
Original PR description
Previously, clicking on an archived user from the channel or group member list triggered a traceback. This PR prevents archived users from being clickable, aligning the behavior with the message model where the popover is not opened for archived users, thus avoiding the traceback. enterprise: https://github.com/odoo/enterprise/pull/117480 task-6179486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264949 Forward-Port-Of: odoo/odoo#262247
This update resolves a test failure in the Odoo WhatsApp app's discuss sidebar. The change ensures the test accurately reflects the new system behavior of only considering active users when determining available commands. This improves the reliability of the test and ensures the app functions correctly for users.
Original PR description
This PR updates the discuss sidebar testcase to match the new behavior where only active users are considered when computing main_user_id, reducing the number of available commands and fixing the failing assertion. community: https://github.com/odoo/odoo/pull/262247 task-6179486 Forward-Port-Of: odoo/enterprise#117579 Forward-Port-Of: odoo/enterprise#117480
This update corrects a bug where users couldn't edit dates within the blog translate mode. The fix ensures the `DateTimeFieldPlugin` is correctly included in Odoo's core components, allowing for proper date field editing and preventing potential save errors. This improves the user experience for content creators.
Original PR description
The plugin `DateTimeFieldPlugin` was only added in registry `builder-plugins`. But it should also be included in the lists `CORE_PLUGINS` of `html_builder` and `TRANSLATION_PLUGINS` of `website` (the same as `MonetaryFieldPlugin` and similar plugins) Steps to reproduce: - Open `/blog` in translate mode - Click on a date - Bug: you can edit the text (and it will likely cause an error on save) task-6226376 Forward-Port-Of: odoo/odoo#264943
This update prevents the system from wasting time attempting to create API keys for unreachable databases. Previously, errors would clutter the synchronization results and cause delays. Now, the system skips these databases, improving synchronization speed and reducing unnecessary processing time.
Original PR description
#### The aim of this commit is to: - avoid cluttering the user UI with "obvious" error. - avoid wasting up to 15s trying to create the key if we don't get any response. #### Context: When a db is unreachable, trying to create an api-key on it will result in an error. #### Before this commit: - The wizard showing the result of the synchronization would show the error for every single databases in which it encounters that error. If there are a lot, it would bloat the result. - An unresponsive db would waste 15s of our sync time in a synchronized process. If that happens multiple times, we could end up a lot of time waiting for no reason. #### After this commit: We don't try to create an api key for unreachable databases. task-id: [5945269](https://www.odoo.com/odoo/project.task/5945269) - follow up Forward-Port-Of: odoo/enterprise#117053
This update resolves an error that occurred when users removed the 'Source Entity Id Type' setting in the Super Contributions module. The fix ensures the system correctly handles this removal, preventing a data processing failure and maintaining accurate reporting. This improves the stability of the Australian payroll reporting.
Original PR description
Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions. **Steps to Reproduce:** - Install `l10n_au_hr_payroll_account` with demo data. - Switch to an…
Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions. **Steps to Reproduce:** - Install `l10n_au_hr_payroll_account` with demo data. - Switch to an `Australian` company. - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`. - Open an existing record or create a new one. - Remove the `Source Entity Id Type` value and click anywhere. `ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id` After [change] in the selection field behavior, when the user removes the Source Entity Id Type, the compute method is triggered to compute the Source Entity ID. However, the condition in the compute method is not match, so no value is assigned. As a result, the method fails and raises an error. This commit ensures that if the condition is not match, the Source Entity ID is explicitly set to False. [1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65 [change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef Forward-Port-Of: odoo/enterprise#115466
This update resolves a visual issue in the composer where adding text to a seemingly empty line would unintentionally hide the user's signature. The fix moves the formatting code to ensure consistent signature display, preventing user confusion and improving the overall composer experience. This change focuses on clarity and usability.
Original PR description
**Steps to reproduce:** - Go to the chatter of any record - Open the full composer - Empty line is present above the signature delimiter (`--`) - Adding text to this line will encapsulate it with the rest of the signature (and hide it by default in the message) **Issue:** Extra `<br>` was added to improve readability, but adding it this way (before the delimiter) can be confusing for the users as they can add text on what appears to be a normal empty line, that is actually hidden with the signature ellipsis. **Fix:** Moved the added `<br>` element outside the signature container for the full composer. The user can still find a way to modify the composer structure in a way that will hide part of the text (e.g. by typing just before the delimiter), but this limits the issue. related: https://github.com/odoo/odoo/commit/13a9c6f5010c3dee01aa0f66ed41b25f517a4a8c opw-6087042 Forward-Port-Of: odoo/odoo#257936