Monday, May 18, 2026
11 changes · 18.0
New functionality added to Odoo
This update allows users to correctly account for VAT credits carried forward from previous months when preparing French VAT returns. Specifically, it adds the ability to adjust for line 25 of the return, which is where these credits are typically reported. This ensures accurate reporting and compliance with French tax regulations.
Original PR description
This commit will add the possibility to do an adjustment on the line 25. Useful when you start using Odoo but have a VAT credit carried forward from the previous month (which should appear in box 25 of your return). task-6072474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256107
Resolved issues and error corrections
This update fixes an issue where unapproved WhatsApp templates could be linked to event communications. The change disables creation features to ensure only approved templates are associated with events, improving data consistency and preventing potential misuse. This resolves a previous bug reported in opw-6047203.
Original PR description
**Steps to reproduce:** - Install Events / Whatsapp apps - Open an event - Add a communication with whatsapp type - Create and edit - Save and try to open the new communication record - Access error is raised **Issue:** Domain of the `'whatsapp.template'` search filter out unapproved templates. But when creating directly the record on the event it still gets linked to it. **Fix:** Disable `quick_create` and `create_and_edit` to prevent linking unapproved templates to an event communications (same logic as with an existing unapproved template). template search: https://github.com/odoo/enterprise/commit/659562008c090dc82039eb06fb99adf26268b3cc opw-6047203
This update fixes a bug where selecting a table from one end would select the entire table. Now, the HTML editor correctly handles selections that begin in a table cell and extend outside of it, providing a more intuitive and reliable table selection experience. This ensures users can accurately select and manipulate tables within the editor.
Original PR description
The previous commit fixes a behavior that is expected when the user makes a selection that starts in any element and ends in a table cell (the whole table gets selected), but the reverse case was never handled, namely when the selection starts in a table cell and ends outside of it. backport-https://github.com/odoo/odoo/pull/239270/changes/68e71fad5bbb0445bb1850bf694235f3235b602f task-5420366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where portal users could inadvertently delete documents they didn't own through archiving. The fix ensures that portal users can only delete documents they own, aligning with the intended functionality. This prevents unintended data loss during the regular cron-based trash collection process.
Original PR description
Reproduce: with rpc call as portal user, you can archive documents you have access to. This is not desired as this may lead to records being deleted when the cron collects the trash, but we only wanted to support portal users deleting only records they own. What we did when calling toggle_active should be done for all calls to `write` with `active`. It also removes the need for `_raise_if_unauthorized_archive` and `_unlink_except_unauthorized`. Task-6205627
This update ensures that the price comparison strikethrough on the shop page only appears when the compare price is higher than the sales price. Previously, it incorrectly displayed the strikethrough even when the prices were equal, creating a confusing user experience. This change improves the accuracy and clarity of product pricing.
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#262434
This update resolves an issue where renaming inherited custom fields in Odoo could cause data inconsistencies. The fix ensures that generated inherited fields are removed from the database before renaming, preventing errors and maintaining data integrity. This improves the reliability of custom field management.
Original PR description
When renaming a custom field that is inherited, first remove the generated inherited fields from the database. backport of https://github.com/odoo/odoo/pull/240603 opw-6148175
This update fixes an issue where WhatsApp channel avatars were incorrectly displaying 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 within the WhatsApp sidebar.
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)
This update resolves an issue where the Studio report editor was unintentionally using default theme colors. By preventing the use of these colors, the report editor now offers greater control and consistency for users creating reports. This ensures reports align better with brand guidelines and user preferences.
Original PR description
This commit will add a new props to ColorSelector to disable default theme colors to allows studio to not use them opw-6167143 linked to https://github.com/odoo/enterprise/pull/109206 enterprise https://github.com/odoo/enterprise/pull/117555
This update fixes an issue where the report editor in Odoo Studio was unintentionally influenced by default theme colors. The change prevents users from customizing report styles with these theme colors, ensuring consistency and preventing potential styling conflicts. This improves the report editor's reliability and simplifies report design.
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/264917This update resolves an error that occurred when generating the SD Worx report due to a missing employee record. The fix ensures the report gracefully handles cases where an employee isn't associated with a working schedule or company, preventing a system crash. This improves report reliability and data accuracy.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll_sd_worx module - Create a public holiday in one company without a working schedule - Create an employee that doesn't have a working schedule nor a contract - Try to generate the sd worx report - A traceback will pop-up ## Cause: Since we fetch all employees if we have a public holiday with no schedule, this puts us in a scenario where we try to access a key in that doesn't exist and it will trigger a KeyError ## Fix: Make sure we fallback on an empty recordset in case we don't have the employee in the key list of the dict we are checking opw-5500070 Forward-Port-Of: odoo/enterprise#117268
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. The change ensures that approval rules are applied correctly based on user and manager roles, preventing potential access problems. This resolves a minor inconsistency in the system's configuration.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480