Steps to produce:
---
- Install `calendar` module.
- Go to `Calendar and create a new event using quick create`.
- Set Location and Notes and other values.
- Click `More options`.

Issue:
---
- When the full form view opens, the `Location, Notes and Privacy`
  fields are empty, even though they were filled in the
  quick-create dialog.

Root cause:
---
- At [1], [2] & [3], `Location, Notes and Privacy` values are
  correctly stored in the location, notes and privacy
  fields respectively.
- When opening the full form, default values are built via
  `getDefaultValuesFromRecord`.
- And here at [4], location,notes and privacy are missing from the
  `QUICK_CREATE_CALENDAR_EVENT_FIELDS`.
- As a result, these fields are skipped and not passed through the
  context, causing data loss.

Solution:
---
- Add the location and privacy fields to the
  `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they
  are included when generating default values for the
  full form view.
- And replace `description` with `notes`.

Note:
---
- As this is a small and simple case, the test has not been added to avoid unnecessary overhead.

[1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381
[2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407
[3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403
[4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17

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

Forward-Port-Of: odoo/odoo#247117

## Short functional explanation of the error
When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B.

## Reproduction Steps
1. Create a second company to your database. Let's call these companies Company A and Company B.
2. Select Company A as your main company, but make sure Company B is also selected.
3. Create an Employee A.
4. Select Company B as tour main company; but make sure Company A is also selected.
5. Create an Employee B who has A as manager.
6. Create Employee C who has B as manager.
7. With a user only having access to Company B, log in and try to access Employee C's page.

### Expected behavior
Employee's C page loads correctly.

### Unexpected behavior
An access error occurs.

## Origin of the issue
A sudo() was missing.
__
opw-5910036





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

Forward-Port-Of: odoo/odoo#248819
Forward-Port-Of: odoo/odoo#247817

Enterprise PR: https://github.com/odoo/enterprise/pull/108109

The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper.

However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices.

Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability.

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

Forward-Port-Of: odoo/odoo#250141
Forward-Port-Of: odoo/odoo#249819

When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate.

Steps to reproduce the error:
- Install ``l10n_it_edi`` module with demo data
- Switch to IT Company
- Create a new invoice > Customer: IT Company > Add a product > Confirm >
  Send > Send
- Actions > Print > XML FatturaPA

Traceback:
```py
TypeError: string indices must be integers, not 'str'
```

In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary.
However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2].
If ``_get_invoice_legal_documents`` returns a dictionary instead of a list,
the following logic incorrectly iterates over dictionary key which leads to the above traceback.
https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26

[1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9
[2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403

sentry-7272542156

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

Forward-Port-Of: odoo/odoo#249408

…r rejections

Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors.

The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use.

This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ...

The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading.


See-also: #243119

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

After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language: when the backend language and the frontend language are not read in the same direction (RTL / LTR), the frontend language is taken to display the previews (see [f9c77de]). This is the right approach to show the snippets themselves, but the order of the columns should be done according to the backend language, which is the one that gives the instructions for the overall UI.

To reproduce:
- Set the admin's language to arabic
- Clear the cache and refresh your page
- Edit and open the add snippet dialog
- Navigate with Tab => The 1st focused snippet is in the wrong column compared with the rest of the UI.

[9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113
[f9c77de]: https://github.com/odoo/odoo/commit/f9c77de84aa6ea705e5d3f129328fb2199103b9a

task-5109547

Forward-Port-Of: odoo/odoo#228414

Steps to reproduce:
- Have facturae modules installed
- Generate invoice with any amount
- Send to Facturae

Issue:
Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost.

When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)."

According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places.
This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies.

[1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844
Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf)


opw-5927356

Forward-Port-Of: odoo/odoo#249674
Forward-Port-Of: odoo/odoo#248882

Steps to produce:
---
- Install `calendar` module.
- Go to `Calendar and create a new event using quick create`.
- Set Location and Notes and other values.
- Click `More options`.

Issue:
---
- When the full form view opens, the `Location, Notes and Privacy`
  fields are empty, even though they were filled in the
  quick-create dialog.

Root cause:
---
- At [1], [2] & [3], `Location, Notes and Privacy` values are
  correctly stored in the location, notes and privacy
  fields respectively.
- When opening the full form, default values are built via
  `getDefaultValuesFromRecord`.
- And here at [4], location,notes and privacy are missing from the
  `QUICK_CREATE_CALENDAR_EVENT_FIELDS`.
- As a result, these fields are skipped and not passed through the
  context, causing data loss.

Solution:
---
- Add the location and privacy fields to the
  `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they
  are included when generating default values for the
  full form view.
- And replace `description` with `notes`.

Note:
---
- As this is a small and simple case, the test has not been added to avoid unnecessary overhead.

