The web client’s Python-like expression engine can now run conditional expressions that it could previously only read. This helps make dynamic interface behavior more reliable when business rules depend on if/then-style logic.

This update simplifies how Odoo identifies fields used in domain rules during view validation. It helps prevent validation errors when domain rules include calculations or more complex expressions, making internal checks more reliable without changing user-facing behavior.

followup on #40445: we can just use the "fallback" unconditionally and in every case, and should properly handle non-segment expressions at the toplevel of the domain list.

This update adds sample timesheet entries to key demo projects, including a billable project scenario. It helps evaluators and sales teams see timesheet and project flows with more realistic example data out of the box.

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

This update adjusts Belgian payroll testing data and flows to stay aligned with related payroll changes in the core Odoo platform. It helps ensure payroll accounting validations remain reliable after the underlying Community edition updates.

Adapt Enterprise test to Community changes of odoo/odoo#32394

The demo data now marks all timesheets older than 10 days as approved. This makes sample timesheet scenarios more realistic and helps users evaluate approval workflows with cleaner demonstration data.

The field service and project task forms have been adjusted so important fields are arranged more clearly. Tags now appear below planned dates, making task details easier for teams to scan and update.

The Accounting app once again shows the menu option to add a bank account. This restores an accidentally removed shortcut, making it easier for users to set up bank account details without searching for alternate paths.

Removed by mistake by https://github.com/odoo/odoo/commit/ec603e2593131d462f578feda2e1fec3cfb59c53

This update ensures the batch payment feature correctly depends on the accounting app that now contains the reconciliation tool it uses. It prevents installation failures for batch payments and related payment modules such as SEPA or Australian ABA payments.

account_batch_payment overrides / updates the reconciliation widget.

That widget was moved from account to account_accountant by #6032,
however the dependency was not updated, so when installing
account_batch_payment or one of its dependents (e.g. account_sepa or
l10n_au_aba) the installation blows up and fails as the reconciliation
widget is not found.

The buttons for italian e-invoice from l10n_it_edi module are erroneously shown for company that are not italian. opw-1945836 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40717 Forward-Port-Of: odoo/odoo#34331

The buttons for italian e-invoice from l10n_it_edi module are
erroneously shown for company that are not italian.

opw-1945836

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

Forward-Port-Of: odoo/odoo#40717
Forward-Port-Of: odoo/odoo#34331

An UBL invoice can contain several `AdditionalDocumentReference`, some of them without `Attachment`. For example: ``` <cac:AdditionalDocumentReference> <cbc:ID>UBL.BE</cbc:ID> <cbc:DocumentDescription>BOB50 6.07.0</cbc:DocumentDescription> </cac:AdditionalDocumentReference> <cac:AdditionalDocumentReference> <cbc:ID>Facture N°19090118 - 30-09-2019.pdf</cbc:ID> <cbc:DocumentDescription>CommercialInvoice</cbc:DocumentDescription> <cac:Attachment> <cbc:E

An UBL invoice can contain several `AdditionalDocumentReference`, some
of them without `Attachment`. For example:

```
  <cac:AdditionalDocumentReference>
    <cbc:ID>UBL.BE</cbc:ID>
    <cbc:DocumentDescription>BOB50  6.07.0</cbc:DocumentDescription>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>Facture N°19090118 - 30-09-2019.pdf</cbc:ID>
    <cbc:DocumentDescription>CommercialInvoice</cbc:DocumentDescription>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject filename="Facture.pdf" mimeCode="application/pdf">JVBERi0xLjMK...
