This update adds consistent internal names to many page sections across Odoo screens. It does not change what users see, but it makes future customizations and upgrades safer and easier for implementation teams.

Description of the issue/feature this PR addresses: Easier xpath expressions
 
Current behavior before PR: Quite some pages have no `name` and no `id` set on the page making it rather annoying/unsafe to xpath into.

Desired behavior after PR is merged: All pages have a `name` element so developers can do easy and safe xpath expressions 🎉 




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

This update makes the journal selection on account payments more consistent by removing a dynamic filtering rule. It should make payment entry behavior easier to understand and maintain, with limited impact for day-to-day users.

Old crap should be more coherent, though by and large it's still crap.

Task 2115472

Split from #40957

Payment forms now better keep the selected payment method aligned with the chosen journal. If the current method is no longer valid after changing the journal, Odoo automatically switches to an appropriate default or available method, reducing incorrect payment setup.

Task 2115472

Split from #40957

Payment forms now use a simpler setup for choosing partner bank accounts by removing an unused dynamic filter hook from the standard screen. This reduces unnecessary complexity in the accounting workflow while preserving customization options for implementations that override the behavior.

`possible_bank_partner_ids` is an override hook, it's not useful in
and of itself.

Task 2115472

Split from #40957

This update simplifies how account options are determined on accounting move lines by replacing unnecessary dynamic filtering with a static setup. It should make the accounting screens easier to maintain while preserving the intended choices for users.

The dynamic domain really seems wholly unnecessary (though the static
one does require adding a field to a bunch of views)

Task 2115472

Split from #40957

The register payment wizard now uses the invoices already available to it instead of re-reading the same records from the screen context. This makes journal selection more consistent with company defaults and reduces confusing behavior when registering payments.

It seems very strange that we'd want to use active_ids as invoices to
work with when when we already have invoices available, and these are
browsed / converted from the active_ids if they weren't provided
explicitly.

There's also an odd divergence between the filtering on the journal's
company here and in the default_get too: in the default_get we get a
journal in the user's company but then we only allow selecting a
journal from the invoices' company...

Task 2115472

Split from #40957

The website editor now has a cleaner way to decide which options and controls appear in the left panel. This helps reduce visual flicker and makes the editing experience more consistent while giving future improvements a simpler foundation.

Partner selection in accounting now uses the user's currently active company directly. This makes company-specific accounting behavior clearer and more reliable in multi-company setups, with minimal visible change for users.

Pretty straightforward so long as you know `current_company_id` is the
currently active company for the user, which is exactly what we need.

Task 2115472

Split from #40957

Batch payment screens were updated to stay compatible with changes in how payment methods are filtered. This helps ensure users continue to see the right payment method choices when creating or managing batch payments.

Cf odoo/odoo#41868

This update simplifies how approval request filters are defined in the Approvals app. It reduces reliance on dynamic filtering logic, making the approval process more predictable and easier to maintain without changing the core user workflow.

Task 2115472

This update adjusts how bank accounts are selected when preparing batch and SEPA payments. It supports a related change in the main accounting app, helping keep payment workflows consistent and reducing selection issues for users.

Cf odoo/odoo#41872

The Documents app now makes lock status easier to understand. Users can no longer try to unlock a document locked by someone else from the inspector, while list and kanban views use a simpler, consistent lock icon.

In the document inspector, the lock button is now
disabled if the document is locked by someone else.

In the Kanban and List view, the icon distinction
between a document locked by someone else or the
current user has been removed.

Task: #2155063

Batch payment screens were adjusted to stay aligned with changes in how payment journals are selected. This helps keep payment processing workflows consistent and avoids confusion when choosing journals for batch payments.

Cf odoo/odoo#41873

Fixes an issue where using the Print button in Surveys could trigger an error instead of producing the expected output. This helps users reliably print survey content without interruption.

