This change reverses part of a previous portal update because it could expose private information to portal users. It helps keep customer-facing portal access limited to appropriate business documents and data.

Purpose
=======

This fix makes no sense because it exposes some private data to
portal users. Fortunately it was only introduced in the master branch.

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 change reverses a recent portal update that could have exposed private information to external portal users. It helps keep helpdesk and subscription-related customer data appropriately protected before the change reaches a released version.

Purpose
=======

This fix makes no sense because it exposes some private data to
portal users. Fortunately it was only introduced in the master branch.

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.

A new demo module lets teams showcase and explore the Social app without connecting to external social media APIs. This provides a safe environment for trying posts, comments, and streams, making customer demonstrations and training easier.

This commit introduces a new complete demo module for the social app.

A full module is necessary because we need to override several methods to prevent calls to third
party APIs.

This creates a full sandbox where you can safely play around with posts and comments while checking
the capabilities of our social app.
It will also make it easier to showcase the app to new customers.

Task#2081610

Manufacturing teams can now add extra components or by-products directly from the work order tablet view when flexible consumption is enabled. Cost analysis reports also make these added or differently consumed items easier to spot, improving visibility into real production costs.

Increase the scope of flexible consumption, allowing to update confirmed MO's and consume components which weren't part of the initial BOM

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

Certification badges are now shown separately from other eLearning badges on the ranks page, making achievements tied to courses easier to find and understand. Users can click a certification badge to go directly to the related course, while background updates improve badge and challenge organization.

This merge adds a section to distinguish the certification badges from the
other badges users may obtain in eLearning. Certification badges are available
on the ranks page, linked to a running survey. Clicking on them directly
redirects into the linked course.

Other commits in this merge include

  * renaming a category field on challenge to challenge_category to ease
    its finding in code;
  * renaming some statistics fields on badge model to ease its understanding;
  * various usability improvements and fixes;

Task ID : 1961053
PR #32594

Odoo now includes user records when automatically applying company-based restrictions. This helps keep stock and product-related selections aligned with the correct company, reducing mistakes in multi-company setups.

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

This change prevents duplicate company-specific default values from being saved for the same setting, which could previously cause inconsistent results. It improves reliability across accounting, inventory valuation, point of sale, product, website learning, and core system flows by ensuring the system uses one clear value.

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

Manufacturing orders can now be adjusted more flexibly by adding and consuming extra components directly from work orders, even when they were not in the original bill of materials. The update also improves traceability, quantity handling, and related manufacturing screens so post-confirmation changes are recorded more accurately.

Increase the scope of flexible consumption, allowing to update confirmed MO's and consume components which weren't part of the initial BOM

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

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

Time off types can now use different approval rules for allocation requests and actual leave requests. This gives businesses more control, such as allowing a manager to approve earned compensation days while another role handles later time off requests.

Purpose
=======

We want to allow different approvals for allocations and leaves of a same type.

e.g. In case of compensation days, a manager would approve the
allocation request, but would later not approve leave requests.

Specification
=============

Allocation modes
----------------
No change here except renames.
1. No limit (employee doesn't need an allocation to request a leave)
2. Allow employee requests
3. Fixed by Time Off Officer

Allocation approval
-------------------
A radio field to choose the approval mechanism
appears if the employee is allowed to request an allocation.
The following approval modes are possible:
1. Time Off Officer
2. Employee's Time Off Manager (leave_responsible_id)
3. Employee's Time Off Manager and Time Off Officer

These options are the same as leave approval options
(except the missing "No Validation").

If option 1 or 2 is selected, a o2m field should
allow to select which Time Off Officer is responsible
for approving those allocations.

Additional changes
------------------

The field `code` of a leave type is unused and thus
removed. A code is usefull for payroll purposes
and is added by hr_payroll module.

A stat button on a leave type counting how many allocation
have bee made does not have any sens if no allocation is
required. Therefore we remove it in this case.

Task id: 1936742

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

Inventory adjustments are easier to find and start from the inventory app. Users can open draft or in-progress adjustments directly in the barcode view and create a new adjustment from scratch, improving day-to-day warehouse efficiency.

shows a kanban view of the draft and in progress inventory adjustment, I click on it, it opens the barcode view of the inventory adjustment and  add a create button to start an inventory adjustment from scratch to provide more efficiency and convenience to user.

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

Pad : https://pad.odoo.com/p/r.14bd692e7a6b5301c19b90bc044729b3





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

Project tasks can now be organized into multiple nested sub-task levels instead of only one. This gives teams more flexibility to break down complex work, while keeping sub-task counts, naming, project assignment, and planned or effective hours aligned across the hierarchy.

Purpose
=======

Currently, it is only possible to have 1 level of sub-tasks per task.
The user may want several levels of granurality.

Specifications
==============

Allow having multi levels of sub-tasks
- Move the parent_id field out of the debug mode and display it above the
  Deadline field
- Remove the 'parent task' stat button
- Add the parent_id field to the project.task optional list view
- Display the sub-tasks stat button on sub-tasks
- The 'sub-tasks' stat button should only count/display tasks from the
  first level of sub-tasks
- The name of the sub-task should be
  parent task: sub task level 1: sub task level 2: sub task level 3...
- The sub-task should be created in the sub-task project set on the
  parent task's project
- The subtask_planned_hours and the subtask_effective_hours fields should
  take into account the planned hours of all sub-level tasks

TaskID: 2107078

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 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.

HR users can now update selected employee, contract, recruitment, expense, leave, and work entry fields in bulk from list views. This reduces repetitive manual updates and makes maintaining HR data faster and more consistent.

Make some fields editable in multi edit.
Some onchange are transformed in compute fields.

id=2078674





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

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

Field Service can now be used without requiring the Sales app, making it easier for teams that only need planning and operations workflows. Sales-related billing features are moved into separate add-on modules that activate when sales functionality is installed.

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

Inventory adjustments now open in a kanban view that highlights draft and in-progress adjustments, making it easier for users to continue existing work or start a new adjustment. Barcode inventory adjustments also better support multi-location and multi-warehouse setups by avoiding an incorrect location warning.

shows a kanban view of the draft and in progress inventory adjustment, I click on it, it opens the barcode view of the inventory adjustment and  add a create button to start an inventory adjustment from scratch to provide more efficiency and convenience to user.

Task : https://www.odoo.com/web#id=1970451&action=327&model=project.task&view_type=form&menu_id=4720
Pad : https://pad.odoo.com/p/r.14bd692e7a6b5301c19b90bc044729b3

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.

HR teams can now update selected contract and employee-related fields across multiple records at once. This reduces repetitive data entry and keeps related values updated automatically when changes are made.

Make some fields editable in multi edit.
Some onchange are transformed in compute fields.

id=2078674

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