On mobile, opening My Profile or Preferences now closes the burger menu instead of leaving it over the page. This prevents the profile screen from appearing hidden in the background and makes account settings easier to access.

Pad: https://pad.odoo.com/p/r.5ee0064ab08e266dba260942c5d54e58
Task: https://www.odoo.com/web?#id=2152160&action=327&model=project.task&view_type=form&menu_id=4720

Suggested message recipients now refresh immediately after a user saves changes to a record, such as updating an email address. This prevents outdated recipient information from appearing in the message composer and reduces the need for users to reload or switch composer modes.

Task:https://www.odoo.com/web#id=2089816&action=333&active_id=1251&model=project.task&view_type=form&menu_id=4720

Pad: https://pad.odoo.com/p/r.8da15de40cf2d0a46dd9e9c9107c0538


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

This update tidies the displayed names of Chinese tax records so they are clearer and more consistent for users. It helps accounting teams identify the correct taxes more easily without changing tax behavior or calculations.

Description of the issue/feature this PR addresses:

task-2157487

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

Fixes an issue in the website editor where selected cover layout properties could fail to save because the wrong menu item was being read. This helps website editors keep their chosen cover settings reliably after making changes.

In 2cc8316c669, the cover properties snippet option was refactored to
using a single data attribute per select instead of repeating it on
every button inside of it. After selecting an option, the corresponding
data attribute would be set on the cover container by finding the
currently active button and copying its select class attribute.

However, because of an oversight, instead of finding the currently active
button inside the select, the option would find any active item inside
of the select, and because the select is always open when a button
inside is clicked, the first active item inside of the select is its
toggler.

This commit fixes that by increasing the specificity of the selector
that finds the active button to only find buttons, and not the
select-menu toggler.

This fixes how manufacturing work order quality check data is prepared so filters work reliably. It also restores the expected company-specific filtering behavior, helping users see the correct quality points in multi-company setups.

Commit 0e749c1 introduced computed one2many `component_ids` as a set.
A one2many computed should be returned as list to be used in a domain
instead of set.

On mobile, opening My Profile or Preferences now closes the burger menu instead of leaving it on top of the page. This prevents the profile screen from appearing hidden in the background and makes account settings easier to access.

Pad: https://pad.odoo.com/p/r.5ee0064ab08e266dba260942c5d54e58
Task: https://www.odoo.com/web?#id=2152160&action=327&model=project.task&view_type=form&menu_id=4720

This update fixes payroll-related tests and ensures the taxable benefit for company cars in Belgian payroll is calculated using the payslip date. This helps keep payroll results accurate and improves reliability of automated checks.

When the ecommerce module is installed, the partner field's context is overwritten, which causes some features to be lost, e.g. showing the customer address. This commit fixes the above by merging the content of both contexts. The original context is the following: https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/sale/views/sale_views.xml#L274 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo

When the ecommerce module is installed, the partner field's context is overwritten, which causes some features to be lost, e.g. showing the customer address.

This commit fixes the above by merging the content of both contexts.

The original context is the following:
https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/sale/views/sale_views.xml#L274

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

Forward-Port-Of: odoo/odoo#42401

Steps to reproduce: 1. Open 'Project' on mobile 2. You can scroll x while the content fit the screen. This issue occured because of negative margins on 'o_kanban_manage_toggle_button' class. In general, using negative margins should be avoided. So in this commit we simply avoid to have negative margins by removing unwanted borders. It keeps the same design. Similar issue: https://github.com/odoo/enterprise/commit/805ab4d4a329c0fdf7d1cade6c5d7e8428f3a634 Description of the issue

Steps to reproduce:
1. Open 'Project' on mobile
2. You can scroll x while the content fit the screen.

This issue occured because of negative margins on
'o_kanban_manage_toggle_button' class.
In general, using negative margins should be avoided.

So in this commit we simply avoid to have negative margins by
removing unwanted borders. It keeps the same design.

Similar issue:
https://github.com/odoo/enterprise/commit/805ab4d4a329c0fdf7d1cade6c5d7e8428f3a634

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#42512

When an invoice is duplicated, the `invoice_date` is not carried over. If the field is not set, it will be set at posting at the current date. 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#42578

When an invoice is duplicated, the `invoice_date` is not carried over.
If the field is not set, it will be set at posting at the current date.

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#42578

missing bit from rev[0] and [1] [0] 7ef11e3 [1] d6c8c34ef6539dad110f1e502eaee2c03d968797 Forward-Port-Of: odoo/odoo#42563

missing bit from rev[0] and [1]

[0] 7ef11e3
[1] d6c8c34ef6539dad110f1e502eaee2c03d968797

Forward-Port-Of: odoo/odoo#42563

Task: https://www.odoo.com/web#id=2165919&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.542db01edfbbe6a8e77c7a99c7d926ab 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#42562

Task: https://www.odoo.com/web#id=2165919&action=327&model=project.task&view_type=form&menu_id=4720

Pad: 
https://pad.odoo.com/p/r.542db01edfbbe6a8e77c7a99c7d926ab
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#42562