This fix adjusts how Field Service tasks are filtered in project views to avoid unreliable behavior caused by dynamic rules. It helps users see the right task options more consistently when working with Field Service projects.

Task 2115472

The helpdesk stock return flow has been simplified by removing a dynamic filtering rule that was difficult to maintain without changing behavior. This helps preserve the existing way returns are selected while reducing complexity in the helpdesk stock process.

Task 2115472

Mass mailing and SMS mailing setup fields now keep their values through stored editable computations instead of temporary form-change logic. This should preserve the same user experience while making mailing configuration more consistent, easier to maintain, and better covered by tests.

PURPOSE

Try to move from onchange / default_get to stored editable computed fields.
Normally behavior should be the same (computed or set by user), with support
in create / write + onchange without additional code.

SPECIFICATIONS

Update classic fields with onchange to stored editable computed fields. It
means their value will come either from manual user input, either computed
based on triggers. Purpose is to remove all onchange and default_get when
possible.

Clean fields definition inconsistencies, like default / required on computed
fields. Indeed computed fields should always have a value, maybe coming from
user input. They should not have default / required that are attributes for
classic fields.

Mailing domain computation is also cleaned and is now reset once the
mailing domain is changed. Indeed trying to keep a previous domain
based on try / except has no meaning from functional point of view. If model
changes then domain should change as it is a business record, not just a
technical domain to try to apply.


Finally add some tests to help develop and maintain those fields computation.

LINKS

Task ID 2088577
PR #41877
Enterprise PR odoo/enterprise#7278

Mass mailing settings are now handled consistently at the data level instead of only when users edit forms. This reduces the risk of incorrect mailing behavior when records are created or updated outside the standard screens, including event and SMS mailing flows.

onchange acts only in views, to avoid future issue about that
we cover the onchange behaviour with computed storable and not
readonly fields.

task-2088577

Marketing automation fields now rely on stored editable values that can be automatically calculated or manually set, replacing older form-only update logic. This should keep user behavior the same while making campaign and SMS activity data more consistent across creation, editing, and automation flows.

PURPOSE

Try to move from onchange / default_get to stored editable computed fields.
Normally behavior should be the same (computed or set by user), with support
in create / write + onchange without additional code.

SPECIFICATIONS

Update classic fields with onchange to stored editable computed fields. It
means their value will come either from manual user input, either computed
based on triggers. Purpose is to remove all onchange and default_get when
possible.

Clean fields definition inconsistencies, like default / required on computed
fields. Indeed computed fields should always have a value, maybe coming from
user input. They should not have default / required that are attributes for
classic fields.

LINKS

Task ID 2088577
PR #7278
Community PR odoo/odoo#41877

Marketing automation field updates now work consistently beyond screen-based editing. This reduces the risk of inconsistent campaign or SMS activity data when records are created or updated through other processes.

The onchange decorator works only with views,
to avoid future issues with that, we cover the
onchange behavior with computed storable and
writable fields (model level) for marketing_automation(_sms).
    
task-2088577

Sign CLA -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41716

Sign CLA




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

Forward-Port-Of: odoo/odoo#41716

The slide.slide and slide.channel "_compute_slides_statistics" methods do not always assign a default value for the "total_slides" field. This can cause some CacheMiss and seem related to nondeterministic errors on the runbot. Task#2123711 Runbot build error ID 247 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 slide.slide and slide.channel "_compute_slides_statistics" methods do not
always assign a default value for the "total_slides" field.

This can cause some CacheMiss and seem related to nondeterministic errors on
the runbot.

Task#2123711
Runbot build error ID 247

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

To update the odoo-master Transifex project Forward-Port-Of: odoo/odoo#41907

To update the odoo-master Transifex project

Forward-Port-Of: odoo/odoo#41907

