In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors.

This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow:
1. Add the unmodified source page directly to the `PdfFileWriter`.
2. Retrieve the newly created, writable output page.
3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page.

[^1]: https://github.com/py-pdf/pypdf/pull/3638
[^2]: https://github.com/py-pdf/pypdf/pull/3669

Forward-Port-Of: odoo/enterprise#119694
Forward-Port-Of: odoo/enterprise#119239

## Steps to reproduce:
	- Install l10n_be_hr_payroll module
	- Create a flexible working schedule and set the company to the Belgian company
	- Create an employee and assign the created schedule to him
	- Try to take a multi-day leave for this employee
	- Notice number of days is 0
	- Try to validate the leave
	- An exception is raised 'The following employees are not supposed to work during that period'

## Cause:
When fetching the work intervals for a belgian flexible employee we first fetch the normal work intervals then we call the same method but to filter the time credit attendance and since for the flexible employee there are not specific attendances we return the same normal work intervals and it will subtract those from the main work intervals which will result in an empty intervals to be returned

## Fix:
Check if the working schedule is flexible and if so we don't check the time credit attendances at all.

opw-6237642

Forward-Port-Of: odoo/enterprise#118870
Forward-Port-Of: odoo/enterprise#118528

Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
    * Trigger: On Creation
    * Action To Do: Execute AI Action
    * Add a server action tool with 'Create Next Activity' action
    * Set Activity User Type to Dynamic
    * Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user

Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths

Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed

Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module

opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530

Forward-Port-Of: odoo/enterprise#119179
Forward-Port-Of: odoo/enterprise#118921

### *Why this commit*: 
---
Ensures Quality Checks and Mass Produce options remain available on the
Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid both the Quality Checks and Mass Produce buttons.
This blocked users from registering Serial Numbers and completing mandatory
quality check steps.

Additionally, for products without BoM operations, clicking Mass Produce 
triggered quality check validation instead leading to errors, preventing the
generation of serial numbers.


### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Mass Produce: Stays visible to allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.


OPW: 5473839

Forward-Port-Of: odoo/enterprise#119875
Forward-Port-Of: odoo/enterprise#103926

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Steps to reproduce:
1. Install website_sale_renting_planning
2. In rental module,  create a product that is of type service and can be sold
3. Go to the website and remove the quantity selector input field from the page and save.

Issue:
`TypeError: Cannot read properties of null (reading 'dataset')`

Why this happens:
Following architectural changes in v19.1, the rental data evaluation logic was moved directly into the DaterangePicker component lifecycle. Commit 4e5f71d introduces a new method to where, during initialization (`willStart`), the component triggers `setAddQtyInputMax()` to update the dataset attributes of the quantity selector input box. If the quantity selector has been removed via the website customizer `querySelector` returns `null`, causing the assignment to crash.
In v19.0, this logic lived in the `WebsiteSale` interaction, executing only during post-render UI event listener triggers which kept it safe.

opw-6268945

Forward-Port-Of: odoo/enterprise#119574

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#120098
Forward-Port-Of: odoo/enterprise#109032

The display name of the account.report.line in the general ledger report has the format of:

INVOICE NAME (invoice refs)

In the case where a client has hundreds of sales orders batched to a single invoice, the ref can
become extremely long, e.g.:

INV/2026/00001 (S12123, S12152, S12159, S12140, S12165, S12161, S12162, S12110, S12099, S12124, S12145, S12128, S12114, S12131, S12097, S12185, S12154, S12133, S12190, S12118, S12116, S12102, S12155, S12153, S12158, S12150, S12100, S12142, S12121, S12122, S12111, S12187, S12172, S12177, S12095, S12117, S12144, S12137, S12092, S12138, S12186, S12182, S12112, S12148, S12183, S12101, S12178, S12119, S12169, S12115, S12146, S12093, S12126, S12160, S12163, S12129, S12098, S12151, S12096, S12174, S12120, S12130, S12147, S12180, S12191, S12164, S12141, S12105, S12136, S12139, S12109, S12106, S12104, S12103, S12175, S12179, S12188, S12113, S12173, S12167, S12171, S12134, S12094, S12184, S12166, S12170, S12125, S12135, S12143, S12176, S12189, S12156, S12181, S12107, S12157, S12132, S12149, S12127, S12108, S12168...)

Because the length of the account.report.line is unchecked in account_general_ledger.py label
builder, the pdf can clog to one or two account.report.lines per page, skyrocketing the pdf page length.

