Accounting account types now use the clearer label “Non Trade” instead of “Other,” while keeping familiar Receivable and Payable names. Accounting views also gain more consistent filters for trade and non-trade accounts, helping users find the right accounts more easily.

Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence.

It is now possible to filter the trade/non trade accounts in the accounting views.

Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
The default filtering may be overriden by default selections already in place.

Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed user ; they are now renamed Receivable/Payable, though the Non-Trade option is still present.

task-2669128

This update reorganizes how file uploads are handled in Odoo's messaging area, making attachment behavior more consistent across activities, chatter, and message composition. It mainly improves the underlying structure so future upload-related improvements can be delivered more reliably.

Accounts marked as non-trade are now handled consistently across aged receivable/payable reports and the Partner Ledger, so excluded balances no longer appear where they should not. The Partner Ledger is also easier to read because it shows both account codes and account names.

The accounts indicating Exclude from Aged Reports were not visible in the Aged Receivable/Payable reports, but they did in the Parnter Ledger reports : they don't anymore.

Renamed the option's label to reflect that.

Display account name with its code in Partner Ledger report

In the Partner Ledger reporting section, only the account code was displayed. The account name is now also present ---> better readability.

task-2669128

New tests were added to confirm that rental-related fields on CRM leads continue to work as expected. This helps protect the rental sales workflow ahead of planned performance improvements, reducing the risk of future changes breaking existing behavior.

This fix restores a mail preference that was removed by mistake but was still needed by the system. It helps ensure users' notification volume settings continue to work as expected.

Follow-up of
https://github.com/odoo/odoo/pull/81679

This field was actually being used, so shouldn't have been deleted.

The current user of the pos session is unable to close the session even if he is the one who opened it. This commit allows the cashier to close the session if he is linked to the user that opened the POS session. task-id: 2713876 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81683

The current user of the pos session is unable to close the session even if he is the one who opened it.
This commit allows the cashier to close the session if he is linked to the user that opened the POS session.

task-id: 2713876

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

Forward-Port-Of: odoo/odoo#81683

Description of the issue/feature this PR addresses: The field 'odoobot_state' is defined in view 'res_users_view_form_preferences' of mail_bot. Otheriwse an error is raised 'odoobot_state' cannot be located in parent view. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77762

Description of the issue/feature this PR addresses:
The field 'odoobot_state' is defined in view 'res_users_view_form_preferences' of mail_bot. Otheriwse an error is raised 'odoobot_state' cannot be located in parent view.




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

Forward-Port-Of: odoo/odoo#77762

Before this commit, in some cases the submit button of the form snippet never stop loading after being clicked. (e.g. redirect to an anchor in the same page, show message after submit) task-2172312 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#81598

Before this commit, in some cases the submit button of the form snippet
never stop loading after being clicked. (e.g. redirect to an anchor in
the same page, show message after submit)

task-2172312

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

Prior to this commit, the _search_valid method returns all the time off types. With this commit, only the time off types that have a valid allocation are returned task-2711388 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81714 Forward-Port-Of: odoo/odoo#81111

Prior to this commit, the _search_valid method returns all the time off types.

With this commit, only the time off types that have a valid allocation are returned

task-2711388

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

Forward-Port-Of: odoo/odoo#81714
Forward-Port-Of: odoo/odoo#81111

Problem 1: The context was not passed when calling the resequence function. Problem 2: Also, the subsequent read operation did not pass the full context, but only the context of the user, not the context of the action. A test has been added for the basic model to check that the context is properly given after a resequence. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81477 Forward-Port-Of: odoo/odoo#81393

Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.

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

Forward-Port-Of: odoo/odoo#81477
Forward-Port-Of: odoo/odoo#81393

**Description of the issue/feature this PR addresses:** "Name" mandatory field in popup is still appearing two times when user tries to save the contact record. **Current behaviour before PR:** Already PR: https://github.com/odoo/odoo/pull/78802 is merged which added changes into "view_partner_simple_form" form view but still the name is showing twice in popup when saving the contact record. **Desired behaviour after PR is merged:** In this commit the same changes are added into "view_

**Description of the issue/feature this PR addresses:**
"Name" mandatory field in popup is still appearing two times when user tries to save the contact record.

**Current behaviour before PR:**
Already PR: https://github.com/odoo/odoo/pull/78802 is merged which added changes into "view_partner_simple_form" form view but still the name is showing  twice in popup when saving the contact record.

**Desired behaviour after PR is merged:**
In this commit the same changes are added into "view_partner_form" form view and now the name is only visible once in the popup.

Fixes #79753


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

Forward-Port-Of: odoo/odoo#79758

Context ------- On some database, record rule may be configured in such a way that user are able to read Purchase/Sale order with a company_id != user.company_ids Issue ----- This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6# introduce a new field tax_country_id that require to be able to read the fiscal.position as well. The reading of a sale.order or purchase.order should not require the right to read the fiscal.position for the computati