[1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381
[2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407
[3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403
[4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17

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

Forward-Port-Of: odoo/odoo#247117

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#98701

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

Ticket [link](https://www.odoo.com/odoo/project.task/5913088)
opw-5913088

Forward-Port-Of: odoo/odoo#249272
Forward-Port-Of: odoo/odoo#247537

## Issue Before This PR:
The fields `used_weight_percentage` and `used_volume_percentage` in the
list view were showing incorrect values. These fields were incorrectly
aggregating totals across all batches, as the calculation of
`estimated_shipping_weight` and `estimated_shipping_volume`
was not handled per batch, resulting in wrong percentages.

## Steps to Reproduce:
- install inventory module and enable settings for
  batch transfers and dispatch management,
- add two batch records with vehicles assigned
  (having weight or volume capacity), and transfers
  having products with weight or volume defined
- Observe different values of weight % or volume %,
  in form and list view.

## Cause of the Issue:
In the method `_compute_estimated_shipping_capacity`
the computation loop referenced all records together,
causing totals to be shared across batches.

## With This PR:
Each batch now computes its own estimated shipping weight and volume correctly,
ensuring correct per-batch values consistent with the form view and
match what users see when opening individual records.

Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7)

Forward-Port-Of: odoo/odoo#249239

Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong.

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**Observed Behavior:**
Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related: https://github.com/odoo/enterprise/pull/100142

opw-5167898

Forward-Port-Of: odoo/odoo#237262

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#100142

Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.

Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.

Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
  so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
  `super_domain + [('rent_periodicity', '=', False)]`, only
  `[('rent_periodicity', '=', False)]` was returned, and
  `super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
  `sale_ok = True` were not applied.

Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.

[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49

opw-5902403
---

Forward-Port-Of: odoo/enterprise#107639

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#100142

### The problem
Suppose we have two users, A and B, who are on the same account.move and click the same button to make the same API call.
Suppose B clicks their button just a bit before A's transaction commits. This is what the transactions might look like:

1. A clicks on the button, so the transaction starts...
2. A checks whether the move can be sent -> it can!
3. A acquires a lock on the account.move
4. A does the API call
5. A writes on the account.move

At some point between 1 and 5, B starts their transaction:
6. B clicks on the button, so the transaction starts...

Then, A commits the transaction:
7. A commits the transaction -> the lock is removed!

Then:
8. B checks whether the move can be sent -> it can because B is working on an outdated snapshot of the DB.
9. B acquires a lock on the account.move -> no problem!
10. B does the API call -> no problem!
11. B writes on the account.move -> now there might be a SerializationError.

But in the meantime, both A and B performed a non-idempotent external API call...

### Analysis
The biggest problem is that when B checked whether the move could be sent, it wasn't working on an up-to-date snapshot of the DB.

Another problem is that when B checked whether the move could be sent, it didn't yet have a lock acquired on the account.move.

### Solution
We introduce a `_critical_section` context manager that ensures that:
- only one database session can enter this context manager at a time for the given records (thanks to a lock);
- when you enter this context manager you automatically get an up-to-date snapshot of the DB (thanks to an env.cr.commit)
- committing is forbidden within this context manager (to ensure you don't lose the lock).

### How to use this context manager:
- Enter it right before you check whether the API call should be made (e.g. checking whether the API was already called).
- Exit it after you have written the state resulting from the API call.

task-none

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, Quadrum seems to accept this.

We don't perform the modification for other PACs.

opw-4222310

__

## Short functional explanation of the error
When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page.

## Reproduction Steps
1. Go to Time off > Configuration > Time off Types and click on any time off type.
2. A smart button Allocations should appear with a number in it. Note the number and click on the button.
3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation.
4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now.
5. Go back to the Time off type page and look at the number on the Allocations smart button.

### Expected behavior
As the allocation we set is still valid, the number shouldn't have changed.

### Unexpected behavior
The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity.

## Origin of the issue
The domain of the allocations to take into account when computing the count of valid allocations is defined here:
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year.
The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above.
__
opw-5504272

Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5
in Odoo), the JS sanitization process aggressively removes html attributes with
`-->`, `<style` and `<title` for security reasons (see [1]).

However `html_editor` embedded components use `data-attributes`
(`data-embedded-props` and `data-embedded-state`) to store various kind of data
as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex
and these attributes are therefore removed, which results in an Editor crash.

There are multiple reasons why such values are acceptable as is for the
`html_editor` usage:
- only `HTMLElement` instances are sanitized, never a string, therefore there is
  no `DOMParser` to trick with invalid HTML.
- values in these attributes are always/exclusively parsed as JSON strings, and
  the editor will crash if the value is not a legit JSON.
- values in these attributes are HTML escaped by the python sanitizer when the
  serialized html is sent to the server.
- values in the JSON parsed object are at worst rendered as plain text (never as
  HTML or other parsed formats).
- values in the JSON parsed object are never executed as JS (only serializable
  primitives are stored).

Therefore, the suggested solution is to encode the values during sanitization,
and decode just after, to keep the rest of the codebase simple and explicit.

[1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml

task-5960707

**Steps to reproduce:**
- Install l10n_ro_saft
- Switch to a Romanian company (e.g. RO Company)

- Create an asset model:
  * Method: Straight Line
  * Duration: 12 Months
- Configure a "Fixed Assets" account:
  * Automate Asset: Create and validate
  * Asset Model: [the asset model created above]
- Create a bill:
  * Vendor: [create a new vendor]
  * Bill Date: [last month]
  * Invoice Line: [A line with the fixed asset account]
- Confirm the bill

- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Select the current month (The fixed asset account should be present)
- In the cog menu, select "SAF-T (D406 Asset Declaration)"

**Issue:**
A traceback is raised while trying to display the name of a supplier.

**Cause:**
To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report.
In this case, it's the current month.
However, the created bill has been posted the month before.
So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict.

**Solution:**
Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft.


opw-5499918

Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong.

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**Observed Behavior:**
Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related: https://github.com/odoo/enterprise/pull/100142

opw-5167898

Forward-Port-Of: odoo/odoo#237262

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#100142

Steps to produce:
---
- Install sales module.
- Open sales module > orders > switch to kanban view.
- Then make it group by status.

Observation:
---
- The order of status is not proper.
- It comes as Cancelled, Quatation, Sale order, Quatation sent.

Root cause:
---
- When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself.
- Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order  as `cancel, draft, sale, sent`.

Solution:
---
- Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly.
- This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view.

opw-5497664

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

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854