Odoo Changelog — 2026-04-14

Tuesday, April 14, 2026

22 changes · saas-18.3

Bug Fixes(22)

Resolved issues and error corrections

[FIX] sale_shopee: remove with_context called on Python file

Enterprisesaas-18.3sale_shopeeMEDIUM

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

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…

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#integration#sales

[FIX] sale_project: correct analytic distribution in multi-company context

PR #258906

Coresaas-18.3sale_projectMEDIUM

This update fixes an issue where sale orders were incorrectly using the analytic distribution account from Company A instead of the correct Company B when multiple companies were involved. The change ensures that the system accurately assigns the appropriate project and analytic account based on the company context of the sale order, improving financial reporting accuracy.

Original PR description

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
* Timesheets
* Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
* Type: Service
* Create on Order: Task
* No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.

opw-5864452

Forward-Port-Of: odoo/odoo#257776

#accounting#sales#analytics

[FIX] hr_holidays: fix left/taken balance report

PR #258907

Coresaas-18.3hr_holidaysMEDIUM

This update fixes an error in the leave balance report that was miscalculating employee leave accruals and balances, particularly when leaves spanned multiple years. The fix ensures accurate reporting by addressing timezone issues and improving how overlapping leave periods are handled, leading to more reliable leave data.

Original PR description

__ISSUE__: - FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each…

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

#reporting#leave#balance

[FIX] web_studio: fix crash when dblclick in list view

PR #113664

Enterprisesaas-18.3web_studio

This update resolves a crash that occurred when users double-clicked 'Add Custom Field' within Odoo's list views. The fix prevents the studio from opening multiple times simultaneously, ensuring a stable user experience. This improves reliability for users adding custom fields to their lists.

Original PR description

On a list view, open the optional fields dropdown. Click twice on "Add Custom Field"

Before this commit there was a crash, because opening studio while it is already opening was not protected.

After this commit, there is no crash.

Forward-Port-Of: odoo/enterprise#113299

#optional fields#list view#studio

[FIX] stock_delivery: use order currency for delivery slip prices

PR #258993

Coresaas-18.3stock_deliveryMEDIUM

This update fixes an issue where delivery slips incorrectly displayed product prices in the company currency instead of the customer's order currency. This ensures accurate pricing and invoicing for sales made in foreign currencies, improving financial reporting and customer satisfaction. The change was triggered by a previous bug fix.

Original PR description

The product value reported on delivery slips may incorrectly use the company currency instead of the order currency.

Steps to reproduce:
- Enable multi-currency and create a foreign currency
- Create a pricelist in the foreign currency
- Create and confirm a Sale Order using that pricelist
- Add a delivery via carrier (eg. Fedex)
- Confirm the delivery and generate the commercial invoice.

Issue:
The 'sale_price' on the stock move lines is taken in company currency rather than order currency.

opw-6104130

Forward-Port-Of: odoo/odoo#258875

#currency#pricing#delivery#sale order

[FIX] sale_stock: correct invoice status of SO after return of delivery

PR #258553

Coresaas-18.3sale_stockMEDIUM

This update fixes an issue where sales orders with fully returned products incorrectly displayed as 'Fully Invoiced'. The fix ensures that the invoice status accurately reflects zero delivered and invoiced quantities after a customer returns a product, preventing incorrect invoicing and improving order accuracy.

Original PR description

### Issue before this commit: When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this…

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#257942
Forward-Port-Of: odoo/odoo#254871

#sales#returns#invoicing

[FIX] sale: translate 'View Quotation' for followers

PR #258908

Coresaas-18.3sale

This update fixes a problem where action buttons in email notifications (like 'View Quotation') weren't consistently translated correctly for recipients in different languages. The change ensures the email composer uses the correct language context, resulting in fully accurate translations for all users, regardless of their language settings.

Original PR description

When sending a quotation or sales order via email to a follower, the action button in the notification (e.g., "View Quotation") was appearing partially translated in the recipient's language.

The issue came from the document description being explicitly evaluated using the sender's language context usually English) during the email composition phase, so it could not be correctly re-translated by the mail engine when rendering the final layout for a recipient using a different language.

This commit allows the language context to be dynamic when preparing the document description for the email composer, ensuring the action button is fully and accurately translated.

---
opw-5976084

Forward-Port-Of: odoo/odoo#257349
Forward-Port-Of: odoo/odoo#256077

#translation#email#notifications

[FIX] l10n_it_edi: normalize UoM's non-standard Unicode chars in XML

PR #258976

Coresaas-18.3l10n_it_ediMEDIUM