Before this commit, when the domain alias was set (e.g. my_domain.com), the reply-to and the reply-path were filled with default values using this domain (e.g. reply-to : catchall@my_domain.com and reply-path: Return-Path: bounce+number@my_domain.com) Now, both are filled with the sender email. Fine-tuning of 66c5053 opw-2127407 opw-2161942 Forward-Port-Of: odoo/odoo#42604 Forward-Port-Of: odoo/odoo#42572

Before this commit, when the domain alias was set (e.g. my_domain.com),
the reply-to and the reply-path were filled with default values using
this domain (e.g. reply-to : catchall@my_domain.com and reply-path:
Return-Path: bounce+number@my_domain.com)

Now, both are filled with the sender email.

Fine-tuning of 66c5053

opw-2127407
opw-2161942

Forward-Port-Of: odoo/odoo#42604
Forward-Port-Of: odoo/odoo#42572

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#42577

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#42577

When creating a customer on a repair order form view, it isn't considered as one. An adapted context key is needed to make sure the new res.partner is correctly saved as "customer". Fixes #42449 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42519 Forward-Port-Of: odoo/odoo#42462

When creating a customer on a repair order form view, it isn't considered
as one.  An adapted context key is needed to make sure the new res.partner
is correctly saved as "customer".

Fixes #42449

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

Forward-Port-Of: odoo/odoo#42519
Forward-Port-Of: odoo/odoo#42462

In 404fa81640 when an element that was the root of the view was saved it would override its element original attributes. In this commit, the blacklist of field we should not set is replaced by a whilelist of fields that should be set which contains only those known to have been an issue. opw-2122947 Forward-Port-Of: odoo/odoo#42547 Forward-Port-Of: odoo/odoo#42545

In 404fa81640 when an element that was the root of the view was saved
it would override its element original attributes.

In this commit, the blacklist of field we should not set is replaced by
a whilelist of fields that should be set which contains only those known
to have been an issue.

opw-2122947

Forward-Port-Of: odoo/odoo#42547
Forward-Port-Of: odoo/odoo#42545

Fine-tunning of 42eec88e5da164e4930c48113109f2c8d4b73da3 Before this commit, the assets were not found when the user is connected in mode debug assets in a multi-website and multi-company. This occurs because the attachments (assets) were created only for the first website accessed, and cannot be loaded when trying to access the second website. Now, the attachments are created for each website accessed and can be loaded withtout problems. Forward-Port-Of: odoo/odoo#42529 Forward-Port-

Fine-tunning of 42eec88e5da164e4930c48113109f2c8d4b73da3

Before this commit, the assets were not found when the user is connected
in mode debug assets in a multi-website and multi-company. This occurs
because the attachments (assets) were created only for the first website
accessed, and cannot be loaded when trying to access the second website.

Now, the attachments are created for each website accessed and can be
loaded withtout problems.

Forward-Port-Of: odoo/odoo#42529
Forward-Port-Of: odoo/odoo#38942

Commit d86c2c5 removed the multi-company partner rule because it interfered with the users rule. Indeed, interference between the user's default company and its corresponding partner's company made it possible to have users that were basically unselectable in relational fields if you were not viewing more than one company at the same time. However, this generates a lot of frustrations and tickets for Odoo users, since having everything shared by default is annoying and a clear departure

Commit d86c2c5 removed the multi-company partner rule because it
interfered with the users rule. Indeed, interference between the user's
default company and its corresponding partner's company made it possible
to have users that were basically unselectable in relational fields if
you were not viewing more than one company at the same time.

However, this generates a lot of frustrations and tickets for Odoo
users, since having everything shared by default is annoying and a clear
departure from the expected behaviour.

This commit tries to mitigates this fix's side-effects by re-introducing
the multi-company rules but by not applying it to partners who are linked
to a non-share user (basically, any partner who has a user that is not
a portal user). That way, customers and vendors remain filtered by the
multi-company rules and only partners of internal users bypass the rule.
This is still a side-effect, and might raise a few eyebrows (why is this
partner visible even though it is in another company?), but the
trade-off seems to be worth it since it fixes the original issue with a
far smaller behaviour change.

Fixes #41720.

Forward-Port-Of: odoo/odoo#42511

Steps to reproduce: -install sales -try to import a product file with volumes set to scientific notation (9.2e-05 for example) Misc: you can force excel and openoffice to use full decimal notation by using the CONCATENATE() function on the problematic fields/column Previous behavior: scientific notation is not recognized by the base_import module and raises a small warning Current behavior: scientific notation is converted to decimal notation on the fly opw-2162353 Forward-P

Steps to reproduce:
-install sales
-try to import a product file with volumes set to scientific notation
(9.2e-05 for example)

Misc:
you can force excel and openoffice to use full decimal notation by
using the CONCATENATE() function on the problematic fields/column

Previous behavior:
scientific notation is not recognized by the base_import module
and raises a small warning

Current behavior:
scientific notation is converted to decimal notation on the fly

opw-2162353

Forward-Port-Of: odoo/odoo#42394