...
```

In this case, a crash occurs since:

```
element.xpath('cac:Attachment//cbc:EmbeddedDocumentBinaryObject', namespaces=namespaces)
```

is an empty list.

To avoid this, we loop on all elements and generate all PDFs.

opw-2128083

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#40698
Forward-Port-Of: odoo/odoo#40681

**[FIX] stock: set serial count to generate SN** > Before this commit, the field `next_serial_count` in stock.move, used to > know how many SN the user wants to generate, wasn't correctly set and > was always equals to 0. **[FIX] stock: display assign SN immediate transfer** > Before this commit, when user creates a receipt for a product tracked by > serial number, using immediate transfer, the fields to generate and > assign SN was hidden. > The reason was the move is confirmed in t

**[FIX] stock: set serial count to generate SN**

> Before this commit, the field `next_serial_count` in stock.move, used to
> know how many SN the user wants to generate, wasn't correctly set and
> was always equals to 0.

**[FIX] stock: display assign SN immediate transfer**
> Before this commit, when user creates a receipt for a product tracked by
> serial number, using immediate transfer, the fields to generate and
> assign SN was hidden.
> The reason was the move is confirmed in this case, and those fields was
> displayed only for partially available and assigned moves.
> 
> task-2123761

Forward-Port-Of: odoo/odoo#40559

Before this commit, with a time range activated in a pivot view, click on a non empty cell would not always give the right list of records because of a bad action domain. The reason is that the headers domain or comparisonDomain were not always set when appropriate: - for the headers 'Total', the corresponding group obtained by read_group does not contain the key __domain. For that reason both the key domain and comparisonDomain were left undefined. - for hea

Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.

The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
    - for the headers 'Total', the corresponding group obtained
      by read_group does not contain the key __domain. For that
      reason both the key domain and comparisonDomain were left
      undefined.
    - for headers that correspond to groups not present in the two
      periods compared, one of the key was left undefined.

With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.

Forward-Port-Of: odoo/odoo#40509
Forward-Port-Of: odoo/odoo#40344

Fix the case when `_rec_name` is an inherited field. Forward-Port-Of: odoo/odoo#40639

Fix the case when `_rec_name` is an inherited field.

Forward-Port-Of: odoo/odoo#40639

Before this commit, calling gengo_authentication (executed from the cron _send_translation_terms) returns an error when the python library gengo is not found on the system. If tried to request a synchronisation, got an error "NameError: name 'Gengo' is not defined" Gengo variable was undefined as no imported. Forward-Port-Of: odoo/odoo#40674

Before this commit, calling gengo_authentication (executed from the
cron _send_translation_terms) returns an error when the python library
gengo is not found on the system.
If tried to request a synchronisation, got an error "NameError: name
'Gengo' is not defined"
Gengo variable was undefined as no imported.

Forward-Port-Of: odoo/odoo#40674

No justification, commit message not linked to the diff. If there is an issue in the line_number extraction it must be investigated. I suspect an outdated polib version. Forward-Port-Of: odoo/odoo#40672

No justification, commit message not linked to the diff.
If there is an issue in the line_number extraction it must be
investigated.
I suspect an outdated polib version.

Forward-Port-Of: odoo/odoo#40672

In case the Stripe API call fails, an Internal Server Error page is displayed to the user, which is not user friendly. opw-2126196 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#40670

In case the Stripe API call fails, an Internal Server Error page is
displayed to the user, which is not user friendly.

opw-2126196

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

When a calendar event is created with a duration of for example 20 minutes, the end time appears as the start time + 19 minutes. Because of the rounding of the duration (20 minutes = 0.333... hours), the end time is incorrectly set (xx:19:59.998...) then displayed. Since the duration can only be set by the minute, we round it before computing the end time. opw-2122853 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is m

When a calendar event is created with a duration of for example 20
minutes, the end time appears as the start time + 19 minutes.

Because of the rounding of the duration (20 minutes = 0.333... hours),
the end time is incorrectly set (xx:19:59.998...) then displayed. Since
the duration can only be set by the minute, we round it before computing
the end time.

opw-2122853

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

Install Helpdesk, setup an email alias. Send to that alias an email where the name of the from field contains unicode characters. The name shown in the interface is base64 encoded, RFC compliant email name. Python 2 `email.utils.formataddr` does not generate RFC compliant header fields. It just formats the header as `name <email>`, quoting the name when necessary. Only ASCII names/emails are supported but it is convenient to show correctly formatted emails on forms. Python 3 `email.ut

Install Helpdesk, setup an email alias. Send to that alias an email
where the name of the from field contains unicode characters. The name
shown in the interface is base64 encoded, RFC compliant email name.

Python 2 `email.utils.formataddr` does not generate RFC compliant
header fields. It just formats the header as `name <email>`, quoting
the name when necessary. Only ASCII names/emails are supported but it is
convenient to show correctly formatted emails on forms.

Python 3 `email.utils.formataddr` generates RFC compliant header
fields, it encodes the name in base64 or quoted-printable when it
contains non-ascii characters. The entire unicode charset is supported
but the function shouldn't be used when showing email addresses on
forms.

The problem has been fixed by backporting our own `formataddr` (c024d89,
a66e16e and 81003c1). Our function supports both use cases : pretty
format and RFC compliant format.

opw-2115767

Forward-Port-Of: odoo/odoo#40298

Activate and set as language Arabic(Syria). Go to Payroll>Work Entries>Conflict Traceback will popup: date has been converted to arabic characters and database does not recognize the date object. This is because moment.js change the date according to the locale of the system, so the locale need to be manually set to 'en' just to evaluate the datetime. opw-2122916 Forward-Port-Of: odoo/enterprise#6833