This update corrects a problem where electronic invoices generated with units of measure containing special characters (like m² or m³) failed validation by the Italian tax authority (FatturaPA). The fix ensures that units of measure are properly formatted before being included in the XML, guaranteeing compliance with the required standards and preventing invoice rejection.

Original PR description

### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#258851
Forward-Port-Of: odoo/odoo#257012

#it_edi#fatturapa#invoice#validation

[IMP] survey: always shows answers when printing participant inputs

PR #259014

Coresaas-18.3survey

This update ensures that all participant answers are now consistently included when surveys are printed, regardless of the survey type. Previously, certain survey types omitted answers, leading to inaccurate and incomplete reports. This change improves the reliability and usefulness of survey data for analysis and reporting.

Original PR description

Previously, printing surveys of type scoring_without_answers omitted participants' answers, resulting in incomplete and inconsistent reports. This commit ensures answers are always included, regardless of survey type.

Task-5407701





---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#258616

#survey#reporting#data accuracy

[FIX] pos_settle_due: no error when commercial partner is not loaded

PR #111957

Enterprisesaas-18.3pos_settle_due

This update prevents errors during invoice settlement when the commercial partner information wasn't fully loaded. By directly using the partner ID from the invoice data, the system now reliably settles invoices without interruption. This improves the stability and usability of the point-of-sale system.

Original PR description

Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice.

This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID.

opw-6023150

#invoice#settlement#pos

[FIX] website_helpdesk: handle case insensitive emails in form

PR #113576

Enterprisesaas-18.3website_helpdeskMEDIUM

This update resolves an issue where ticket submissions with emails in different capitalization formats would incorrectly create a new partner record. Now, the system correctly identifies and uses the provided email address to create the ticket, preventing duplicate partner creation and ensuring accurate ticket assignment.

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"…

**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 #113565

Enterprisesaas-18.3mrp

This update fixes an issue where search filters applied in the Manufacturing Production Scheduling (MPS) view would disappear when navigating away and returning via the breadcrumb. The fix ensures that the search state is correctly maintained, providing a more consistent and reliable user experience for filtering MPS data.

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

#MPS#search#filters

[FIX] project: prevent traceback when editing message as a portal user

PR #258669

Coresaas-18.3projectMEDIUM

This update fixes an issue where portal users couldn't edit messages within the project chatter. The fix prevents a technical error (a 'null' value issue) that occurred when attempting to edit a message, ensuring portal users have the full functionality to manage their communications.

Original PR description

## Issue When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything. ## Steps to reproduce 1. Install *Project* (`project`) 2. Create a Project P and a…

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

#project#chat#portal#user experience

[FIX] account_edi_ubl_cii: Fix import totals

PR #258989

Coresaas-18.3account_edi_ubl_ciiMEDIUM

This update resolves issues where imported BIS3 invoices didn't accurately reflect the totals from the original XML files. The code has been refactored to ensure values are correctly processed and written to the invoice, improving data accuracy. A new, more manageable testing approach is also implemented.

Original PR description

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be…

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#257710
Forward-Port-Of: odoo/odoo#250160

#accounts#EDI#UBL#invoice

[IMP] account_accountant: `partner` domain on move line query builder

PR #113719

Enterprisesaas-18.3accountantMEDIUM

This update enhances the system's ability to accurately match invoices by adding a 'partner' domain to the move line query builder. This is part of a larger effort to fix data synchronization issues related to invoice imports, ensuring more reliable financial reporting and improved data consistency within the system. It also allows the system to predict products without a linked account move line.

Original PR description

This commit is part of a bigger commit on the community side- to refactor the import code of BIS3 Invoice to fix various unsynchronized values issues.

task-id: 5058687

Forward-Port-Of: odoo/enterprise#113048
Forward-Port-Of: odoo/enterprise#108356

#invoice#accounting#data accuracy

[FIX] website_sale_renting: naive default dates

PR #113680

Enterprisesaas-18.3website_sale_renting

This update corrects a problem where default dates for website rental pricing were using the wrong timezone. The fix ensures these dates are correctly converted back to the website's timezone before being displayed, preventing pricing discrepancies for customers. This improves the accuracy of rental quotes.

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

#timezone#pricing#website

[FIX] product,sale{,_pdf_quote_builder}: update invalid links

PR #259085

Coresaas-18.3saleproductsale_pdf_quote_builder

A previous error caused a blank page when users clicked the 'Check the sample button' in the sales module. This was due to a change in the link to the sample quotation PDF. This update provides a valid link, resolving the issue and ensuring users can access the sample.

Original PR description

Currently, a 404 error is occurring when the user clicks on the Check the sample button.

**Steps to produce:**
- Install sales module without demo data.
- Click on the check a sample. its clean! button.

**Issue:**
- A 404 error occurs with a blank page.