Activate multicurrency. The default currency for the company should be USD. Make an invoice in EUR, with taxes, save and create the invoice. The tax section will display the correct tax amount but the displayed amount on which the tax should be applied is wrong: it's displayed the amount in the company currency rather than the invoice currency. Adding a _convert step to restore the correct currency since that information does not appear to be saved in the database opw-2161039 --

Activate multicurrency. The default currency for the company should be
USD. Make an invoice in EUR, with taxes, save and create the invoice.

The tax section will display the correct tax amount but the displayed
amount on which the tax should be applied is wrong: it's displayed the
amount in the company currency rather than the invoice currency.

Adding a _convert step to restore the correct currency since that
information does not appear to be saved in the database

opw-2161039

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

Forward-Port-Of: odoo/odoo#42463

When `invoice_sequence_number_next` is set in [1], the move date is not taken into account to find a corresponding `ir.sequence.date_range` in [2]. We use the current date instead. However, when the move is posted we use its date to find the `ir.sequence.date_range` [3]. This leads to an inconsistency: we set `invoice_sequence_number_next` on the `ir.sequence.date_range` of the current date, but at posting we use the `ir.sequence.date_range` of the move date. The fix is to take into

When `invoice_sequence_number_next` is set in [1], the move date is not
taken into account to find a corresponding `ir.sequence.date_range` in
[2]. We use the current date instead.

However, when the move is posted we use its date to find the
`ir.sequence.date_range` [3]. This leads to an inconsistency: we set
`invoice_sequence_number_next` on the `ir.sequence.date_range` of the
current date, but at posting we use the `ir.sequence.date_range` of the
move date.

The fix is to take into account the move date when we set
`invoice_sequence_number_next`.

[1] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/tests/test_account_move_in_invoice.py#L829
[2] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/models/account_move.py#L1153
[3] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/models/account_move.py#L2096

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#42557

Changing the background color was not working anymore because 'o_mail_snippet_general' having a background color white. while bg-* colors are applied on a parent of 'o_mail_snippet_general' Forward-Port-Of: odoo/odoo#42265

Changing the background color was not working anymore
because 'o_mail_snippet_general' having a background color white.
while bg-* colors are applied on a parent of 'o_mail_snippet_general'

Forward-Port-Of: odoo/odoo#42265

- Create products A & B - Create a BOM: 1 unit of A to produce 1 unit of B - Create a Route which applies on products with the following Rule: Action: Push To Operation Type: YourCompany: Internal Transfers Source Location: WH/Stock Destination Location: WH/Stock/Shelf 1 Automatic Move: Automatic No Step Added - Apply the route to A - Create a MO for B, validate - Create an Unbuild Order for the MO created, validate The component (A) has a `stock.move` to WH/Stock/Shelf 1

- Create products A & B
- Create a BOM: 1 unit of A to produce 1 unit of B
- Create a Route which applies on products with the following Rule:
  Action: Push To
  Operation Type: YourCompany: Internal Transfers
  Source Location: WH/Stock
  Destination Location: WH/Stock/Shelf 1
  Automatic Move: Automatic No Step Added
- Apply the route to A
- Create a MO for B, validate
- Create an Unbuild Order for the MO created, validate

The component (A) has a `stock.move` to WH/Stock/Shelf 1 but a
`stock.move.line` to WH/Stock.

This is because the `stock.move.line` is created when the quantity is
set in:

https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/mrp/models/mrp_unbuild.py#L151

However, the `_run_push`, which only changes the `stock.move` location,
is called on `_action_confirm` during the call to `_action_done`:

https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/mrp/models/mrp_unbuild.py#L152

The solution is to call `_action_confirm` before the creation of the
`stock.move.line`.

opw-2156132

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#42416
Forward-Port-Of: odoo/odoo#42413

Replace options.toolbar by options.airPopover if options.toolbar is undefined This change allows to edit the body even in debug mode and to display the according toolbar. task-2126203 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#42345

Replace options.toolbar by options.airPopover if options.toolbar is undefined
This change allows to edit the body even in debug mode and to display the according toolbar.

task-2126203

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#42345

### Issue - Install Studio - Edit/Create a form view - Add tabs - Add columns in the tab page then delete both column - A big container appear - Try to add something below it It always go under the line (out of the page) ### Cause There is no hook at the end of the tab page when you have a big container. ### Solution Modify _renderTabPage and allow to add a hook a the end when you have a big container **OPW-2124233** Forwar

### Issue

    - Install Studio
    - Edit/Create a form view
    - Add tabs
    - Add columns in the tab page then delete both column
    - A big container appear
    - Try to add something below it

    It always go under the line (out of the page)

### Cause

    There is no hook at the end of the tab page when you have
    a big container.

### Solution

    Modify _renderTabPage and allow to add a hook a the end
    when you have a big container

**OPW-2124233**

Forward-Port-Of: odoo/enterprise#7469
Forward-Port-Of: odoo/enterprise#7345

OPW 2162584 Forward-Port-Of: odoo/enterprise#7486 Forward-Port-Of: odoo/enterprise#7414

OPW 2162584

Forward-Port-Of: odoo/enterprise#7486
Forward-Port-Of: odoo/enterprise#7414