Monday, June 1, 2026
11 changes · saas-18.3
Enhancements to existing features
This update adjusts how global discounts are exported in invoices to align with UBL (Universal Business Language) standards. Previously, discounts were represented as negative invoice lines, which is now changed to 'Allowances'. This ensures compliance with international trade regulations and simplifies the export process for global transactions.
Original PR description
Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261029
Resolved issues and error corrections
This update backports several bug fixes identified during a recent upgrade process for the French payroll module (l10n_fr_pdp). These fixes address minor issues impacting the accurate processing of French tax regulations, ensuring continued compliance and reliable financial reporting.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267330
This update fixes an issue where group allocations with past start dates incorrectly showed zero accrual amounts. The change ensures that accrual calculations are properly triggered when group allocations are created, regardless of the start date, ensuring accurate time-off tracking.
Original PR description
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To…
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce: 1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day) 2. From the allocations view -> New Group Allocation 3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off 4. Go to the newly created allocation The allocation amount is 0. Reason ---------------------- When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed. Solution ------------------ Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations. task-4938695 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#266969 Forward-Port-Of: odoo/odoo#265783
This update resolves an issue where activity labels in the Chatter interface were not displaying correctly when the default summary was removed. The fix ensures that activity labels now consistently use the `display_name` when the summary is empty, providing accurate and consistent information for users.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures test data is correctly formatted for validation, preventing a 'binascii.Error' that occurred with Python 3.14. This improves the reliability of the Italian EDI module.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update corrects a visual issue in the POS system where a split button was always displayed, even when bill splitting was disabled. The fix ensures the button is hidden when the restaurant module is active, aligning the user interface with the current bill splitting settings. This improves the user experience and prevents confusion.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267037 Forward-Port-Of: odoo/odoo#266654
This update automatically sets the deductibility prorata rate to 100% by default in the tax reports. Previously, users had to manually configure this rate, which often led to inaccurate tax reports. This change simplifies the process and ensures more reliable tax calculations.
Original PR description
Users often forget to complete the deductibility prorata rate, which makes the tax report seems buggy. Set the rate to 100% by default. task-6092580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263486
This update resolves a rare test failure related to timing issues within the website's automated testing process. By adjusting how the test waits for updates, the system is now more reliable and less prone to intermittent errors. The changes also include minor improvements to the test's structure for better stability.
Original PR description
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise…
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise timings, but the helper `advanceTime` could introduce a non-deterministic lag because, when called with default options, it awaits for an animation frame. If the lag happens to be too long, the second `verifySteps` is called too late and the test fails. **Fix** The helper `advanceTime` is now called with the option `animationFrame` set to false to avoid awaiting for an animation frame. For additional safety, the waiting time is also reduced. Two changes not directly related to this problem have been applied to improve the test: 1. an unnecessary `await` in `willStart` has been removed; 2. the `animationFrame` has been set to false also on the second `advanceTime` (a non-deterministic lag here can't fail the test, but still there is no reason to await for the animation frame). runbot-243515 Forward-Port-Of: odoo/odoo#266432
This update resolves a minor visual issue where the name of the Sendcloud website delivery module was displayed incorrectly. The typo ('Sendcould') has been corrected, ensuring consistent branding and a better user experience. This change does not impact functionality.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118223This update disables the '@' mention feature for visitors in live chat conversations. Previously, visitors could trigger irrelevant suggestions, creating unnecessary noise. This change ensures a cleaner and more focused chat experience for all users.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266758 Forward-Port-Of: odoo/odoo#253551
This update fixes an issue where combo product prices were incorrectly duplicated in sales orders when all component prices were zero. The fix ensures the combo price is accurately distributed across its items, preventing double-reporting and improving order accuracy. This ensures consistent and correct pricing for combo products.
Original PR description
**Problem:** When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last…
**Problem:** When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last combo item line. **Steps to reproduce:** 1. Create a combo product with a non-zero price and two or more combo groups whose component products have a zero list price. 2. Create a sale order, add the combo, pick one item per group. 3. Look at the quotation/order: the combo line total and the last combo-item line both show the full combo price. **Current behavior:** The full combo price ends up on the last combo item line; the other combo items show 0. The combo line then displays the same total via `_get_combo_totals`, so the same amount appears twice. **Expected behavior:** The combo's price is spread across its combo items so no single line duplicates the combo total. **Cause of the issue:** `_get_combo_item_display_price` prorates the combo price by each combo's base price. When every base price is 0, every prorated price is 0, so `combo_price_delta` equals the full combo price and is added to the last combo as a rounding correction, concentrating the whole price there instead of spreading it. **Fix:** Treat an all-zero base case as "no proration signal" and split the combo price evenly across combos before the delta adjustment runs. The delta correction then only handles rounding, as intended. opw-6217945 Forward-Port-Of: odoo/odoo#265010