As wkhtmltopdf processes the report from html to pdf it makes a system call openat() to the /tmp/report.footer.tmp.x.html file for EACH page of the pdf. You can see the TODO comment in the spoolTo function in wkhtmltopdf (both in Odoo and the original repo) saying that the header and footer need to be freed, on each page processing, not just null pointed.

https://github.com/odoo/wkhtmltopdf/blob/2c884bd1545b8a639847de22f24754ee5a6fc44c/src/lib/pdfconverter.cc#L794

I verified that that the number of openat calls to the /tmp/report.footer.tmp.x.html file equals the exact number of pages in the pdf to be generated if the report HAD generated successfully by setting the footer input into
_run_wkhtmltopdf to None, generating the report without footers, then separately running an strace on wkhtmltopdf when the report fails to generate. See related ticket linked at bottom.

The linux machine used on sh instances has a ulimit -n of 1024 file descriptors. Because
the footer file descriptors accumulate, once a pdf has about 1010+ pages (~a dozen fd's are allocated for other purposes), over 1024 file descriptors are opened and the system fails with:

Wkhtmltopdf failed (error code: -6). Message:
QEventDispatcherUNIXPrivate(): Unable to create
thread pipe: Too many open files
QEventDispatcherUNIXPrivate(): Can not continue
without a thread pipe

Since wkhtmltopdf is archived and Odoo has a replacement in development, I suggest that we limit the display_name of the account.report.line to 200 to keep the bloat minimized, preventing one account.report.line's name from taking up an entire page of the general ledger pdf. This allows many more batched invoices to be shown in the report and a much greater time range of data to be printed without hitting the fd limit.

I suggest changing it at the general ledger report level rather than in the account.move.line
_compute_display_name function, as we probably still want to see the full display_names at the invoice level.

On runbot, the machine has different memory constraints than on sh / local, so it hits the following error before the one above:

Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum file number of subprocess
reached. Message :

Steps to Reproduce on 19.0 newdb:

1. newdb -n test_gl -v 19.0
2. ensure ulimit is set to 1024 in shell that runs odoo instance by running ulimit -n 1024 to
mimic ulimit of sh environment
3. run db with python3 odoo-bin, ensuring high enough memory constraints to simulate multi
worker sh instance, i.e.
--limit-memory-soft=12884901888
--limit-memory-hard=1288490188
4. install sales, accounting, stock
5. install demo data
6. create invoices with 100+ associated sales orders
7. generate the pdf
8. Increase the amount of invoices till the general ledger page count hits ~1010+, where you will
hit the error.

Notes:
opw-ticket-6201508

closes #118067

Forward-Port-Of: odoo/enterprise#120137
Forward-Port-Of: odoo/enterprise#118067

Steps to reproduce
1. With a Mexican POS configured, create a POS order and sign a Global Invoice for it.
2. Open a new session and partially return the order; close the session.
3. On the original order, cancel the Global Invoice through the CFDI page.
4. Try to create a new Global Invoice for the original order.

Issue
The wizard raises "Orders <REFUND-NAME> are already sent or not eligible for CFDI."

Validating the refund auto-signs an `invoice_sent` CFDI on the refund pos.order because its parent is `global_sent`, see `_l10n_mx_edi_check_autogenerate_cfdi_refund` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L98. Cancelling the GI only flips its own document to `ginvoice_cancel`; the refund's `invoice_sent` doc stays untouched, so the refund's computed `l10n_mx_edi_cfdi_state` stays `'sent'`. The chain check in `_l10n_mx_edi_check_orders_for_global_invoice` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L184 then rejects the refund as already sent and the new GI cannot be created.

opw-6181136

Forward-Port-Of: odoo/enterprise#120349
Forward-Port-Of: odoo/enterprise#117211

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120384
Forward-Port-Of: odoo/enterprise#115256

Report edits could be applied on shared layouts such as web.basic_layout instead of the report-specific document view.

This caused Studio customization diffs to affect unrelated reports and could also lead to rendering errors when report-specific fields were evaluated in a different report context.

The issue occurred because content was inserted directly into the shared layout article section instead of the nested report document view.

Steps to reproduce:
1. Open Studio on any module and create or edit a report.
2. Select any of the External, Minimal, or Blank report types.
3. Add content to the report body and save the report.
4. Open another module and create a report using the same report type.
5. Observe that the previous customization is already present.

Before this fix, the generated diff could inherit from web.basic_layout. After this fix, body edits are kept inside the report-specific document view.

Related Ticket:
opw-6245485

Forward-Port-Of: odoo/enterprise#120357
Forward-Port-Of: odoo/enterprise#118880

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#120413
Forward-Port-Of: odoo/enterprise#113133

Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120394
Forward-Port-Of: odoo/enterprise#112859