Odoo Changelog — 2026-04-14

Tuesday, April 14, 2026

6 changes · saas-18.2

Bug Fixes(6)

Resolved issues and error corrections

[FIX] sale_shopee: remove with_context called on Python file

Enterprisesaas-18.2sale_shopeeMEDIUM

This update resolves an error preventing customers from connecting or refreshing their Shopee accounts through the `sale_shopee` module. The fix corrects a technical issue within the module's code that was causing errors during the authorization process. New tests have been added to ensure this functionality remains stable.

Original PR description

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

Forward-Port-Of: odoo/enterprise#113081

#Shopee#Sales#Integration

[FIX] website_helpdesk: handle case insensitive emails in form

PR #113554

Enterprisesaas-18.2website_helpdesk

This update resolves an issue where ticket submissions with emails in different capitalization (e.g., 'partner@mail.com' vs. 'Partner@mail.com') would incorrectly create a new partner. Now, the system correctly identifies and uses the submitted email to create the ticket without unnecessary partner creation.

Original PR description

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393

#helpdesk#ticket#email

[FIX] mrp_mps: keep search state when returning to initial view

PR #113555

Enterprisesaas-18.2mrp

This update fixes an issue where users would lose their search filter selections in the MRP Planning view (MPS) after navigating away and returning. The fix ensures that search filter state is correctly maintained, improving the user experience and allowing users to quickly resume their planning tasks. This resolves a minor usability problem.

Original PR description

Issue:
In the MPS view, when the user sets a search filter, navigates away and then returns via the breadcrumb, the search filters that were applied are gone.

This happened because the MPS client action was not passing `globalState` to the `WithSearch` component.

Fix by passing `globalState` in `withSearchProps`.

task-5368078

Forward-Port-Of: odoo/enterprise#113183
Forward-Port-Of: odoo/enterprise#113125

#usability#search#mrp

[FIX] web_studio: create activity filters when use_mail is checked

PR #113691

Enterprisesaas-18.2mailweb_studioMEDIUM

This update fixes a bug in Odoo Studio that prevented users from correctly filtering activities based on their status (past, today, future) when the 'use_mail' option was enabled. The fix adds necessary filters to the search view, ensuring users can easily manage and view activities related to their records.

Original PR description

Steps to reproduce
==================

- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future

Cause of the issue
==================

https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77

For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present

Solution
========

We add them to the search view. They are all pretty much implemented the same way in every model.

opw-6069150

Forward-Port-Of: odoo/enterprise#113011

#studio#activity#filter#mail

[FIX] website_sale_renting: naive default dates

PR #113662

Enterprisesaas-18.2website_sale_renting

This update fixes an issue where website date defaults were using the wrong timezone. The change ensures dates are correctly converted back to the website's timezone before displaying them to users, improving the accuracy of rental and sales information. This ensures consistent and reliable date presentation.

Original PR description

should be converted from website tz as they're going to be converted back by the front-end to that specific timezone.

Runbot issue: 234756

Forward-Port-Of: odoo/enterprise#102153

#dates#timezone#website

[FIX] timesheet_grid: prevent timer hotkey from intercepting modal events

PR #113126

Enterprisesaas-18.2timesheet

A bug was preventing users from deleting timesheets when a confirmation dialog was open. This was caused by the timer incorrectly responding to the Enter key. This update ensures the delete confirmation dialog functions as expected, allowing users to properly remove timesheet entries.

Original PR description

When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key.

Add a `.modal` check consistent with the grid renderer's onKeyDown.


Steps to reproduce:
1) Open timesheet list view
2) Select a record and delete it
3) When the confirmation dialog opens, hit ENTER key

Current behavior: The Timer starts recording timesheet
Expected behavior: The record should be deleted

For ref: https://youtu.be/tzm_3RNe1ig

Forward-Port-Of: odoo/enterprise#112583

#timesheet#deletion#UI

Currently, customers report errors when connecting or refreshing a Shopee account through the `sale_shopee` module. **Steps to reproduce:** - Install and configure the `sale_shopee` module - Attempt to connect a Shopee account via the onboarding flow - Complete the authorization process **Observed behavior:** An error is raised during the authorization callback, preventing the Shopee account from being connected or refreshed. **Root cause:** In `onboarding.py`, the `shopee_return_from_authorization` controller incorrectly uses `utils.with_context(authorization_code=code)`. Since `utils` is an imported Python module, calling `with_context` on it attempts to set the context on the module itself rather than on a model instance, which raises an error. **Solution:** Move the `with_context` call from the `utils` module to the `temp_shop` record, which is the appropriate model instance that needs the context. Additionally, this commit adds regression tests for the controller to prevent future regressions, as this functionality was previously untested. opw-6092524 Forward-Port-Of: odoo/enterprise#113081

**Steps to reproduce** - Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123"). - Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number. Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated. Behavior after this fix: no partner is created. **Causes** - the partner search was case sensitive - the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to `_mail_find_partner_from_emails` (case-insensitive) Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`). Also, avoid allowing modifying existing partner's phone via this form. opw-5914064 Forward-Port-Of: odoo/enterprise#109393

Issue: In the MPS view, when the user sets a search filter, navigates away and then returns via the breadcrumb, the search filters that were applied are gone. This happened because the MPS client action was not passing `globalState` to the `WithSearch` component. Fix by passing `globalState` in `withSearchProps`. task-5368078 Forward-Port-Of: odoo/enterprise#113183 Forward-Port-Of: odoo/enterprise#113125

Steps to reproduce ================== - Install studio - Create a new app - Create a new model - Keep the Chatter toggled (use_mail) - Exit studio - Create three records, one with an activity in the past, one today and one in the future - Click on the clock status icon in the top right - There should be a section with the new model - Click on 1 Late => every records is displayed - Same for Today and Future Cause of the issue ================== https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77 For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present Solution ======== We add them to the search view. They are all pretty much implemented the same way in every model. opw-6069150 Forward-Port-Of: odoo/enterprise#113011

When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#112583