Wednesday, May 20, 2026
29 changes · 19.0
New functionality added to Odoo
This update adds a new test to ensure the payment data sent to our payment processor (Odoofin) remains consistent. This test helps prevent unexpected changes that could disrupt payments and ensures developers are aware of any necessary updates on the Odoofin side. It's a proactive measure to maintain payment processing reliability.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID Forward-Port-Of: odoo/enterprise#117260
Enhancements to existing features
The online shop search or filter clear button now keeps its intended size instead of shrinking. This improves visual consistency and makes the button easier for shoppers to notice and use.
Original PR description
task-6145581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents Odoo spreadsheets from making duplicate server requests when loading list values and headers at the same time. Users should see spreadsheets reload more efficiently, especially when list-based formulas are used.
Original PR description
How to reproduce: - Create a spreadsheet with a CRM list and only set 2 cells content A1: =odoo.list(1, 1, "id") A2: =odoo.list.header(1,"zip") - save and reload the spreadsheet and look at the server calls ⮕ web_search_read called 2 times The problem is that the datasource methods early return if the datasource is already loading without adding the field to the list to fetch. It was partially solved by explicitely adding the field to fetch in the *getter* `getListCellValueAndFormat` but not on `getListHeaderValue`. This revision ensures that we always add the field to the list to fetch in the datasource directly, this responsibility should not be held by the plugin getters. Task-6175523 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#261985
Documentation and clarification updates
This pull request adds QoQa's signed corporate contributor agreement to Odoo's records. This supports legal compliance for accepting contributions from QoQa and has no direct impact on product features or users.
Original PR description
Description of the issue/feature this PR addresses: This is the corporate CLA for QoQa. I backported #262581 because we need it from 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262582
This update optimizes how bank statement details are recorded within Odoo. By using a batch logging function, the system now processes transactions more efficiently, reducing delays and improving overall performance. This change focuses on internal system improvements, enhancing the speed and reliability of bank statement management.
Original PR description
There is no need for a full message post to get the details of the transaction. We can use the batched function instead `_message_log_batch`.
Clicking archived users in chat channel or group member lists is now disabled to prevent an error screen. This keeps the member list experience stable and consistent with how archived users are handled in messages.
Original PR description
Previously, clicking on an archived user from the channel or group member list triggered a traceback. This PR prevents archived users from being clickable, aligning the behavior with the message model where the popover is not opened for archived users, thus avoiding the traceback. enterprise: https://github.com/odoo/enterprise/pull/117480 task-6179486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262247
Automated maintenance and base automation jobs no longer report partial progress when they are not processing a true queue. This prevents the scheduler from incorrectly retrying the same failed work and helps avoid repeated errors.
Original PR description
Base automation and autovacuum should not log progress as this is makes the job scheduler think that something progresses and can be retried leading to the same error because we process the same (all) items. In general, progress numbers are only relevant for jobs that act as job queues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264684
The website editor color picker now correctly detects colors defined with modern color values. This prevents existing page styling from appearing unrecognized or difficult to edit after the recent website refactoring.
Original PR description
Following the website refactoring (commit 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2) `BuilderColorPicker` no longer recognizes colors defined using `color()`, introducing a regression. This commit restores support for `color()` values. Steps to reproduce: 1. Add the snippet `s_text_image`. 2. Manually, in the DOM, set the style of the first column to "background-color: color(srgb 0.4 0.2 0.8 / 0.4);". 3. In edit mode, click on the column to observe that the colorpicker does not recognize the background color. The same behavior can also be observed in the custom tab. Task: [5453922](https://www.odoo.com/odoo/project/974/tasks/5453922) Forward-Port-Of: odoo/odoo#255331
Projects created from a template now inherit the stage set on that template instead of being placed in the first available stage. This helps teams preserve intended project workflows when creating projects manually or from sales orders.
Original PR description
Steps to reproduce: - 1. Enable "Project Stages" in Project settings. 2. Create a project template and move it to a stage other than the first one (e.g., "Stage 2"). 3. Create a project from this template (manually or via a Sales Order). Issue: - The newly created project is always placed in the first stage instead of inheriting the stage defined in the template. Cause: - The `stage_id` field on the `project.project` model is defined with `copy=False` When a project is created from a template, this field is excluded from the copied values, causing the new project to fall back to the default first stage. Fix: - Override `copy_data` to explicitly include `stage_id` from the source project template. task-6019852 Forward-Port-Of: odoo/odoo#253864
This fixes an issue where renaming a custom field that is inherited could leave outdated generated fields in the database. The system now removes those generated fields first, helping avoid data model conflicts and administrative errors during field changes.
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 Forward-Port-Of: odoo/odoo#265194 Forward-Port-Of: odoo/odoo#264044
The online shop no longer shows a crossed-out comparison price when it is the same as the actual sales price. This avoids misleading customers by only highlighting a discount when the comparison price is genuinely higher.
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#265004 Forward-Port-Of: odoo/odoo#262434
This fix ensures date and time fields on website pages are handled correctly when translating content. It prevents users from accidentally editing date text on blog pages, reducing the risk of save errors and broken translated content.
Original PR description
The plugin `DateTimeFieldPlugin` was only added in registry `builder-plugins`. But it should also be included in the lists `CORE_PLUGINS` of `html_builder` and `TRANSLATION_PLUGINS` of `website` (the same as `MonetaryFieldPlugin` and similar plugins) Steps to reproduce: - Open `/blog` in translate mode - Click on a date - Bug: you can edit the text (and it will likely cause an error on save) task-6226376 Forward-Port-Of: odoo/odoo#264943
This fixes a display error in Time Off accrual plans where weekly milestones could show the wrong weekday after saving. HR users now see the selected day accurately, reducing confusion when reviewing leave accrual schedules.
Original PR description
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and…
**Steps to reproduce:** 1. Install Time Off 2. Go to Accrual Plans and create a new plan with a milestone 3. Set frequency to Weekly and choose a day other than Monday (e.g., Tuesday) 4. Save and check the displayed weekday in the accrual plan level **Issue:** The displayed weekday is incorrect (e.g., shows Monday instead of Tuesday). **Cause:** Previously, the weekday value was directly displayed using: https://github.com/odoo/odoo/blob/b40184ab371f7a4708621ecf7f25b4e2daaae38d/addons/hr_holidays/views/hr_leave_accrual_views.xml#L212-L214 so no conversion was involved. Now, the value is processed using Luxon. However, the week_day field stores values from 0 (Monday) to 6 (Sunday), while Luxon expects ISO weekday numbers from 1 (Monday) to 7 (Sunday). This mismatch causes an off-by-one error during conversion. https://github.com/odoo/odoo/blob/1b3d0a3c2f794324f8b230a9ae19f097454e3bdd/addons/hr_holidays/models/hr_leave_accrual_plan_level.py#L54-L62 **Solution:** Adjust the value before passing it to Luxon by adding +1 to match ISO format. opw-6112614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259054
This fixes a typo in the Mexican localization account grouping data so it matches official SAT references. The correction helps businesses using Mexican accounting reports rely on accurate labels and classification data.
Original PR description
Source: https://www.sat.gob.mx/minisitio/NormatividadRMFyRGCE/documentos2026/rgce/anexos/Anexo24delasRGCEpara2026.pdf opw-6174385 Forward-Port-Of: odoo/odoo#262549
The point of sale receipt flow was reorganized so self-order receipts can be prepared through a shared step before printing. This lets fiscal compliance add-ons process the order when required, helping ensure receipts are handled correctly in regulated environments.
Original PR description
Extract the `getSelfOrderToPrint` logic from `printSelfOrderReceipt` in `pos_online_payment_self_order` into a dedicated overridable method on the base `PosStore`. This allows `pos_blackbox_be` to intercept the order before printing and push it to the fiscal data module when needed. task-id: 6172108 enterprise PR: https://github.com/odoo/enterprise/pull/116544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Studio report editor can now prevent users from choosing default website theme colors where they are not appropriate. This helps keep report styling consistent and avoids colors that may not render correctly in generated reports.
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 Forward-Port-Of: odoo/odoo#265358 Forward-Port-Of: odoo/odoo#264917
Quotations using the DIN5008 layout now correctly show the recurring plan for subscription orders. This prevents customers and sales teams from missing key subscription billing information on printed quotes.
Original PR description
When generating a quotation for a recurring plan, if the quotation uses the DIN5008 template, the recurring plan is not shown in the report. Steps to reproduce: ------------------- * Make sure l10n_din5008 is installed * Create a Swiss company * Go to the subscription app and create an order with a recurring plan * Print the quotation > Observation: The recurring plan is not shown in the report. Why the fix: ------------ We add a new scss rule to make sure the recurring plan is always shown in the report. https://github.com/odoo/enterprise/blob/fb2eb6cfdc4527e102dd22321975ab3f0d24b88b/sale_subscription/views/subscription_templates.xml#L7-L23 Before: <img width="790" height="677" alt="image" src="https://github.com/user-attachments/assets/342753fa-9655-41ac-a958-f94f6ae2b6c7" /> After: <img width="808" height="756" alt="image" src="https://github.com/user-attachments/assets/4ed726c5-0702-48ee-8578-8b0d2c0f4e55" /> opw-5960219
Fixes a display issue in selection pop-up dialogs where the control panel and list headers could scroll out of view. This keeps key actions and column labels visible while users browse records, making selection workflows easier and less confusing.
Original PR description
This commit fixes an issue where the SelectCreateDialog's control panel and list headers would scroll out of view, restoring the intended behavior introduced in https://github.com/odoo/odoo/pull/206433. The feature was inadvertently broken by https://github.com/odoo/odoo/pull/219972, which removed the `overflow: auto` rule from `o_content` elements outside of actions. To resolve this, the `overflow: auto` rule has been explicitly reapplied to the SelectCreateDialog content area. task-6214232 Forward-Port-Of: odoo/odoo#264965
The website editor now correctly turns uppercase and mixed-case web addresses into clickable links when users type a space. It also recognizes short domains like x.com and t.co, reducing manual cleanup when writing content.
Original PR description
### Description of the issue/feature this PR addresses: - URL_REGEX was constructed with the "i" flag, but passing a RegExp object to new RegExp(regex, "g") silently drops the original flags, leaving only "g". This caused uppercase (ODOO.COM) and mixed-case (Odoo.Com) URLs to not be converted to links when pressing space. ### Desired behavior after PR is merged: - URL_REGEX.source with explicit "gi" flags to preserve case-insensitive matching in `prepareConvertToLink`. - Allow automatic URL detection for single-character domains such as `x.com`, `t.co`, and `a.io` by relaxing the minimum domain label length in the URL regex from 2 to 1 characters. task-6199269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263255
This fixes an issue where service products could ignore a user's saved default unit of measure and switch to hours automatically. Default units are now preserved unless the product is specifically invoiced using timesheets, where a time-based unit is required.
Original PR description
A user-defined default on `product.template` Unit is not applied when the product is of type Service 1. Install Sales and Sales Timesheet 2. Go to Settings > Sales > Product Catalog and enable Units of Measure & Packagings 3. Enable debug mode 4. Go to Sales > Products, open a new product form and set unit to Days 5. In the debug menu (bug icon in the top right), select Set Default Values for Unit = Days and save 6. Reload the page 7. Set the type to Service 8. Unit changes from Days to Hours Same issue happens for `product.product` Issue: User default values are overwritten when certain conditions are met by https://github.com/odoo/odoo/blob/6955370fd2d62c83f0ea24247abf7a9e4b4ebed3/addons/sale_timesheet/models/product_template.py#L55-L57 Solution: Use the user defined default on `uom_id` except for service products that are invoiced with timesheets as they need a time unit of measure opw-6139603 Forward-Port-Of: odoo/odoo#262597
This change makes an automated test for the HTML editor more reliable by removing dependence on real browser timing and rendering behavior. It helps reduce random test failures on slower CI systems, improving development confidence without changing user-facing functionality.
Original PR description
Description of the issue this PR addresses: Previously the test relied on real timers, animation frames and simulateArrowKeyPress(), making it sensitive to browser scheduling, native selectionchange timing and CPU slowness. The test now: - use advanceTime() instead of real setTimeout() - Replace simulateArrowKeyPress() with manual selectionchange dispatch to make debounce scheduling deterministic and avoid relying on the browser's asynchronous native selectionchange dispatch. - Add patchWithCleanup + verifySteps to test actual debounce execution rather than DOM visibility timing, which is sensitive to rendering and brwoser scheduling variance. This removes timing races and stabilizes the test on slow CI workers. runbot-242466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264893
Creating a new opportunity from a contact no longer shows archived sales teams, users, tags, or stages in dropdowns. Archived opportunities remain visible in the contact’s opportunity list where appropriate, while inactive setup records stay hidden from new opportunity forms.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801
Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300This fixes an issue where opening a dropdown on the /r page could trigger an error instead of showing the menu. Dropdowns now wait until their menu is ready, improving reliability for users on affected frontend pages.
Original PR description
Steps to reproduce: - Go to the `/r` page. - Click a dropdown. => traceback Before this commit, `Dropdown.onOpened()` always observed `menuRef.el` as soon as the popover reported it was open. In frontend pages such as `/r`, the menu can still be rendering at that moment. The menu appears just after, but `MutationObserver.observe()` already received `undefined` and raised a `TypeError`. After this commit, `Dropdown.onOpened()` only starts the observer when the menu element exists. The dropdown can finish opening normally, so the menu is shown without traceback. Introduced by [1]. [1]: 7aed5b141f06
This fixes an issue in the HTML editor where selecting content starting inside a table and ending outside it did not properly select the full table. Users can now expect consistent table selection behavior regardless of which direction they drag their selection, reducing editing mistakes.
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 Forward-Port-Of: odoo/odoo#265171 Forward-Port-Of: odoo/odoo#264722
This update resolves a test failure in the WhatsApp discuss sidebar by aligning it with a recent change that now only considers active users when determining user roles. This ensures the test accurately reflects the current system behavior and prevents further disruptions to the WhatsApp functionality.
Original PR description
This PR updates the discuss sidebar testcase to match the new behavior where only active users are considered when computing main_user_id, reducing the number of available commands and fixing the failing assertion. community: https://github.com/odoo/odoo/pull/262247 task-6179486 Forward-Port-Of: odoo/enterprise#117480
This update prevents the report editor in Odoo Studio from using default theme colors, which were causing potential styling conflicts. This change improves the consistency and reliability of report design within Studio, ensuring reports are rendered correctly regardless of the underlying interface customizations.
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/264917
Forward-Port-Of: odoo/enterprise#117780
Forward-Port-Of: odoo/enterprise#117555This update fixes an issue where WhatsApp channel avatars were incorrectly displayed as 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 for WhatsApp channel communication. This improves the visual consistency and usability of the WhatsApp feature.
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) Forward-Port-Of: odoo/enterprise#117633 Forward-Port-Of: odoo/enterprise#115745
This update fixes a discrepancy in how contract types are defined within Odoo's HR modules. Specifically, the definition of `contract_type_id` was standardized across the base and Belgium-specific versions. This ensures consistent data and avoids potential errors in reporting and calculations related to employee contracts.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#117586 Forward-Port-Of: odoo/enterprise#113244
This update corrects a bug where portal users could inadvertently delete documents they didn't own. The fix ensures that portal users can only delete documents they own, preventing unintended data loss during the system's automatic trash collection process. The change simplifies the code and improves stability.
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 Forward-Port-Of: odoo/enterprise#116886