Activate and set as language Arabic(Syria). Go to Payroll>Work
Entries>Conflict

Traceback will popup: date has been converted to arabic characters and
database does not recognize the date object. This is because moment.js
change the date according to the locale of the system, so the locale
need to be manually set to 'en' just to evaluate the datetime.

opw-2122916

Forward-Port-Of: odoo/enterprise#6833

The CO2 taxes for company cars are computed based on the health indice at the 30th September of the previous year. This commit adds the rule parameter value for 2020 (health indice at Sept. 2019) https://statbel.fgov.be/en/themes/consumer-prices/health-index#figures Forward-Port-Of: odoo/enterprise#6450

The CO2 taxes for company cars are computed based on the health indice
at the 30th September of the previous year.

This commit adds the rule parameter value for 2020 (health indice at Sept. 2019)

https://statbel.fgov.be/en/themes/consumer-prices/health-index#figures

Forward-Port-Of: odoo/enterprise#6450

### Purpose: Ponto has changed is access mechanism from a simple token to a client_id:client_secret that generates temporary token. The token mechanism will be deprecated in december and thus we have to adapt the code for it to work with the new mechanism. ### Spec: Since we don't want to add new fields, we will use the ponto_token field to store the information about client_id and client_secret and temporary access token (this information will be stored in the form of a stringified json)

### Purpose:
Ponto has changed is access mechanism from a simple token to a client_id:client_secret that generates temporary token.
The token mechanism will be deprecated in december and thus we have to adapt the code for it to work with the new mechanism.

### Spec:
Since we don't want to add new fields, we will use the ponto_token field to store the information about client_id and client_secret
and temporary access token (this information will be stored in the form of a stringified json)

**Json structure:**
```
{
 'encoded_credentials': (client_id:secret_id) -> encoded in base 64,
 'access_token': temporary access token,
}
```

There is a new method for the generation of the access_token.
This method sends credentials to a special route on api.myponto.com and get a temporary access_token.
This token is valid only 30 minutes. If the token is invalid, we re-ask a new temporary access_token.

**Task ID: 2082144**

Forward-Port-Of: odoo/enterprise#6818
Forward-Port-Of: odoo/enterprise#6674

Install Helpdesk, setup an email alias. Send to that alias an email where the name of the from field contains unicode characters. The name shown in the interface is base64 encoded, RFC compliant email name. Python 2 email.utils.formataddr does not generate RFC compliant header fields. It just formats the header as name <email>, quoting the name when necessary. Only ASCII names/emails are supported but it is convenient to show correctly formatted emails on forms. Python 3 email.utils.f

Install Helpdesk, setup an email alias. Send to that alias an email
where the name of the from field contains unicode characters. The name
shown in the interface is base64 encoded, RFC compliant email name.

Python 2 email.utils.formataddr does not generate RFC compliant
header fields. It just formats the header as name <email>, quoting
the name when necessary. Only ASCII names/emails are supported but it is
convenient to show correctly formatted emails on forms.

Python 3 email.utils.formataddr generates RFC compliant header
fields, it encodes the name in base64 or quoted-printable when it
contains non-ascii characters. The entire unicode charset is supported
but the function shouldn't be used when showing email addresses on
forms.

The problem has been fixed by backporting our own formataddr (
odoo/odoo@c024d89, odoo/odoo@a66e16e and odoo/odoo@81003c1). Our
function supports both use cases : pretty format and RFC compliant
format.

odoo/odoo#40298
opw-2115767

Forward-Port-Of: odoo/enterprise#6726

- Activate SEPA Credit Transfer for outbound payments for 'Bank' - Create and validate 2 vendor bils for the same supplier - Select both bills, then Action > Register Payment - Choose SEPA Credit Transfer You are allowed to validate, but the payment will be created without a bank account set. Later in the process, the user will be blocked since it won't be possible to set the bank account anymore. The bank account taken is from the first invoice of the list: https://github.com/odoo

- Activate SEPA Credit Transfer for outbound payments for 'Bank'
- Create and validate 2 vendor bils for the same supplier
- Select both bills, then Action > Register Payment
- Choose SEPA Credit Transfer

You are allowed to validate, but the payment will be created without a
bank account set. Later in the process, the user will be blocked since
it won't be possible to set the bank account anymore.

The bank account taken is from the first invoice of the list:

https://github.com/odoo/odoo/blob/4eb47d335c5c87c9cc39a504e67b25d026b3c422/addons/account/models/account_payment.py#L795

We force the user to set the bank account on all invoices.

opw-2119374

Forward-Port-Of: odoo/enterprise#6819