Daily updates from Odoo
Wednesday, May 20, 2026
147 changes
33 changes
Resolved issues and error corrections
A recent issue with the HTML editor was causing a technical error when selecting table headers. This fix updates the code to correctly identify both table data cells (`td`) and header cells (`th`), resolving the error and ensuring proper table selection functionality. This improves the overall 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
A technical issue where a 'Create Ticket' action was incorrectly appearing in WhatsApp conversations has been resolved. This change prevents users from attempting to create tickets through the sidebar, eliminating a potential error and improving the user experience. This was a minor 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 addresses a problem where lazy translations weren't correctly loaded when using Markupsafe 3.0.0, leading to incorrect language display. The fix ensures translations are evaluated in the proper context, maintaining compatibility with older Markupsafe versions used across our different Ubuntu environments.
Original PR description
In Markupsafe 3.0.0, a refactoring [^1] aiming at simplifying speedups implementation had an impact on the encapsulated templates introduced in commit odoo/odoo@aab7b846cdb8e77701c5e84e81d9c95bd9cd0894. More precisely, the eventual subtitles containing most of the time lazy translation, those were not evaluated in the right context anymore leading to being unable to find the lang to translate into. This commit fixes it by forcing the evaluation of the translation at a point were the context makes sense and contains the right lang when using Markupsafe 3.0.0+ (used in Ubuntu Resolute), while maintaining compatibility with 2.1.5 (used in Ubuntu Noble and Debian Trixie). [^1]: https://github.com/pallets/markupsafe/commit/dcb170b127137880729ac66f03cb590fff562225 Forward-Port-Of: odoo/odoo#264023
This update corrects a problem where a view was incorrectly trying to modify a field that existed in a different part of the system. This prevented the base module from upgrading correctly. The fix ensures the correct inheritance path is used, resolving a parsing error and allowing the system to function as intended.
Original PR description
The `partner_pages_tree_view` was attempting to modify `activity_ids` field attributes, but this field is added by the mail module in a sibling inheritance branch…
The `partner_pages_tree_view` was attempting to modify `activity_ids` field attributes, but this field is added by the mail module in a sibling inheritance branch ([mail.res_partner_view_tree_inherit_mail]), making it unreachable from the [`partnership.view_res_partner_grade_tree`] ancestry chain:
```py
base.view_partner_tree → partnership.view_res_partner_grade_tree → partner_pages_tree_view
base.view_partner_tree → mail.res_partner_view_tree_inherit_mail ← activity_ids lives here
```
This caused a ParseError during base module upgrade:
```py
File "/home/odoo/odoo/odoo/odoo/tools/convert.py", line 639, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml:13
Error while parsing or validating view:
Element '<field name="activity_ids">' cannot be located in parent view
View error context:
{'file': '/home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml',
'line': 1,
'name': 'Partner Pages List',
'view': ir.ui.view(2148,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(2108,),
'xmlid': 'website_crm_partner_assign.partner_pages_tree_view'}
```
**Steps to reproduce:**
- In a v19.1 db install `website_crm_partner_assign`
- Go to apps and search base module and click upgrade
**Fix:**
Make the partner view from partnership inherit from the one defined in mail instead of the one defined in base.
opw-6186684
[mail.res_partner_view_tree_inherit_mail]: https://github.com/odoo/odoo/blob/saas-19.3/addons/mail/views/res_partner_views.xml#L58C21-L67
[`partnership.view_res_partner_grade_tree`]: https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/partnership/views/res_partner_views.xml#L48-L57
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264639This update fixes an issue preventing subcontracted products from automatically generating manufacturing orders during the replenishment process. The change ensures the correct routing logic is applied, improving the efficiency of stock replenishment for products using subcontracting. Task 6132290.
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 the default prompt within the AI Documents account module was not updated after a recent code change. The fix ensures the prompt functions correctly, providing the expected AI assistance for document processing. This improves the usability of the AI Documents feature.
Original PR description
Bug === Since odoo/enterprise/pull/97362 we remove the code action to use a new type of action. But we forgot to update the code in the prompt modal. Task-6230554 Forward-Port-Of: odoo/enterprise#117715
This update resolves a minor issue where ActionList actions weren't correctly referencing the current context. This fix ensures that actions within ActionList displays and functions as intended, improving the overall user experience. It's a follow-up to a previous reported problem.
Original PR description
Follow-up of #265140.
This update fixes an issue where the displayed weekday in accrual plan levels was sometimes incorrect, showing Monday instead of the intended day. The change was necessary due to a difference in how Luxon handles weekday values (0-6 vs. 1-7). This ensures accurate representation of accrual plan schedules.
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 fixes an issue where the Table of Contents (TOC) navigation bar wasn't updating with translated text after styling headings on the website. The fix ensures that translated headings are correctly displayed in the TOC, regardless of inline styling, improving the user experience across multiple languages.
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#263547 Forward-Port-Of: odoo/odoo#260378
This update fixes a potential issue where incorrect data in payslips could trigger warnings. The change ensures that these warnings are handled more gracefully, preventing disruptions to payroll processing. This improves the stability and reliability of the HR payroll module.
Original PR description
…ta and versions Task: 6133111 Forward-Port-Of: odoo/enterprise#114778
This update resolves an issue where file downloads from Odoo were failing when the filename started with a tab character. The fix ensures that filenames with tab characters are now correctly processed, allowing users to download files from various sources, including ZIP archives.
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 ensures that all text within the MRP MPS component of Odoo Enterprise is properly prepared for internationalization (I18N). Previously, placeholder text was not translatable, and this change makes the system ready for localization into different languages. This improves the user experience for international customers.
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 fix restores the intended scrolling functionality, ensuring users can properly view and interact with the dialog. This was caused by a previous change that removed a key styling rule.
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 test failure related to GS1 barcode scanning in the Point of Sale module. The fix ensures the system correctly interprets 14-digit GTIN-14 barcodes, which are standard for GS1 products, leading to accurate product addition to orders. This improves the reliability of barcode scanning during transactions.
Original PR description
The test_GS1_pos_barcodes_scan was failing because the "GS1 Variant Product" barcode was defined as a 13-digit string, while the tour scans it using the GS1 AI 01 (GTIN), which expects a 14-digit GTIN-14. By adding a leading zero to the barcode in the test setup, we align it with the GTIN-14 format parsed by the POS barcode parser during the scan, ensuring the product is correctly added to the order. runbot-error: 242323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258547 Forward-Port-Of: odoo/odoo#258089
This update ensures that the first product variant shown on the external website matches the order in which it appears on category pages and within the product configurator. Previously, the website wasn't consistently displaying the correct initial variant, leading to a potentially confusing customer experience. This fix corrects this issue.
Original PR description
When generating a product, set product.template.attribute.value sequences so that the variant that shows first in the external website is also first by _get_first_possible_variant_id(). This ensures the correct variant image appears on the shop category page and is pre-selected in the product configurator. Forward-Port-Of: odoo/enterprise#117701
This update ensures that UTM tracking parameters (like those used for marketing campaigns) are correctly processed when the website's cookies bar is displayed. Previously, these parameters weren't handled properly. This change improves the accuracy of marketing data collected through the cookies bar.
Original PR description
Since we've added the utm_reference parameter, it should be correctly handled in when the cookies bar is present Added in: https://github.com/odoo/odoo/pull/233963 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#265011
This update fixes a test for the HTML editor that was unreliable due to its dependence on timing and browser behavior. The change makes the test more stable and predictable, especially on slower computer systems, ensuring consistent test results.
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 an issue where product category images weren't showing correctly on website B when accessed without being logged into website A. The fix ensures category images use absolute URLs, bypassing domain-based access rules that were causing the display to fail. This improves the visual consistency of product categories across all websites.
Original PR description
Scenario: - set two website A and B with different domain - create an eCommerce category Y - create and publish a product with category Y, website B - drop category list widget in a page in website B - set in /odoo/system-parameters web.base.url to domain of website A - open the page in website B while being logged out of website A Result: the category Y image is dead. Cause: category images are using domain of "web.base.url", so if that corresponds to a website where the category is not shown (because of the access rule "Hide empty eCommerce categories to public/portal users") then the image will not be shown (unless we are a logged in internal user on the domain of "web.base.url"). Fix: use absolute URL without domain for category image, the same way it is done for other dynamic snippets (eg. Products). opw-6118004 Forward-Port-Of: odoo/odoo#260124
This update corrects a bug where a course would remain active even after all orderlines were removed, preventing table release. The fix automatically cleans up empty courses when the last orderline is deleted, ensuring the system functions correctly and tables can be released efficiently.
Original PR description
Steps to reproduce: - add a course - add a orderlines - remove orderlines - the course is still there - unable to release table Fix: Call cleanCourses after removeOrderline so empty unfired courses are automatically deleted when the last orderline of a course is removed. Task-6181153 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#262818
This update corrects a technical issue preventing Croatian invoices with alphanumeric premises labels (like 'v1') from processing correctly. The change adjusts a key system rule to accept these labels, ensuring invoices are properly generated and processed without errors. This resolves a previous traceback and improves invoice confirmation functionality.
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
A recent update (saas-19.3) introduced an unwanted gap between the Studio navigation bar and the apps section on the home page. This fix removes the problematic margin and adjusts spacing for the search input, restoring the intended visual appearance and preventing background exposure.
Original PR description
Since saas-19.3, an extra margin on the home menu introduced a visible gap between the Studio navbar and the apps section, exposing the background. This commit removes the margin from the o_home_menu and applies spacing to the search input instead. task-6175467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 error and maintaining accurate reporting. This improves the stability of the Australian payroll functionality.
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 usability issue in the composer where adding text to a seemingly blank line would hide it within the user signature. The fix moves the formatting code outside the signature container, preventing accidental text encapsulation and improving the composer's clarity for users. This ensures consistent and predictable signature behavior.
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
This update resolves an issue where archived sales teams were incorrectly showing up in the Sales Team dropdown when creating new opportunities within the CRM. The fix removes a redundant setting that was causing this behavior, ensuring accurate dropdown lists for active and archived teams. This improves the user experience and data consistency.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801
Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300This update ensures that donation confirmation emails are sent in the user's chosen website language, regardless of their anonymous status. Previously, emails were defaulted to English. This change improves the user experience and ensures consistent communication for all donors.
Original PR description
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make…
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make a donation via the donation snippet. 3. Check the outgoing confirmation email. => Email body is rendered in English. Cause: ====== The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in. Solution: ========= `payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation. - override it in the `/donation/transaction` controller with `request.env.lang` when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context); - render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`. opw-5875338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264657 Forward-Port-Of: odoo/odoo#259351
This update fixes a minor error in the Odoo software's configuration for Mexican accounting. The change corrects a typo in the account group data, ensuring accurate reporting and compliance with Mexican tax regulations. This ensures the software functions correctly within the Mexican market.
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 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 user experience.
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 fixes a potential issue in the Point of Sale system by separating the waiter method. This change allows for more flexible error handling, particularly important for features like FDM where order validation needs to be paused during errors. It ensures the system can continue to function correctly even when issues arise.
Original PR description
In order to allow patching (in particular for FDM, where we don't want to finalize the validation of the order if there is an error), we extract the waiter method. see odoo/enterprise#104468 Forward-Port-Of: odoo/odoo#264974 Forward-Port-Of: odoo/odoo#244298
A test for multi-lot component consumption was failing due to a missing user group. This update explicitly grants the necessary 'lot tracking' group within the test environment, ensuring the test now passes correctly. This resolves a technical issue that could have impacted future development.
Original PR description
The test uses the stock move line detailed operations form and expects the `lot_id` field to be present in the view. Without demo data, the current user may not belong to the `stock.group_production_lot` group, causing the field to be absent from the rendered form view and the test to fail. Causing: `AssertionError: 'lot_id' was not found in the view` in line: https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/mrp/tests/test_consume_component.py#L477 Grant the lot tracking group explicitly in the test setup. runbot-243588 Forward-Port-Of: odoo/odoo#263759
This update fixes a visual inconsistency in the CRM form view. Previously, MRR and AI probability fields were displayed on separate lines, causing misalignment across devices. Now, both fields are aligned on a single line for a cleaner and more consistent user experience on both desktop and mobile.
Original PR description
**Before this commit:** When recurring revenues were enabled in CRM, the MRR field was displayed across two lines instead of a single line as expected. In mobile view, the AI probability was displayed as a separate input field, instead of a same line. Commit: https://github.com/odoo/odoo/commit/cfef0dde9df8d1999e6aad0a28dbfd11049d19d8 **After this commit:** Updated the form view layout to display both the MRR and AI probability fields on a single line for better alignment and consistency across desktop and mobile views. Task-6128227
This update resolves an issue where Odoo was attempting to process GSTR2B attachments with missing file content, leading to errors. The change now verifies that the attachment's actual file data exists before processing, ensuring smoother return filing and preventing potential disruptions. This improves the reliability of the Invoicing reports.
Original PR description
There may be databases contained GSTR2B JSON attachments whose metadata was still present in `ir.attachment`, but whose underlying binary content was missing from the filestore. This caused the matching flow to attempt processing invalid JSON payloads instead of moving the return to `error_in_fetching`. The condition validating JSON attachments now also checks that the attachment raw content exists before adding it to the payload list. opw-6088082 Forward-Port-Of: odoo/enterprise#117083
This update corrects a technical error that prevented users from interacting with the 'Test' button within the IoT app. The issue stemmed from a data processing error, specifically an 'index out of range' error, which was preventing the button from functioning correctly. This fix ensures the 'Test' button operates as intended.
Original PR description
This PR fixes the following traceback when using "Test" button in the iot app: ``` 2026-05-18 07:48:36,248 22727 ERROR ? websocket: error from callback <bound method WebsocketClient.on_message of <WebsocketClient(Thread-6, started daemon 3995071456)>>: list index out of range 2026-05-18 07:48:36,249 22727 ERROR ? odoo.addons.iot_drivers.websocket_client: websocket received an error: list index out of range ``` opw-6226014 Forward-Port-Of: odoo/odoo#264897
This update resolves a limitation in the sale commission report's query, allowing it to handle significantly larger sales order IDs. By removing an unnecessary bit shift, the report now supports a much wider range of data, improving performance and scalability. This change ensures the report continues to function correctly with growing sales volumes.
Original PR description
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.…
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10` This shifts the max aml.id 40 bits to the left. Example: Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number. 1 << 20 = 1048576 1048576 | 1 = 1048577 1048577 << 10 = 1099512676352 1099512676352 | 1 = 1099512676353 1099512676353 << 10 = 1152922604119523328 With this format, the highest guaranteed AML ID this query can handle is under 838,861. The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id` | | AML Max | RULES.ID Max |RULES.USER_ID Max| | --------------------- | ------ | ------ | ------ | | Before | 838,861 | 1,048,576 | 1,024 | | After | 858,993,459 |1,048,576 | 1,024| opw-6124026 Forward-Port-Of: odoo/enterprise#114711
22 changes
Resolved issues and error corrections
This update resolves an issue where deleting menus in the project module caused a system error. The change ensures the system gracefully handles the absence of menus, preventing disruptions to project workflows. This improves stability and reliability for users managing projects.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist. 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#263647 Forward-Port-Of: odoo/odoo#262824
This update resolves an issue where deleting specific menus in the database caused a failure during startup. The change ensures the system correctly handles the absence of these menus, improving stability and preventing errors. This primarily impacts the Enterprise version of Odoo.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist. Forward-Port-Of: odoo/enterprise#116803 Forward-Port-Of: odoo/enterprise#116498
This update resolves a technical problem that prevented users from correctly selecting table headers in the HTML editor. The fix ensures that the table plugin now correctly identifies both table header (`th`) and data cell (`td`) elements, preventing an error that caused the application to crash when selecting header rows. This improves the overall 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. Removing this action prevents errors and improves the user experience. This change ensures a smoother workflow for users interacting with WhatsApp through Odoo.
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 when the compare price is higher than the regular sales price. Previously, it incorrectly displayed a strikethrough even when the prices were identical, creating a confusing user experience. This change improves the accuracy and clarity of product pricing on the website.
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 ensures that donation confirmation emails are automatically translated to the user's preferred language. Previously, anonymous donors received emails in a default language regardless of their browsing language. This change improves the user experience and ensures consistent communication for all donors.
Original PR description
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make…
Steps to reproduce: =================== 1. Configure website with at least 1 language installed different from English. ex: English and French. 2. As anonymous user, change wehbsite language and make a donation via the donation snippet. 3. Check the outgoing confirmation email. => Email body is rendered in English. Cause: ====== The donation confirmation email rendered with `self.partner_id.lang`. For anonymous donors, `partner_id` is the website's shared public user partner, so every anonymous donor received the email in whatever language was set on that partner (or English if unset), regardless of the language they were browsing in. Solution: ========= `payment.transaction` already has a `partner_lang` field auto-filled from `partner.lang` at creation. - override it in the `/donation/transaction` controller with `request.env.lang` when the public partner is used, capturing the request language at donation time (also works later from `_cron_post_process`, which has no request context); - render `_send_donation_email` using `self.partner_lang` instead of `self.partner_id.lang`. opw-5875338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259351
This update addresses a technical issue related to how translations are handled within Odoo's Markupsafe 3.0.0 implementation. Specifically, lazy translations weren't correctly identified, preventing proper language selection. The fix ensures translations are evaluated in the correct context, maintaining compatibility across different Odoo environments.
Original PR description
In Markupsafe 3.0.0, a refactoring [^1] aiming at simplifying speedups implementation had an impact on the encapsulated templates introduced in commit odoo/odoo@aab7b846cdb8e77701c5e84e81d9c95bd9cd0894. More precisely, the eventual subtitles containing most of the time lazy translation, those were not evaluated in the right context anymore leading to being unable to find the lang to translate into. This commit fixes it by forcing the evaluation of the translation at a point were the context makes sense and contains the right lang when using Markupsafe 3.0.0+ (used in Ubuntu Resolute), while maintaining compatibility with 2.1.5 (used in Ubuntu Noble and Debian Trixie). [^1]: https://github.com/pallets/markupsafe/commit/dcb170b127137880729ac66f03cb590fff562225 Forward-Port-Of: odoo/odoo#264023
This update resolves an issue preventing subcontracted products from using the 'Manufacture' route during replenishment. The fix corrects a technical error in how Odoo determines which products can initiate manufacturing orders, ensuring the system functions correctly for all product types. This improves the efficiency of the manufacturing process.
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 fixes an issue where custom order names entered on kiosks were being overwritten with generic tracking numbers. Now, kiosk orders will accurately retain the customer-provided name, improving the order experience and reporting accuracy. This ensures consistent order identification across all channels.
Original PR description
Before this commit, when a customer placed an order from a kiosk and provided a custom name, it was systematically overwritten by the backend with a generic "Table tracker X" or the tracking number. task-id: 6014281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252983
This update fixes an issue where the displayed weekday in accrual plan levels was incorrect, often showing Monday instead of the selected day. The change was necessary due to a mismatch between how Luxon handles weekday values (0-6) and the previous system. This ensures accrual plans accurately reflect the intended weekly frequency.
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 fixes a minor typo in the CSV file defining account groups used in Odoo's Mexican localization (l10n_mx). The correction ensures accurate reporting and compliance with Mexican tax regulations, as outlined by the SAT (tax authority). This change ensures data integrity for Mexican businesses using Odoo.
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 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 upload and download files with tab characters without disruption.
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
A recent test failed because the system was creating multiple orders for the same table in certain configurations. This update resolves this issue by creating a new, unique table for each configuration, ensuring accurate order processing and preventing test failures. This improves the reliability of our self-order system.
Original PR description
In the test test_self_order_table_sharing, the test could fail due to multiple orders being created for the same table on different config since the same table was used on multiple config. This commit fixes this test by creating a new table for the config. runbot-error: 240898, 240896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253862 Forward-Port-Of: odoo/odoo#253081
This update ensures that the MRP MPS component in Odoo Enterprise is fully prepared for internationalization (I18n). Specifically, placeholder text within the component has been modified to be translatable, allowing for accurate localization in different languages. This improves the overall user experience for international customers.
Original PR description
Forward-Port-Of: odoo/enterprise#117750
This update fixes a potential issue in the Point of Sale system, specifically related to order validation. By extracting a 'waiter method,' the system can now continue to process orders even if errors occur, particularly important for features like FDM. This change enhances flexibility and reliability.
Original PR description
In order to allow patching (in particular for FDM, where we don't want to finalize the validation of the order if there is an error), we extract the waiter method. see odoo/enterprise#104468 Forward-Port-Of: odoo/odoo#264974 Forward-Port-Of: odoo/odoo#244298
This update resolves a visual issue where the SelectCreateDialog's control panel and list headers were not visible. The problem was caused by a previous change that removed a scrolling feature, and this commit has re-enabled the scrolling functionality to ensure the dialog displays correctly.
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 fixes a visual issue on the company's website where the first product variant shown wasn't always the correct one. By setting specific product sequences, the system now ensures the desired variant image appears prominently on category pages and in the product configurator, leading to a better customer experience.
Original PR description
When generating a product, set product.template.attribute.value sequences so that the variant that shows first in the external website is also first by _get_first_possible_variant_id(). This ensures the correct variant image appears on the shop category page and is pre-selected in the product configurator. Forward-Port-Of: odoo/enterprise#117701
This update fixes a test for the HTML editor that was unreliable due to its dependence on timing and browser scheduling. 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 fixes an issue where self-order receipts incorrectly displayed 'Service at Table' instead of 'Pickup At Counter' when a customer selected a counter service option without identification. This ensures accurate receipt information for customers using the self-order feature, improving the customer experience and order clarity.
Original PR description
When selecting a preset with a service at counter but without identification, after a self order the receipt header was wrongly showing "Service at Table" instead of "Pickup At Counter". This is now fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264115
This update corrects a bug where a course would remain active even after all orderlines were removed, preventing table release. The fix automatically cleans up empty courses when the last orderline is deleted, ensuring a smoother and more reliable restaurant order process.
Original PR description
Steps to reproduce: - add a course - add a orderlines - remove orderlines - the course is still there - unable to release table Fix: Call cleanCourses after removeOrderline so empty unfired courses are automatically deleted when the last orderline of a course is removed. Task-6181153 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#262818
A previous error prevented users from searching for links within the Link Tracker feature. This update resolves the issue, allowing users to accurately search for clicks based on their short URLs. The fix addresses a technical limitation with how the short URL field is currently handled.
Original PR description
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing…
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing app 2. Create a new mailing (or you can use an existing one that has some clicks) and send it 3. Make a click in the email from the recipient's side 4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button) 5. Make a search based on the Link (short_url) field Expected Behavior ------ Return the list of links that matches the entered search query. Current Behavior ------ Odoo Server Error. Cause & Solution ------ The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method. Task-6131693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265059 Forward-Port-Of: odoo/odoo#260146
This update prevents Odoo 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, streamlining the synchronization process and improving overall performance.
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
24 changes
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 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 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 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 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 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 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
This update fixes a potential error message that could appear when spreadsheets are unavailable. The change prevents this traceback by handling server errors directly within the spreadsheet action, eliminating the need for complex template modifications. This improves the user experience and stability of the Enterprise edition.
Original PR description
The fix suggested in #81276 did not account for other spreadsheet models than a document as it required some modification in the component template. The same logic should then have been forwarded to other models (quality.check for instance] but that process is error prone. This revision changes the approach by handling the server error inside the abstract action so that no template modification is required. task-6208222 Forward-Port-Of: odoo/enterprise#117221
This update resolves an issue where archived sales teams were incorrectly appearing in the Sales Team dropdown when creating new opportunities. The fix removes a redundant setting that was causing this behavior, ensuring that dropdowns only display active teams. This improves the user experience and data accuracy within the CRM.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801
Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300This update fixes an issue where newly created projects weren't automatically using the stage defined in their project template. The fix ensures that projects created from templates correctly inherit the intended stage, streamlining project setup and reducing manual adjustments. This improves consistency and efficiency in project management workflows.
Original PR description
Steps to reproduce: - 1. Enable "Project Stages" in Project settings. 2. Create a project template and move it to a stage other than the first one (e.g., "Stage 2"). 3. Create a project from this template (manually or via a Sales Order). Issue: - The newly created project is always placed in the first stage instead of inheriting the stage defined in the template. Cause: - The `stage_id` field on the `project.project` model is defined with `copy=False` When a project is created from a template, this field is excluded from the copied values, causing the new project to fall back to the default first stage. Fix: - Override `copy_data` to explicitly include `stage_id` from the source project template. task-6019852 Forward-Port-Of: odoo/odoo#264827 Forward-Port-Of: odoo/odoo#253864
This update addresses a technical issue that prevented users from consistently interacting with the 'Test' button within the IoT driver application. The fix corrects a data processing error (specifically, an 'index out of range' error) that was causing the button to malfunction. This ensures reliable operation of the IoT driver.
Original PR description
This PR fixes the following traceback when using "Test" button in the iot app: ``` 2026-05-18 07:48:36,248 22727 ERROR ? websocket: error from callback <bound method WebsocketClient.on_message of <WebsocketClient(Thread-6, started daemon 3995071456)>>: list index out of range 2026-05-18 07:48:36,249 22727 ERROR ? odoo.addons.iot_drivers.websocket_client: websocket received an error: list index out of range ``` opw-6226014 Forward-Port-Of: odoo/odoo#264897
This update fixes a limitation in the sale commission report's query, allowing it to handle significantly larger sales order IDs. By removing an unnecessary bit shift, the report now supports a much wider range of data, improving performance and scalability. This change ensures the report continues to function correctly with growing sales volumes.
Original PR description
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.…
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10` This shifts the max aml.id 40 bits to the left. Example: Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number. 1 << 20 = 1048576 1048576 | 1 = 1048577 1048577 << 10 = 1099512676352 1099512676352 | 1 = 1099512676353 1099512676353 << 10 = 1152922604119523328 With this format, the highest guaranteed AML ID this query can handle is under 838,861. The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id` | | AML Max | RULES.ID Max |RULES.USER_ID Max| | --------------------- | ------ | ------ | ------ | | Before | 838,861 | 1,048,576 | 1,024 | | After | 858,993,459 |1,048,576 | 1,024| opw-6124026 Forward-Port-Of: odoo/enterprise#114711
3 changes
Resolved issues and error corrections
This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to allow creators to successfully cancel their own approvals, streamlining the workflow and improving user experience.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104
This update fixes an issue where new WhatsApp channel members weren't correctly displayed as avatars in the sidebar. Now, avatars are pulled directly from the channel's WhatsApp member, ensuring users see the correct representation of each conversation. This improves the user experience and consistency within the WhatsApp channel.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#117633 Forward-Port-Of: odoo/enterprise#115745
This update prevents the report editor in Odoo Studio from using default theme colors, which were causing potential styling conflicts. This change improves the consistency and reliability of report design within Studio, ensuring reports are rendered correctly regardless of the underlying interface customizations. This resolves a longstanding architectural issue.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style
to be influenced by the presence or lack thereof of the html_editor
module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143
community: https://github.com/odoo/odoo/pull/264917
Forward-Port-Of: odoo/enterprise#117634
Forward-Port-Of: odoo/enterprise#1175554 changes
Resolved issues and error corrections
This update fixes an issue where URLs with mixed or uppercase letters weren't automatically converted to clickable links within the HTML editor. The change ensures that all URLs, including single-character domains like 'x.com', are correctly recognized and linked. This improves the user experience by making it easier to share and navigate to online resources.
Original PR description
### Description of the issue/feature this PR addresses: - URL_REGEX was constructed with the "i" flag, but passing a RegExp object to new RegExp(regex, "g") silently drops the original flags, leaving only "g". This caused uppercase (ODOO.COM) and mixed-case (Odoo.Com) URLs to not be converted to links when pressing space. ### Desired behavior after PR is merged: - URL_REGEX.source with explicit "gi" flags to preserve case-insensitive matching in `prepareConvertToLink`. - Allow automatic URL detection for single-character domains such as `x.com`, `t.co`, and `a.io` by relaxing the minimum domain label length in the URL regex from 2 to 1 characters. task-6199269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263255
This update resolves a minor error in the Mexican accounting module (l10n_mx) related to a typo in the account group data file. The correction ensures accurate reporting and compliance with Mexican tax regulations. This change was prompted by a document from the Mexican tax authority (SAT).
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 resolves an error that prevented users from initiating replenishment when no suitable routes were configured for a product. The fix ensures the system handles cases where routes aren't defined correctly, preventing a crash and allowing replenishment to proceed smoothly. This improves the reliability of the stock management process.
Original PR description
## Steps to Reproduce: 1. Install the stock module. 2. Activate "Multi-Step Routes" from settings. 3. Activate the "My Company (Chicago)" company. 4. Create a route for the Chicago company. 5. Create a new product and enable the created route on it. 6. Click on the "Replenish" button. ## Error: `IndexError - tuple index out of range` ## Cause: At [1], when none of the product routes belong to the current company or are shared routes, the filtering returns an empty recordset. As a result, trying to access the first route from the empty result raises an index error. ## Fix: This commit only assigns `route_id` when a route matches the given condition. Otherwise, it keeps the value as `False`. [1] - https://github.com/odoo/odoo/blob/13c0e082c260381a332fe1425fe2ba83a1c0c579/addons/stock/wizard/product_replenish.py#L78 sentry-7488075413 Forward-Port-Of: odoo/odoo#265179
This update resolves an issue where UBL invoices would fail to import due to extra spaces in the 'EndpointID' field. The change automatically removes these spaces, ensuring invoices are correctly processed and imported, improving data accuracy.
Original PR description
**PROBLEM** When importing a ubl that, for some reason, have trailing space on the text of the EndpointID node, we refuse it. This PR strips the trailing spaces on the import. **STEP TO REPRODUCE** 1. Import a ubl as a bill, with a trailing space in the EndpointID of the other party. 2. Notice the import fail, with the error: The Peppol endpoint (50238597645 ) is not valid. It should contain only letters and digit. opw-6227395
3 changes
Resolved issues and error corrections
The website builder's AI-generated content was causing spacing issues due to overly broad rules. This update refines the AI's spacing adjustments, now focusing only on new layout changes and preserving existing snippet styles during content edits. This ensures a cleaner and more consistent website experience.
Original PR description
Snippets added by AI have its elements glued with no proper spacing. The problem is the spacing rule in the builder topic was too broad and implied existing Bootstrap margin or gutter classes should be removed, even when only editing snippet content. Limit the rule to new layout spacing changes and tell the AI to preserve existing snippet structure/classes during content-only edits. task-id-6230199 Forward-Port-Of: odoo/enterprise#117712
This update resolves a crash that occurred when users clicked the 'hide' button on the payroll dashboard. The issue stemmed from in-memory warning records being incorrectly processed, leading to database errors. The fix ensures these warnings are handled correctly, preventing the crash and improving dashboard stability.
Original PR description
Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849
A bug was causing a 'Create Ticket' action to appear unexpectedly in the WhatsApp sidebar. This commit removes this action, resolving a technical issue that prevented users from accessing the WhatsApp feature as intended. This ensures a smoother and more reliable experience for WhatsApp conversations.
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
4 changes
Resolved issues and error corrections
This update resolves a test failure in the WhatsApp discuss sidebar by aligning it with a recent change that now only considers active users when determining user roles. This ensures the test accurately reflects the current system behavior and prevents further disruptions to the WhatsApp functionality.
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#117480
This update prevents the report editor in Odoo Studio from using default theme colors, which were causing potential styling conflicts. This change improves the consistency and reliability of report design within Studio, ensuring reports are rendered correctly regardless of the underlying interface customizations.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style
to be influenced by the presence or lack thereof of the html_editor
module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143
community: https://github.com/odoo/odoo/pull/264917
Forward-Port-Of: odoo/enterprise#117780
Forward-Port-Of: odoo/enterprise#117555This update fixes an issue where WhatsApp channel avatars were incorrectly displayed as the default Discuss avatar after a member was added. Now, avatars are correctly pulled from the channel's WhatsApp member, ensuring accurate representation and a better user experience for WhatsApp channel communication. This improves the visual consistency and usability of the WhatsApp feature.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#117633 Forward-Port-Of: odoo/enterprise#115745
This update fixes a discrepancy in how contract types are defined within Odoo's HR modules. Specifically, the definition of `contract_type_id` was standardized across the base and Belgium-specific versions. This ensures consistent data and avoids potential errors in reporting and calculations related to employee contracts.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#117586 Forward-Port-Of: odoo/enterprise#113244
7 changes
Resolved issues and error corrections
This update corrects a typographical error in the CSV file defining account groups used in Odoo's Mexican localization (l10n_mx). The fix ensures accurate reporting and compliance with Mexican tax regulations, as outlined in the latest SAT guidelines. This ensures the system correctly categorizes financial transactions according to Mexican standards.
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 issue where tip payments, even with a 0% tip, weren't always being processed by Stripe. The change ensures that a capture payment is always initiated, regardless of the tip amount, aligning with Stripe's requirements and preventing pending payments from being automatically cancelled.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596
This update corrects a validation issue within the l10n_pl_edi module, ensuring that a specific flag (TWybor1) always accepts only the value '1'. It also clarifies that the KursWaluty field is optional when it matches PLN, simplifying invoice creation. This ensures compliance with Polish tax regulations.
Original PR description
Legal ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf
- KursWaluty is optional and doesn't need to be included if it's the same as PLN.
- The following flags accept only "1" as a valid value.
See their type being etd:TWybor1:
http://crd.gov.pl/wzor/2025/06/25/13775/schemat.xsd
http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2020/07/06/eD/DefinicjeTypy/ElementarneTypyDanych_v7-0E.xsd
```xsd
<xsd:simpleType name="TWybor1">
<xsd:annotation>
<xsd:documentation>Pojedyncze pole wyboru</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:byte">
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
```This update fixes an issue where refreshing a timesheet record from the 'My Timesheets' grid view incorrectly displayed the generic 'Analytic Items' form. The fix ensures the correct timesheet-specific form view is consistently shown after a page refresh, providing a more accurate and user-friendly experience.
Original PR description
**Problem** When opening a timesheet record from the *My Timesheets* grid view (via the magnifier icon that appears on cell hover) and refreshing the page, the wrong form view is loaded: the generic…
**Problem** When opening a timesheet record from the *My Timesheets* grid view (via the magnifier icon that appears on cell hover) and refreshing the page, the wrong form view is loaded: the generic "Analytic Items" form on `account.analytic.line` instead of the timesheet-specific form. **Steps to reproduce** 1. Go to *Timesheets* → *My Timesheets* → switch to **Grid** view. 2. Hover a cell with a timesheet entry and click the magnifier (search) icon. 3. The list opens; click a record to open its form view. 4. Observe the URL: `/odoo/timesheets/<id>`. 5. Refresh the page (F5). **Expected** The same timesheet form view is shown after refresh. **Actual** The "Analytic Items" form view (`analytic.view_account_analytic_line_form`) is shown instead, exposing the wrong layout/fields. **Cause** The grid renderer's `openRecords` builds an inline `ir.actions.act_window` with no `path` and no `id`. When the page is refreshed, the action service reconstructs the action from the URL state alone — model + resId — and resolves the form view by priority. Two priority-1 form views exist on `account.analytic.line` (`analytic.view_account_analytic_line_form` and `hr_timesheet.hr_timesheet_line_form`); the lower-id one wins, which is the analytic one. **Fix** Override `openRecords` in `TimesheetGridRenderer` to carry the current action's `path` (or `id`, for non-pathed database actions) onto the inline action. The URL then stays anchored to the original act_window (e.g. `/odoo/timesheets/<id>`), and on refresh the action service rebuilds it with the correct views, including the timesheet-specific form. opw-6133602
This update corrects a formatting error in invoices where extra decimal places were being added to the displayed price. The fix reduces the precision calculations to prevent these unnecessary digits from appearing in the PDF output, ensuring invoices display correctly.
Original PR description
Issue: - Create an invoice with a line having a price of `528,000,000.00` - Print the invoice -> pdf displays `528,000,000.000001` Cause: In `value_to_html` from `ir.qweb.field.float`, we compute the maximum precision that we can get from the value, to avoid parasite digits. The maximum is 15, so if a number has 11 digits, we won't ask for a precision higher than 4. But in `float_round`, they multiple the value with its precision, then add `epsilon` (a small value). So we're now working with a 16 digits float, which is what we want to avoid. Solution: Reduce the maximum precision from one digit before calling `float_round`. opw-6012129
A recent update inadvertently removed a key test related to product margins. This change has been corrected to ensure continued testing and maintain the quality of the product margin calculations. Restoring this test helps guarantee the accuracy and reliability of our product margin features.
Original PR description
Commit e61403f5a3 accidentally removed test_aggregates while resolving a forward-port conflict. Restoring the test to maintain coverage. no task-id
This update resolves an issue where Jofotara was rejecting invoices due to extremely small negative discount amounts. The fix ensures that discount amounts are always non-negative by applying an absolute value function, preventing errors related to floating-point calculations and improving invoice processing with Jofotara.
Original PR description
Before this commit: 1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3) 2. Send the order to Jofotara Jofotara rejects the…
Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara
Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`
This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency
where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.
After this commit:
Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.
opw-6183423