### Issue - Export all english translation - Import the file and override existing terms ### Cause When importing, we try to insert the translation if it doesn't exists. If it exists, we do an update via a "onconflict" rule. This update can be done only one time but in the values to import there are things like: ``` ( 'Account', # translation 8, # numbers of duplicate ['account', 'account', 'account', 'account', # modules 'account', 'account_ponto', 'account_yodlee',

### Issue

- Export all english translation
- Import the file and override existing terms

### Cause

When importing, we try to insert the translation if
it doesn't exists. If it exists, we do an update via
a "onconflict" rule.

This update can be done only one time but in the values to import
 there are things like:
```
( 'Account', # translation
  8, # numbers of duplicate
  ['account', 'account', 'account', 'account', # modules
  'account', 'account_ponto', 'account_yodlee', 'payment']
)
```

### Solution

It will not be fixed in stable to avoid performances issues.
Instead, we will display a clearer error message.

As it's a `psycopg2.ProgrammingError`, the cursor is aborted
and we can no longer use it to retrieve translations. This
is why I use a new cursor in the `__get_source` method.

**OPW-2150610**

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

Forward-Port-Of: odoo/odoo#41906
Forward-Port-Of: odoo/odoo#41639

- Create a product A, FIFO & Automated - Create a SO, deliver and invoice - Post the invoice - Reset it to draft - Post the invoice again The COGS lines are duplicated. Unlike the other lines, the COGS lines are only added at posting. This is done in case several invoices are generated in draft, but validated in an arbitrary order. We clean up the COGS lines when resetting to draft. opw-2153695 opw-2152465 Description of the issue/feature this PR addresses: Current behav

- Create a product A, FIFO & Automated
- Create a SO, deliver and invoice
- Post the invoice
- Reset it to draft
- Post the invoice again

The COGS lines are duplicated.

Unlike the other lines, the COGS lines are only added at posting. This
is done in case several invoices are generated in draft, but validated
in an arbitrary order.

We clean up the COGS lines when resetting to draft.

opw-2153695
opw-2152465

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

The filename can be obtained in 3 ways when downloading a file, in order: - by the filename argument - by the filename_field argument - a default one is computed as backup. In the last case, there is by construction no file extension. The filename is made from the record's model name, id and field. However the model name almost certainly contains a ".", which is the standard extension separator for filenames. As a result <model_name_end-id-field> is considered to be the existing exten

The filename can be obtained in 3 ways when downloading a file, in order:
- by the filename argument
- by the filename_field argument
- a default one is computed as backup.

In the last case, there is by construction no file extension.
The filename is made from the record's model name, id and field.
However the model name almost certainly contains a ".",
which is the standard extension separator for filenames.
As a result <model_name_end-id-field> is considered to be the existing
extension, so we don't try to guess it from the mimetype.

To keep the existing default filename convention, we always add the
guessed extension in this case.

opw 2149612

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#41667
Forward-Port-Of: odoo/odoo#41560

When you are printing the sale details report in point_of_sale, there are no payment method shown. It is caused by the changing of model from statement lines to pos payment. So we ar now checking the pos payment instead of the statement lines. ISSUE_ID: 41815 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 Forw

When you are printing the sale details report in point_of_sale, there
are no payment method shown.

It is caused by the changing of model from statement lines to pos
payment.

So we ar now checking the pos payment instead of the statement lines.

ISSUE_ID: 41815

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

### Issue - Install e-commerce - Add stripe as payment acquirer - Go in website > shop - Add something in your cart and process checkout - In developer tools > network set online to slow 3g - Spam the pay now button - Go in Website > Configuration > Ecommerce > Payment Transactions Multiple transactions have been created for your order. ### Cause The pay now button doesn't stay disabled during the payment process. ### Solution Disable the button and enable it only when th

### Issue

- Install e-commerce
- Add stripe as payment acquirer
- Go in website > shop
- Add something in your cart and process checkout
- In developer tools > network set online to slow 3g
- Spam the pay now button
- Go in Website > Configuration > Ecommerce > Payment Transactions

Multiple transactions have been created for your order.