Context
-------

On some database, record rule may be configured in such a way
that user are able to read Purchase/Sale order
with a company_id != user.company_ids

Issue
-----
This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6#
introduce a new field tax_country_id that require to be able to read
the fiscal.position as well.

The reading of a sale.order or purchase.order should not require the
right to read the fiscal.position for the computation of a technical
field only use during the modification.

Solution
--------
Compute tax_country_id as sudo





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

Forward-Port-Of: odoo/odoo#80028

Issue ----- When a customer sign and pay a sale order from the portal and automatic invoicing is enabled, it generate an invoice. Once the payment done the customer is redirected to the sale order preview with a link to the invoice created. To display the link to the invoice the method _portal_ensure_token() is called and write the access token token. In parallel, if the invoice need to send edi document, the cron job is triggered at the posting of the invoice and thus the cron

Issue
-----

When a customer sign and pay a sale order from the portal and  
automatic invoicing is enabled, it generate an invoice. 
Once the payment done the customer is redirected to
the sale order preview with a link to the invoice created.

To display the link to the invoice the method _portal_ensure_token() is
called and write the access token token.

In parallel, if the invoice need to send edi document, the cron job is
triggered at the posting of the invoice and thus the cron job try to
write as well on the invoice as the invoice link is displayed to the
customer

This lead to a concurrent update for the cron job that do not retry in
case of concurrent update as normal transactions do. So the edi document
is never synchronized and the invoice never sent

Solution
--------
Avoid to write on the invoice while displaying the sale order portal
view by already generating the access_token in the transaction that post
the invoice





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

Forward-Port-Of: odoo/odoo#81672

[FIX] account: reconciliation models: properly match statement line fields when no partner is set When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name. This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working. As an example, consider the following case: 1) setup an invoice-matcing reconciliation model as s

[FIX] account: reconciliation models: properly match statement line fields when no partner is set

When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.

This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.

As an example, consider the following case:

1) setup an invoice-matcing reconciliation model as such:
	- Partner Is Set and Matches = False
	- Match Invoice/bill with = Reference

2) Create an invoice with payment reference 123, for 100€

3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.

4) Try to reconcile the statement line

=> not match is found

OPW 2701729


 
[IMP] account: reconciliation models: No confusing label anymore for "Match Invoice/bill with"

This label was defined with 'for="match_text_location_label"', even though it actually isn't met for just that field, but for the three boolean fields allowing to choose where to match on the statement line. As a consequence, in debug, it displayed the helper of that field, which was confusing for the user.

Forward-Port-Of: odoo/odoo#81641
Forward-Port-Of: odoo/odoo#81481

The previous code resulted in only the last editor to trigger its handler having hints, as all the others would be killed by the last one. Forward-Port-Of: odoo/odoo#81712

The previous code resulted in only the last editor to trigger its
handler having hints, as all the others would be killed by the last one.

Forward-Port-Of: odoo/odoo#81712

Current behavior : Cash in/out button is not present on mobile PoS app Steps to reproduce : - Go on your mobile app - Go in PoS app opw-2704097 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81677

Current behavior :
Cash in/out button is not present on mobile PoS app

Steps to reproduce :
- Go on your mobile app
- Go in PoS app

opw-2704097

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

Forward-Port-Of: odoo/odoo#81677

Some transactions can include charges in their total amount. The management of charges was added by commit https://github.com/odoo/enterprise/commit/fbde4f64034c59b1f96eb42c231e021fa93238f1 but it seems the charges can also be found at TxDtls/Chrgs/Amt level in addition to TxDtls/Chrgs/Rcrd/Amt. We should also look in this corresponding element to properly retrieve the amount, otherwise the closing balance won't match. opw-2710427 Forward-Port-Of: odoo/enterprise#23021 Forward-Port-Of:

Some transactions can include charges in their total amount. The management
of charges was added by commit https://github.com/odoo/enterprise/commit/fbde4f64034c59b1f96eb42c231e021fa93238f1 but it seems the charges can also be
found at TxDtls/Chrgs/Amt level in addition to TxDtls/Chrgs/Rcrd/Amt.

We should also look in this corresponding element to properly retrieve the
amount, otherwise the closing balance won't match.

opw-2710427

Forward-Port-Of: odoo/enterprise#23021
Forward-Port-Of: odoo/enterprise#22897

Issue: The subject of the followup mail was not translated Solution: Add the parameter `translate=True`to the field `email_subject` Forward-Port-Of: odoo/enterprise#23006

Issue:
The subject of the followup mail was not translated

Solution:
Add the parameter `translate=True`to the field `email_subject`

Forward-Port-Of: odoo/enterprise#23006

Courtesy of Erwin van der Ploeg Forward-Port-Of: odoo/enterprise#23012

Courtesy of Erwin van der Ploeg

Forward-Port-Of: odoo/enterprise#23012