**Cause:**
- This issue is occurring because the link to open the sample quotation pdf was changed in the Odoo documentation.

**Solution:**
- Give a valid link to open the sample quotation pdf.
- similar fix already did [here1] & [here2].

[here1]: https://github.com/odoo/odoo/commit/38431f3aef57c5b91644b4c5241f226beb917b12
[here2]: https://github.com/odoo/odoo/commit/610cea89c37454a4ddb68939333b4b363f2f81a2

opw-6099641
opw-6074953

Forward-Port-Of: odoo/odoo#258984
Forward-Port-Of: odoo/odoo#258003

#sales#pdf#quote#template

[FIX] website: hide hidden fields in form in masonry

PR #258987

Coresaas-18.3website

This update resolves an issue where hidden fields within masonry blocks in the website editor were still visible. The fix involves adding '!important' to the CSS rule that hides these fields, ensuring they are truly hidden as intended. This improves the consistency and usability of the website editor.

Original PR description

# How to reproduce - Go to the website editor - Add a Masonry block - Add a Form inner block in the Masonry block - Select any fields of the form - Set it's visibility to Hidden - Save # The problem…

# How to reproduce
- Go to the website editor
- Add a Masonry block
- Add a Form inner block in the Masonry block
- Select any fields of the form
- Set it's visibility to Hidden
- Save

# The problem
The field is still visible.

# Cause
When a field has its visibility set to hidden, it is applied the
`.s_website_form_field_hidden` CSS class which applies `display: none`.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_website_form/001.scss#L26-L28

But that CSS rule is overriden by the masonry's
`.s_masonry_block[data-vcss='001'] .row > div` CSS class.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_masonry_block/001.scss#L1-L3

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/scss/website.scss#L3246

# Proposed solution
We set `display: none` with `!important` to prevent it from being overidden.
We also need to add `!important` to its edit mode
counter-part so that the field is still visible in that mode.

opw-6038955

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#256100

#website#masonry#form#UI

[FIX] mail: prevent composer focus loss with active mobile menus

PR #258974

Coresaas-18.3mailMEDIUM

This update resolves an issue where the chat composer on mobile devices would become unresponsive when the navigation menu was open. The fix prevents the navigation menu from stealing focus from the composer, ensuring users can consistently access and use the chat feature. This improves the mobile user experience.

Original PR description

**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.…

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.

https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef

Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops propagation of the composer `focusin` event so the Offcanvas focus trap does not steal focus from the composer.

Thread focus state can also depend on `focusin` bubbling from the composer to the thread component. Since that bubbling is now stopped, the shared thread focus state is tracked through the JS models instead:

- composer focus updates the related thread through `composer.thread`
- thread component focus updates the thread model directly.

This keeps the composer accessible while preserving thread focus behavior.

Related: https://github.com/odoo/enterprise/pull/113763
Task-5954657

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#258713
Forward-Port-Of: odoo/odoo#250294

#mobile#chat#composer

[FIX] ai: forward focus event in composer patch

PR #113763

Enterprisesaas-18.3discuss

This update resolves a technical bug in the AI composer that was causing crashes. The fix ensures that focus events are correctly passed to the base handler, maintaining stability and functionality. This change was necessary due to an update in how the mail composer handles focus events.

Original PR description

**Purpose of this PR:**

The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler.

This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered.

This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract.

Related: odoo/odoo#258974
Task-5954657

#AI Composer#Stability#Bug Fix

[FIX] partner_autocomplete: fix not deterministic test

PR #259170

Coresaas-18.3partner_autocomplete

A recent test was unreliable due to inconsistent results, impacting the accuracy of partner data. This fix ensures the test is deterministic, guaranteeing consistent results regardless of changes to Belgium company IDs. This improves the overall stability and reliability of the partner autocomplete feature.

Original PR description

The newly added test `test_enrich_by_duns_with_incorrect_vat` was not deterministic
https://github.com/odoo/odoo/commit/9c89391848ed00de91f3caa8ba6876ec0002d064
This commit ensure the consistency if the id of belgium change

opw-6030164

#partner#autocomplete#test

[FIX] html_editor: color picker test by selecting solid tab

PR #259169

Coresaas-18.3html_editor

This update resolves a bug in the HTML editor's color picker that was causing tests to fail. The issue stemmed from different color tab behavior between the community and enterprise versions of Odoo. This change ensures consistent test results across all Odoo environments.

Original PR description

Purpose of this PR:

Color picker opens different tabs by default because inline code uses a custom color `-900`. In community it opens the custom tab, while in enterprise it opens the solid tab.

This caused the test to fail in community when selecting a color from the solid tab.

runbot-242556

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#html_editor#color picker#test