Wednesday, May 13, 2026
29 changes · 19.0
Enhancements to existing features
The event registration process was reorganized so custom business needs can be added more easily without replacing the whole registration response. This helps partners and teams extend website event registration in a cleaner, more maintainable way while preserving the existing user experience.
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
This update removes restrictions on the fiduciary VAT field within the connection wizard for the l10n_be_codabox module. This change provides greater flexibility for users configuring VAT settings related to Codabox, streamlining the process and accommodating evolving business requirements. It's a minor improvement focused on usability.
Original PR description
This commit will remove the readonly on the fiduciary_vat in the connection wizard. It will give more flexibility for fiduciary. task-6148930
This update automatically sends email reminders to customers 7 days before an account return deadline. This improves the process of collecting returns and reduces the risk of missed deadlines, leading to better inventory management. The change was implemented as an improvement to the existing account return workflow.
Original PR description
Send reminder mail to submit an account return 7 days before the deadline. task-4752152
Resolved issues and error corrections
Website editors will now see the translation status background correctly on tab description text, even when that text uses block-style formatting. This makes it easier to spot and manage translated content while editing website tabs.
Original PR description
Span elements which have a style that causes them to be displayed as "block" do not have the background color given by the translation span (this is a ["known" issue]) To show the translation state on those nodes, this commit uses the resource `force_background_translation_state_selectors` for the following: - `.o_nav_tabs_description`, the description of tabs in `s_tabs_images` Introduction of `force_background_translation_state_selectors`: cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 ["known" issue]: https://github.com/odoo/odoo/commit/9addf9617830885532c27abb0ad5fa915e9f8f62 task-5892636 Forward-Port-Of: odoo/odoo#263620
Code cleanup and technical improvements
Peppol endpoint cleanup and validation is now handled in one shared place on partner records, reducing duplicated logic across invoicing and localization modules. This makes company and partner Peppol data checks more consistent and easier to maintain, with no expected workflow change for users.
Original PR description
[REF] account_{edi_ubl_cii,peppol}, *: unify sanitizer and checker
modules: account_peppol, account_edi_ubl_cii, l10n_dk_oioubl, l10n_dk_nemhandel
There are multiple places where the peppol endpoint is sanitized and/or checked. This commit unify the sanitizer/checker so that the res.partner model is responsible for doing it. The choice to keep it in res.partner was made because it's where the data is saved (e.g. peppol_endpoint on res.company is a related to the res.partner field)
This commit also removes the constraint on the field peppol_endpoint on res.company: as it is a related field and not readonly, the check will be triggered in res.partner.
task-5404836The Norwegian localization has been corrected so tax code 32 uses the official 11.11% rate instead of 11.0%. This helps businesses using Norwegian accounting avoid small but important tax calculation discrepancies and stay aligned with official rates.
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
This fixes an incorrect Spanish label for an Argentine fiscal position so domestic operations are no longer described as purchases or sales abroad. The change reduces confusion by ensuring fiscal position names are unique and match their intended business use.
Original PR description
### Description of the issue/feature this PR addresses: Fix fiscal position spanish translation to match with its real purpose. ### Current behavior before PR: * We have a fiscal position name that does not match with its purpose: Represent the local operations inside argentina (country: Argentina) but the name is " Purchases / Sales abroad" * Two fiscal positions have the same translation value and this is confusing ### Desired behavior after PR is merged: * we do not have duplicated fiscal position anymore * Domestic fiscal position is taged with the correct name --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Polish bank verification module is now included in the translation configuration. This ensures its user-facing text can be translated consistently, improving localization for Polish users.
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
The website editor no longer tries to load an unavailable Vimeo preview video when users configure a snippet background. This prevents an error from appearing and keeps the background video option usable.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#263555
Self-order receipts now show the correct pickup method when customers choose counter service without identification. This avoids confusion by displaying "Pickup At Counter" instead of incorrectly saying "Service at Table".
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
Partners created through Google Calendar synchronization now receive a clearer activity message posted by Odoobot instead of the system user. This makes audit trails easier to understand by showing that the contact came from calendar sync.
Original PR description
Before we were logging the new created partners default message using system user. Now we log custom message indicating that this partner was created from Calendar sync with Odoobot. task-6177363 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
The HTML editor now uses screen size, not only touch capability, to decide whether to show the mobile toolbar. This prevents large touch-enabled tablets from getting a phone-style toolbar, giving users the expected desktop editing experience on larger screens.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the display of remaining hours for sales order items shown from project tasks. Users can again see the time left directly in the dropdown, helping them choose the right sales order line without extra checks.
Original PR description
Steps to Reproduce: - Open any project linked with a sales order - Open task and click on Sale Oder Item dropdown. Issue: - You can see that SOL's with time remaining don't show the amount of time left Reason: - In this PR https://github.com/odoo/odoo/pull/193079 a record (view_task_form2_inherit_sale_timesheet) has been removed. - So the context key `with_remaining_hours` required to show remaining time is missing. Fix: - Add the record back which updates context task-6170953 Forward-Port-Of: odoo/odoo#262746
This fix ensures that when users change selected text from one heading style to another, the old heading style is properly removed. It prevents mixed or incorrect text appearance in website and editor content, making formatting results more predictable.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The user list filter for accounts with two-factor authentication disabled now returns the correct users instead of matching the enabled filter. This helps administrators accurately review which users still need two-factor authentication configured.
Original PR description
Issue: In the user view list, the "Two-factor authentication Disabled" filter doesn't work (return the same result than the "Two-factor authentication Enabled").
Explanation: The ORM normalises `=`/`!=` to `in`/`not in` with list values (commit odoo/odoo#191549 - 92301a5b300d). `_totp_enable_search` only handled the legacy scalar form: `value` is now always a list of boolean then always truthy then `[('totp_enabled', '=', False)]` returned users *with* a totp secret, the opposite of what was asked.
Fix it and add tests for it.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSpreadsheet charts now handle custom date filters that have only a start or only an end date. When the best time grouping cannot be reliably determined, charts keep their existing granularity instead of applying an unsuitable change.
Original PR description
The charts adapt their granularity when a date global filter is updated. But the code didn't handle the cases where the user sets a custom range with an open start or end date (eg. `until 2024-01-01`). In those case picking the best granularity is not practical (because it fully depends on the server data), so we will just keep the current granularity. Task: [6196246](https://www.odoo.com/web#id=6196246&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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
This fix ensures a sales inventory test runs under the intended restricted user instead of reusing cached access from an earlier step. It helps keep permission checks reliable so future changes are tested against the right access rules.
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 fixes an Email Marketing issue where attachments from test emails could incorrectly show up in a contact's chatter. Test email messages and their attachments are now cleaned up properly, keeping contact records free of temporary test content.
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 fixes an internal manufacturing test so it consistently includes lot tracking when checking component consumption. It helps prevent false test failures in environments without demo data, supporting more reliable product quality checks without changing user-facing behavior.
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
Event registration pages no longer show the original ticket price as struck-through when a fixed price rule is used. This avoids making standard fixed pricing look like a discount and keeps event ticket 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 test setup for Latin American checks now ensures the required Argentina localization data is available before running. This prevents a test failure on fresh databases and helps keep validation of check-related workflows reliable.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard BATCH/<TYPE>/000NN naming convention. The change ensures that all new batches are automatically named correctly, improving data consistency and reporting accuracy. This resolves a minor operational inefficiency.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320
Forward-Port-Of: odoo/enterprise#115809This 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 corrects a misleading warning message that appeared after a payslip was cancelled in the payroll system. This change ensures a cleaner user experience and prevents unnecessary confusion for HR staff. The fix includes associated testing to guarantee proper functionality.
Original PR description
. Clear payslip warning after cancelling the payslip . Add corresponding tests task-6199148
This update enhances the processing of French FEC import files by automatically skipping empty lines. Previously, the parser would encounter errors due to these empty lines, preventing successful file processing. This change ensures all valid data is processed, improving import reliability.
Original PR description
It could happens that we have some empty lines in the fec files, the parser was returning an error when that happened. We still want to process the file so we will just skip the empty lines. task-6169168
This update fixes an issue where completion and refusal emails for signatures were incorrectly sent using the partner's email address instead of the signer's email. Now, emails are sent using the correct, validated email address associated with the sign request, ensuring accurate communication with signers.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765
This update resolves an error preventing users with limited access rights from loading certain knowledge article templates. The fix delays an access check, ensuring the template loading process works correctly for users outside the primary 'Bookkeeper' group. This improves usability and prevents disruptions for users accessing knowledge articles.
Original PR description
Steps to reproduce: 1. Install `accountant_knowledge` with `demo data` 2. Remove demo user from bookkeeper access right and give some lesser right 3. Open knowledge and create a new artical with demo user 4. Click on Load template for example `Meeting Minutes` Issue: It gives a access error: `This operation is allowed for the following groups: - Accounting/Bookkeeper` Cause: - accountant_knowledge was doing accounting-only work during generic template loading. Immediately calling `target_article._get_inherited_audit_report()` that returns `inherited_audit_report_id`, which is a computed relation to audit report. `audit.report` is only readable by `account.group_account_user` Solution: - delay that access until it is actually needed, - only if the template contains data-embedded="accountReport" opw-6067390
This update resolves a problem where users couldn't link invoices to the chatter feature in Odoo. The fix prevents a security error that occurred when copying attachments, ensuring users with appropriate permissions can now successfully link documents.
Original PR description
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now…
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now go back to the SO, and try to link the INV document to the chatter. **Cause:** When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document. **Solution:** Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework. opw-5916364
This update resolves an issue where regular stock users were unable to view sales order details, leading to access errors. The fix ensures all sales orders, including inter-company transactions, can be properly accessed by standard users, improving operational efficiency.
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