Monday, March 23, 2026
12 changes · 18.0
Enhancements to existing features
This update allows employees to create leave requests even when a payroll record exists for that period. Previously, leave creation was blocked if payroll was validated. This change relaxes the rules, enabling more flexible leave management while maintaining accurate payroll calculations, specifically addressing scenarios related to Swissdec payroll impact.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
Resolved issues and error corrections
This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves payroll accuracy for employees with very short overtime periods.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711
A bug was causing updates to Studio Approval Rules to inadvertently delete those rules from the database. This issue, identified during an upgrade, has been fixed by ensuring new records created by the system have a flag to prevent automatic deletion. This prevents data loss and ensures the stability of approval workflows.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records.
This update resolves an issue where non-sales users were encountering an error when viewing product information. The fix allows all users to access product pricing details by bypassing access restrictions within the product view calculation. This ensures a smoother experience for all users.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information based on payroll line items. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update fixes a misunderstanding regarding the date a W4 form is filed with an employer. The previous field incorrectly tracked when the form was filled out, rather than the actual filing date. This correction ensures accurate payroll processing for US HR payroll.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
This update prevents the entire reports cron job from stopping if a single report export fails. Previously, an error would halt the entire process. Now, the cron will continue to attempt exporting other reports, ensuring a more reliable and complete report generation.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#105191
This update fixes a bug related to currency rate calculations for Bulgaria. After the country switched to the Euro, the system was incorrectly using reversed rates from the data source. The change adjusts the parsing process to use the correct 'RATE' value, ensuring accurate currency conversions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update fixes an issue where chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages exchanged after the chatbot is restarted are accurately reflected, ensuring a cleaner and more reliable record of conversations. This improves the clarity and usability of customer support tickets.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where users could inadvertently assign inherited views to groups, leading to validation errors during module upgrades. The change adds a safeguard to prevent this, ensuring groups are defined correctly within the view XML, improving stability and reducing user confusion.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the…
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the Views section. - Upgrade the module. **Issue:** - Odoo already prevents assigning groups directly on inherited view records in ir.ui.view. However, it is still possible to indirectly assign groups to inherited views through res.groups via the view_access relation. - This creates entries in ir_ui_view_group_rel and can trigger a ValidationError during module upgrades. As a result, users may unknowingly create invalid group-view relations, leading to errors and confusion. **Solution:** - Add a validation constraint on res.groups to prevent linking groups to inherited views via the view_access relation. - Raise a ValidationError when such an assignment is attempted, with the message: "Groups should instead be defined using the 'groups' attribute inside the view XML definition." This ensures that inherited views cannot be assigned to groups, avoiding invalid configurations and preventing errors during module upgrades. **opw-6015526** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254849
This update fixes a potential issue where users could inadvertently create incorrect group assignments within Odoo's view settings. The change prevents assigning inherited views to groups through a specific database link, ensuring data integrity and preventing upgrade-related errors. This improves stability and reduces confusion for users.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the…
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the Views section. - Upgrade the module. **Issue:** - Odoo already prevents assigning groups directly on inherited view records in ir.ui.view. However, it is still possible to indirectly assign groups to inherited views through res.groups via the view_access relation. - This creates entries in ir_ui_view_group_rel and can trigger a ValidationError during module upgrades. As a result, users may unknowingly create invalid group-view relations, leading to errors and confusion. **Solution:** - Add a validation constraint on res.groups to prevent linking groups to inherited views via the view_access relation. - Raise a ValidationError when such an assignment is attempted, with the message: "Groups should instead be defined using the 'groups' attribute inside the view XML definition." This ensures that inherited views cannot be assigned to groups, avoiding invalid configurations and preventing errors during module upgrades. **opw-6015526** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254849
This update resolves a problem where strict email servers rejected Odoo emails due to folded Subject headers. We've extended our system to prevent folding, ensuring emails are properly delivered and avoiding errors. This aligns with best practices for reliable email communication.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo/odoo#250388 See-also: #243119 Backport: #247057 Forward-Port-Of: odoo/odoo#254670