### Cause

The pay now button doesn't stay disabled during the payment process.

### Solution

Disable the button and enable it only when the process is done.

**OPW-2148899**

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

Forward-Port-Of: odoo/odoo#41860
Forward-Port-Of: odoo/odoo#41823

Install POS, create a product available in POS, tracked by Serial Number. Add some units of product to the inventory. Open the POS session, sell the demo item, close the session (do not end the session, just close the interface). Go to POS orders, select the last order and click on "Return Products", the refund will be created with all the products Edit the refund. The user will be able to change fields of the refund such as price, discount, quantity, etc but not the lot ids which wil

Install POS, create a product available in POS, tracked by Serial
Number.
Add some units of product to the inventory.
Open the POS session, sell the demo item, close the session (do not end
the session, just close the interface).
Go to POS orders, select the last order and click on "Return Products",
the refund will be created with all the products
Edit the refund.

The user will be able to change fields of the refund such as price,
discount, quantity, etc but not the lot ids which will be fixed. Adding
the possibility to edit such field allow to aumatically manage inventory
on refund

opw-2152776

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

Forward-Port-Of: odoo/odoo#41846

On a Sale order having customer with bank information available create an invoice (down payment). Bank informations will not be available. This append because the company_id is not provided to the create and bank informations will not be available https://github.com/odoo/odoo/blob/12.0/addons/account/models/account_invoice.py#L549 opw-2153810 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41794 Forward-Port-Of:

On a Sale order having customer with bank information available create
an invoice (down payment).

Bank informations will not be available.

This append because the company_id is not provided to the create and
bank informations will not be available
https://github.com/odoo/odoo/blob/12.0/addons/account/models/account_invoice.py#L549

opw-2153810

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

Forward-Port-Of: odoo/odoo#41794
Forward-Port-Of: odoo/odoo#41612

