Wednesday, May 13, 2026
12 changes · saas-18.4
Enhancements to existing features
The event registration process was adjusted so businesses and partners can more easily customize it without replacing the whole registration page logic. This improves flexibility for tailored event workflows while keeping the visible user experience unchanged.
Original PR description
Since this controller returns raw markup, it is impossible to inherit. By splitting the controller `registration_new`, allows to manage custom developments with the inheritance of the prepare method instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250756 Forward-Port-Of: odoo/odoo#244156
Resolved issues and error corrections
The Norwegian localization now uses the official 11.11% tax rate for tax code 32 instead of the incorrect 11.0%. This helps businesses using Norwegian accounting stay aligned with statutory tax reporting requirements.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#263904 Forward-Port-Of: odoo/odoo#258390
Event registration pages now avoid showing a crossed-out original price when a fixed price rule is used. This prevents fixed ticket prices from looking like discounts and keeps event pricing consistent with the online shop.
Original PR description
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.…
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior. ### Steps to reproduce 1. Create an event with a paid ticket (e.g., 100 EUR). 2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR). 3. Open the event registration page. 4. The 100 EUR appears struck-through next to 80 EUR. ### Cause Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts. ### Fix Rationale A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount. opw-5993477 Forward-Port-Of: odoo/odoo#263586
The Polish bank verification module has been added to the translation configuration. This ensures its text can be properly translated and maintained for users in different languages.
Original PR description
[FIX] Add l10n_pl_bank_verification to weblate.json In a previous PR, we added the new module 'l10n_pl_bank_verification' but didn't added it in weblate.json. This PR fix it See odoo/odoo#262518 Forward-Port-Of: odoo/odoo#263758
Test emails in Email Marketing now clean up their related messages and attachments after sending. This prevents attachments used only for a test email from showing up incorrectly in a contact's chatter, keeping customer records cleaner.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Upload a file in Settings > Attach a file - Click on the test button to send a test mail to any mail - Go to the first contact record - Related attachment appears in the chatter **Issue:** Before 18.2, messages created for testing were ignored by the Chatter as they were empty (and not unlinked). But if an attachment was provided, it was linked to the test message and not deleted afterwards (which means it shows up in the record chatter). **Fix:** Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to False to trigger the `unlink` logic and remove the related attachments at the same time. backport of: https://github.com/odoo/odoo/commit/526b3d73886558315f2435714b2ed82fec313e78 opw-6168632 Forward-Port-Of: odoo/odoo#262152
This fix ensures the manufacturing test setup explicitly enables lot tracking access before checking detailed stock operations. It prevents test failures in environments without demo data, helping keep manufacturing quality checks stable and reliable.
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 fix ensures a sales and inventory test runs under the intended restricted user, so access checks are validated accurately. It improves confidence that permission rules are enforced correctly without changing customer-facing behavior.
Original PR description
When running the test, `button_validate()` was called twice in succession. - Once explicitly - Once through `process_cancel_backorder()` The first time it is called though, it's not through the restricted user that we want to test, allowing some access rights checks to run smoothly. The second time it's called with the restricted user, the cache still contains some data that should be no longer accessible, allowing the test to run even though it shouldn't. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264057
This fix prevents an error when processing returned stock valuation records that involve products measured in different unit categories. It helps keep inventory valuation workflows reliable when handling returns with mixed product types.
Original PR description
#### Issue: Consuming stock valuation layers linked to returned moves could raise an error when the SVL recordset contained products from different UoM categories. #### Cause: `_consume_specific_qty()` and `_consume_all()` used `self.uom_id` inside per-record loops. When self contained SVLs from different UoM categories, self.uom_id was multi-record, causing quantity conversion to fail with: `ValueError: Expected singleton: uom.category(2, 6)` #### Fix: Use the UoM of the current SVL record during returned quantity conversion: - `candidate.uom_id` in `_consume_specific_qty()` - `svl.uom_id` in `_consume_all()` opw-6119427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263295 Forward-Port-Of: odoo/odoo#259736
This update resolves an issue where users were receiving an error message when exporting payroll data to SDWorx for freelance employees. The change removes a redundant check for SDWorx codes specifically for freelancers, streamlining the export process. This ensures accurate data transfer for all employee types.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set…
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- In https://github.com/odoo/enterprise/pull/106065/changes/c19009c776349c3f5d8aebf99aff8efe987b54db The Check for Freelance Employee type was removed, which was earlier added in the fix https://github.com/odoo/enterprise/pull/102211/changes/96724c3cc55725e87e618443b96069921b8f3bda Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#114411
This update resolves a bug that prevented regular users from accessing sales order details, regardless of whether they were inter-company transactions. Previously, users would encounter access errors when validating sales orders, disrupting the sales process. This fix ensures all sales order information is accessible.
Original PR description
When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047
This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a previous test data state to ensure the tests continue to run successfully. This ensures accurate reporting functionality for Italian customers.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#116923 Forward-Port-Of: odoo/enterprise#112794
This update resolves an issue where planning managers lacked the ability to copy planning slots to employees with flexible calendars. Previously, access restrictions caused errors. Now, planning managers can successfully copy slots, regardless of the employee's calendar type, improving usability and workflow efficiency.
Original PR description
**Purpose**: A user with planning manager rights but no access to employee and contract records should be able to copy and movea planning slot to an employee with a flexible resource_calendar without…
**Purpose**: A user with planning manager rights but no access to employee and contract records should be able to copy and movea planning slot to an employee with a flexible resource_calendar without getting an access rights error. **Before this commit:** When copying a planning slot, the system tries to compute the working hours over the period of the slot. This will raise an access rights error if the user doesn't have access to employee and contract records when the slot is moved to a flexible resource_calendar. **After this commit:** The user can copy a planning slot without access rights error with only planning manager rights, even if the slot is moved to a flexible resource_calendar. **Steps to reproduce:** 1.Install Planning and Planning Contract modules. 2.Create a user with only planning manager rights and no access to employee and contract records. 3.Copy a planning slot to an employee with a flexible resource_calendar. opw-6166557 Forward-Port-Of: odoo/enterprise#115953