On the website when you modified a string with not much change, we modify the translation source so they are not dropped. But we also do it for an en_US translation, so if we have a translation: lang=en_US/src=helloworld/value=helloworld if we change `helloworld` by `helloworld!` the translation would become: lang=en_US/src=helloworld!/value=helloworld which would make it seem like the change did not work at all. Without change, modifed test fail on second: self.assertEqual(view.with_

On the website when you modified a string with not much change, we
modify the translation source so they are not dropped.

But we also do it for an en_US translation, so if we have a translation:

lang=en_US/src=helloworld/value=helloworld

if we change `helloworld` by `helloworld!` the translation would become:

lang=en_US/src=helloworld!/value=helloworld

which would make it seem like the change did not work at all.

Without change, modifed test fail on second:

    self.assertEqual(view.with_env(env_us).arch_db, archf % terms_en)

with assertion:

    AssertionError: '<form string="X">Bread and cheeze</form>'
                 != '<form string="X">Bread and cheese</form>'

opw-2153422

Forward-Port-Of: odoo/odoo#41714

Since visitor banner has been added to the chat window (in discuss app), the channel messages div has been pushed down (padding-top) to display visitor banner without overlapping the channel content. But this padding was always applied, even if there was no visitor banner (in the case of normal -non live- chat). This commit only applies this padding when the visitor banner is present. Task ID: 2145749 Forward-Port-Of: odoo/odoo#41019

Since visitor banner has been added to the chat window (in discuss app),
the channel messages div has been pushed down (padding-top) to display visitor
banner without overlapping the channel content.

But this padding was always applied, even if there was no visitor banner
(in the case of normal -non live- chat). This commit only applies this padding
when the visitor banner is present.

Task ID: 2145749

Forward-Port-Of: odoo/odoo#41019

When a refund of pos order is made in the POS backend, the invoice was created in draft, which is a different behavior than when an order is created. So we now automatically post the refund invoice once it is created, and hide the button 'Payment', because if the invoice is reconciled with an account payment, the session cannot be closed anymore as the invoice should be reconciled with POS recievable. We are also fixing a multi-company issue, because the validation of the invoice was

When a refund of pos order is made in the POS backend, the invoice was
created in draft, which is a different behavior than when an order is
created.

So we now automatically post the refund invoice once it is created, and
hide the button 'Payment', because if the invoice is reconciled with an
account payment, the session cannot be closed anymore as the invoice
should be reconciled with POS recievable.

We are also fixing a multi-company issue, because the validation of the
invoice was made in the company of the user, instead of the company of
the order.

ISSUE-ID: 2129357

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#41645
Forward-Port-Of: odoo/odoo#41525

In Odoo app, we don't need to instantiate a datepicker because the native component is used. It's why we destroy it by overriding "start" method. But before this commit, it wasn't the case as the wrong element was taken. Note that it didn't appear because "readonly" was set. Now, we destroy it on the same node that it was instantiated: this.$el (parent node of this.$input). This commit also fix a bug introduced by the following commit: https://github.com/odoo/odoo/commit/5481c429efb

In Odoo app, we don't need to instantiate a datepicker
because the native component is used. It's why we destroy
it by overriding "start" method.
But before this commit, it wasn't the case as the wrong
element was taken.
Note that it didn't appear because "readonly" was set.

Now, we destroy it on the same node that it was instantiated:
this.$el (parent node of this.$input).

This commit also fix a bug introduced by the following commit:
https://github.com/odoo/odoo/commit/5481c429efb50be8d8617e4c17b04999c5a7fce8

It seems that it only occurs in 12.0 because events handlers
are different between in each version; in our case:
'change.datetimepicker': 'changeDatetime', is called but this
method is never called in future versions.
See odoo/odoo@ac85176ce81427ba6f55b59e28c1ff6e7e080c32

Steps to reproduce:
- Go to Sales
- Click on "create" (quotation)
- The following message will appear:
"The record has been modified, your changes will be discarded.
Do you want to proceed?"

Then hasChanged is true and the datetime field is considered as
dirty. But now the datepicker is correctly destroyed and calls to
"changeDatetime" are correctly skipped by calling "return;" thanks
to "__libInput"..

opw-2154200

Forward-Port-Of: odoo/enterprise#7279

This fix prevents the `ir.attachment` mimetype guessing mechanism to take over the mimetype attribution when explicitly giving the mimetype. Task: 2156396 Forward-Port-Of: odoo/enterprise#7276

This fix prevents the `ir.attachment` mimetype guessing mechanism
to take over the mimetype attribution when explicitly giving the
mimetype.

Task: 2156396

Forward-Port-Of: odoo/enterprise#7276

- The 'reconciled' field must never be used in the report because it doesn't depend of the date. - If 'partner_id' is not set on an account.move.line, a line "Unknown Partner" must appear on the aged balance. Forward-Port-Of: odoo/enterprise#7257

- The 'reconciled' field must never be used in the report because it doesn't
depend of the date.
- If 'partner_id' is not set on an account.move.line, a line "Unknown Partner" must appear
on the aged balance.

Forward-Port-Of: odoo/enterprise#7257

Forward-Port-Of: odoo/enterprise#7280

Forward-Port-Of: odoo/enterprise#7280

… free ones This commit ping iap to create the account if it doesn't exist. This avoid to ask to the user to click on 'buy credit' to get his free credits Forward-Port-Of: odoo/enterprise#7209 Forward-Port-Of: odoo/enterprise#7205

… free ones

This commit ping iap to create the account if it doesn't exist. This avoid to ask to the user to click on 'buy credit' to get his free credits

Forward-Port-Of: odoo/enterprise#7209
Forward-Port-Of: odoo/enterprise#7205

Only highlight package if the line exists. opw-2149413 Forward-Port-Of: odoo/enterprise#7150

Only highlight package if the line exists.

opw-2149413

Forward-Port-Of: odoo/enterprise#7150