**Steps to reproduce:**
- Install the `l10n_fr_reports` module and switch to the FR Company.
- Navigate to Invoicing > Reporting > Fiscal Declaration and select `2033 B`.
- Observe the formula of `A - Accounting income` > `Operating expenses (II)`.

**Observation:**
The formula does not include the balances of `FR_2033_B_c244`, 
`FR_2033_B_c250`, and `FR_2033_B_c252`.

**Root Cause:**
At [1], the formula for `Operating expenses (II)` is missing the
balances of fields `244, 250, and 252`, even though these lines are part
of the operating expenses section.

**Fix:**
This commit ensures that `Operating expenses (II)` displays the 
correct total balance.

**Reference**:
<img width="1422" height="490" alt="6482797" src="https://github.com/user-attachments/assets/95b35ac7-f410-413b-8ef9-29f97f16c35a" />

[1]:
https://github.com/odoo/enterprise/blob/54bfcbee37a241ae70b9bebb9cf23d76172e18fe/l10n_fr_reports/data/fiscal_declaration/report_2033_B_simplified_profit_loss.xml#L302

opw-6482797

Forward-Port-Of: odoo/enterprise#129348

Here is the leaves behavior:

Stored field readonly (shouldn't be edited): `date_from/to` -> UTC reference

Stored fields editable to request:
- time type in days: `request_date_from/to`
- time type in halves: +`request_date_from/to_period`, `request_duration` (multidays/solo)
- time type in hours: +`request_hour_from/to` (not in the view)

Computed field, (editable for a time type in hours): `request_date_hour_from/to` -> converted to the reader tz

It means no more cycle exits:
`request_date_hour_from/to` edited
=> inverse will update requests stored fields
=> date_from/to will be recomputed based on the request stored fields

The purpose of using `request_date_hour_from/to` is to display for the user the same range of hours for employees with different tz

Other little fixes around:
- _to_utc(): round the hour to the whole minute, where the carry can reach the hour, and stop at the end of the day, as float_to_time takes neither a minute 60 nor an hour 24.
- _split_leaves(): both parts are whole where they are cut and carry the request_duration their periods describe, dates included, instead of the half day copied from the original.
- _get_hours_for_date(): a day the schedule leaves out borrows the hours of the nearest day it names, not the widest hours of the whole schedule, which no single day of a two week rota works; a schedule naming no hour at all falls back on an average day centred on midday, where it used to leave the request without any extent.
- _compute_last_several_days(): a request whose end precedes its start is one being edited, not one of several days, so moving one bound of the pair before the other catches up no longer snaps the duration back onto whole days.

task-6459867

**Steps to reproduce:**
* Install `l10n_co_dian`.
* Configure a company with the Colombian localization.
* Set up a DIAN operation mode for Electronic Invoices only (no Support Documents mode).
* Create a vendor bill marked as a Support Document and click **Send to DIAN**.

**Observed behavior:**
* A cryptic server error is raised: *"TypeError: unsupported operand type(s) for +: 'int' and 'str'"*
* No actionable information is shown to the user.

**Cause:**
* `_add_document_config_vals` assigns `vals['l10n_co_dian_operation_mode']` via `.filtered()`, which returns an empty recordset when no matching operation mode exists.
* Accessing a `Char` field on an empty recordset returns `False` (a `bool`, which is a subclass of `int` in Python).
* Concatenating `False` with strings in the `sha384` hash calculation raises the `TypeError`.
* The missing-mode guard only existed in the commercial events path, not in the main invoice export path.

**Fix:**
* Raise a descriptive `UserError` that tells the user which mode is missing and where to configure it.

opw-6499321

Forward-Port-Of: odoo/enterprise#130853
Forward-Port-Of: odoo/enterprise#128935

### Problem

`label` on `account.reconcile.model.line` is a **translatable** field, but its value is
written onto the journal item created when the model is applied (`account.move.line.name`).

That means the label is read in the language of whoever applies the model:

- a user working in another language writes the translated value;
- the auto-reconciliation cron writes the **source** value, since it runs as OdooBot.

So the very same reconcile model ends up writing two different labels on the journal items,
depending on who applied it.

### How it shows up

It becomes visible when a reconcile model is created by **duplicating** an existing one and
the label is then edited while working in a non-source language. The translation holds the
new text, while the source value silently keeps the label of the original model — and the
source value is exactly the one the cron writes. The result is a set of journal items where
some carry the intended label and some carry the label of an unrelated model.

### Fix

The journal item belongs to the company, so the label is read in the **company** language
via a small `_get_aml_label()` helper, instead of the language of the current environment.
It falls back to the current behaviour when the company has no language set.

`_prepare_aml_vals()` is the only place in 18.0 that reads `self.label` for the journal item.

### Test

Adds `TestBankRecWidget.test_auto_reconcile_model_label_uses_company_lang`: a reconcile model
whose line label is translated in the company language, applied by the auto-reconciliation
cron running in the source language, and asserts the journal item carries the company-language
label.

```
odoo -d <db> -u account_accountant --test-enable --stop-after-init \
  --test-tags /account_accountant:TestBankRecWidget.test_auto_reconcile_model_label_uses_company_lang
```

Without the fix the test fails with `[{'name': 'Frais bancaires'}] != [{'name': 'Bank fees'}]`;
with the fix it passes. The full `account_accountant` suite was also run on a clean 18.0
database: 203 tests, 0 failed, 0 errors.

Forward-Port-Of: odoo/enterprise#130865
Forward-Port-Of: odoo/enterprise#128433

Steps to reproduce
---
1. Enable Work Orders.
2. On a product's BoM, add an operation carrying an Instructions step.
3. On a small screen, create a manufacturing order for that product, set the product and save.

Expected: the MO is saved and the generated work order carries its BoM operation.
Actual: saving raises `Missing required field 'Product' (product_id) for model 'Stock Move'`, and once that is bypassed the generated work order has no operation, so its
`quality_point_ids` stays empty and no `quality.check` is created.

Issue
---
On a small screen the MO form resolves its x2many relations to their kanban sub-views, so the fields carried in the onchange and save payloads are only those the active sub-view declares;
two relations lose data this way.

`move_finished_ids` is an invisible relation that always holds the product's finished move, built on the draft by `_compute_move_finished_ids` through `_get_moves_finished_values` with
`product_id` and `product_uom_qty` set.
https://github.com/odoo/odoo/blob/c9012f5ae48e29ff49391b722ed798237c448805/addons/mrp/models/mrp_production.py#L1354-L1371
https://github.com/odoo-dev/odoo/commit/c9012f5ae48e29ff49391b722ed798237c448805 gave that field `mode="list,kanban"` while only a `<list>` sub-view is defined for it.
https://github.com/odoo/odoo/blob/c9012f5ae48e29ff49391b722ed798237c448805/addons/mrp/views/mrp_production_views.xml#L405-L410
On a small screen the field resolves to kanban mode, but since no kanban sub-view exists its field spec comes out empty, so on the first save the client sends the finished move as an empty
create and the `stock.move.product_id` NOT NULL constraint aborts the whole save, so no MO can be created on mobile. The field is invisible and never rendered, so it has no use for a
kanban view in the first place; dropping the kanban mode keeps it on its list spec, which carries `product_id`, on every screen size, while the visible Components and By-Products lists are
unaffected because they resolve a populated kanban sub-view.

The `workorder_ids` kanban sub-view must likewise carry `operation_id`, or the generated work order is saved without an operation and its `quality_point_ids` stays empty, so no
`quality.check` is created. https://github.com/odoo-dev/odoo/commit/e3f6cef5cf94391b5c018c5eb44ce1ddee99290b had restored the invisible `operation_id` on that kanban and https://github.com/odoo-dev/odoo/commit/6318895101435a0a9d4bdff0b8dbfbb17179378e dropped it again in a kanban rework, so it is restored.

opw-6488529

X-original-commit: https://github.com/odoo-dev/odoo/commit/af70218f325147a51ca6e46f4827d697c7ed7801

Fix for #286871.

opw-6543997

### The problem

`web.AceField` and `web.IrUIViewAceField` render their root div with the
`o_field_widget` class, but the `Field` wrapper already puts that class on the
div it renders, along with the `name` attribute. Every ace field therefore
renders a nested `o_field_widget` with no name:

```html
<div name="my_field" class="o_field_widget o_field_code ...">
    <div class="o_field_widget oe_form_field o_ace_view_editor oe_ace_open">
        <div class="ace_editor">... <textarea class="ace_text-input">
```

Any code that goes up from a DOM node with `closest(".o_field_widget")` to find
which field was clicked stops on the inner div, finds no `name` and cannot
resolve the field.

`iap_extract` does exactly that, in a `focusin` listener on `window`, and
`account_invoice_extract` installs its renderer for `account_move_form` with
`force: true` — so it runs on every invoice form. With no name on the inner div
it builds `"<parent_field>.null"`, and since the name now contains a dot,
`getBoxType` takes the x2many branch:

```js
modelFieldType = this.props.record.data[parentField]?._config.fields[fieldName]?.type;
```

For a `widget="code"` field, `record.data[parentField]` is a plain string. It is
truthy, so the optional chaining does not short-circuit, but it has no
`_config` → `undefined.fields` → `TypeError: Cannot read properties of
undefined (reading 'fields')`, and the whole form breaks.

### Steps to reproduce

1. Install `account_invoice_extract`.
2. Put a `widget="code"` field on the `account.move` form view (with
   `l10n_ar_edi` installed there are already two on the ARCA tab).
3. Give the field a value — with an empty value the error does not happen.
4. Enable developer mode and click inside the code editor.

Reproduced on a plain 19.0 runbot build.

### The fix

Drop `o_field_widget` from the root div of both ace templates, since the
wrapper already provides it. The only rule that relied on both classes being on
the same element was `.o_field_widget { &.o_ace_view_editor { ... } }` in
`fields.scss`; it becomes a descendant selector, so the rendering is unchanged.

`account_invoice_extract` / `iap_extract` could be made more defensive as well
(`?._config?.fields[...]`, or not building a `parent.child` name when the
closest `.o_field_widget` has no `name`), but that lives in enterprise and the
duplicated class looks like the actual root cause.

**Steps to reproduce:**
* Install the **Accounting** (`account`).
* Create a **Depreciation Model** (e.g. Linear, 5 years).
* Create an asset, assign the depreciation model, and confirm it.
* Go to **Accounting → Configuration → Depreciation Models** and delete the model used by the running asset.
* Try to **Reset to Draft** on **asset**.

**Observed behavior:**
* The depreciation model is deleted silently.
* The asset's `model_id` FK becomes `NULL`, causing all related fields (`method`, `method_number`, `method_period`, `journal_id`, etc.) to become empty.
* Any subsequent attempt to cancel, reset to draft, or delete the asset fails with a **missing required field** error, leaving the asset permanently unmanageable.

**Cause:**
* `account.depreciation.model` had no `@api.ondelete` guard — deletion was entirely unprotected, unlike `write()` which already blocks edits on models used by running assets.
* `model_id` on `account.asset` had no `ondelete` constraint, so the database silently NULLed the FK on model deletion.

**Fix:**
* Add an `ondelete='restrict',` on a asset's `model_id` field to prevent deletion of a depreciation model that is in use by any asset.

opw-6233210

Forward-Port-Of: odoo/enterprise#130859
Forward-Port-Of: odoo/enterprise#126979

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#286644
Forward-Port-Of: odoo/odoo#281420

Printing an invoice for a Saudi partner raises an error.

Steps to reproduce the error:
- Install ``l10n_sa_edi`` module with demo data
- Switch to My Saudi Arabia Company
- Create a new Partner A > Country: Saudi Arabia > VAT Number: 311111111111113 >
  Click on + Button > Click Tax Identification Number > Save
- Create a new invoice > Customer: Partner A > Add a product > Confirm >
  Print the invoice

Traceback:
```py
AttributeError:
'account.edi.xml.ubl_21.zatca' object has no attribute '_l10n_sa_get_tin_from_vat'
```

https://github.com/odoo/odoo/blob/2e2054d4203f6453fb35ec6037cda0e2e9033cc3/addons/l10n_sa_edi/models/zatca_ubl_mixin.py#L154-L156
In [Commit], ``_l10n_sa_get_tin_from_vat()`` method is called on self to retrieve ``identification_number``.
however, self is an ``account.edi.xml.ubl_21.zatca`` record, while ``_l10n_sa_get_tin_from_vat()`` is a method of ``res.partner``. 
So, It will lead to the above traceback when printing the invoice.

Solution:
Call the ``_l10n_sa_get_tin_from_vat()`` method on the partner record instead of self.

[Commit]: https://github.com/odoo/odoo/commit/227f61e2cb8582d0c3269bb0ae7256250563847a

sentry-7717905761

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

Forward-Port-Of: odoo/odoo#287173

Description of the issue/feature this PR addresses:

Downloading an attachment from the file viewer fails with a `405 Method Not Allowed` error when the attachment belongs to a Discuss channel.

I've already submitted a ticket to Odoo: #6430586

Steps to reproduce (on a 18.0 runbot):
1. open Discuss and send an image in a channel
2. click the image to open the file viewer
3. click the download button (either the one in the header or the one in the bottom
   toolbar)

The server rejects the request:

```
POST /discuss/channel/1/image/519861?filename=image.png&unique=32647b0f&download=true  405
```

and the user gets a `RPC_ERROR: Arbitrary Uncaught Python Exception` dialog reporting `405 Method Not Allowed`.

Cause: `download()` always issues a POST request, while the routes serving the attachments of a discuss channel only allow GET:

* `/discuss/channel/<int:channel_id>/attachment/<int:attachment_id>`
* `/discuss/channel/<int:channel_id>/image/<int:attachment_id>`

so the request never reaches the controller. Downloading the very same attachment from the attachment card in the conversation still works, because that one is a plain anchor navigation (GET).

This is a regression from fb152985f4b8 ("[FIX] web: download FileViewer files via blob helper"), which routed the file viewer download through `download()` in order to honor the filename sent by the server in the `Content-Disposition` header.

Only 18.0 is affected: saas-18.1 and saas-18.2 do not have the commit that introduced the regression, and from saas-18.3 on, the `urlRoute` override was dropped and channel attachments are served through the standard `/web/content` and  /web/image` routes, which are not restricted to GET. 
The download is still sent with POST on those branches though, hence forward-porting this up to master.

Current behavior before PR:

Downloading a Discuss channel attachment from the file viewer raises a 405 error and the file is not downloaded. Images and other file types are equally affected.

Desired behavior after PR is merged:

The file is downloaded, keeping the filename advertised by the server. The download is performed with a GET request through `downloadFile()`, which still goes through the blob helper, so the fix of fb152985f4b8 is preserved. This is already the way a file is downloaded from its url in `readonly_file.js`.

Added a test that downloads an image attachment of a channel from the file viewer and asserts the request is a GET on the channel attachment route. It fails before this fix with `POST /discuss/channel/1/image/1`.

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

Forward-Port-Of: odoo/odoo#287172
Forward-Port-Of: odoo/odoo#279232

**Description of the issue/feature this PR addresses:**

When selecting Unsplash images from a relational field (which uses `CustomMediaDialog`), the images would fail to process or link correctly to the target record.

In the web editor, Unsplash image selections are handled by patching the base `MediaDialog`. When a user selects an Unsplash image, that patch intercepts the save action and uses the `unsplash` service to notify the backend. The server then fetches the external Unsplash URL and converts it into a native `ir.attachment` record before the frontend completes the save.

Because `CustomMediaDialog` is a distinct component used for relational fields, it bypassed the existing `MediaDialog` patch entirely and lacked this specialized fetch-and-convert logic.

This commit introduces a parallel patch specifically for `CustomMediaDialog`. It intercepts `imageSave`, routes any Unsplash records through the `unsplash` service, and replaces the raw Unsplash records with the newly generated Odoo attachments before executing the underlying save.

**Steps to reproduce:**

- POS > Products > Products > choose any product > click the ‘edit’ button in the image > search something, e.g. ‘burger’ > add Unsplash Access Key and Application ID when prompted > select one of the resulting Unsplash images

**Current behavior before PR:**

- Error when saving an unsplash image when editing product images

**Desired behavior after PR is merged:**

- No error when saving an unsplash image when editing product images

opw-6445843

Forward-Port-Of: odoo/odoo#285954
Forward-Port-Of: odoo/odoo#283694

**Steps to reproduce:**
1. Install Payroll and Time Off modules on v19.2.
2. Create a public holiday via the form view (Time Off -> Configuration -> Public Holidays). Do not enter a work entry type and save.
3. Open Payroll and try to create a payslip for any employee in the same month as the public holiday you will face below traceback.

**Issue:**
The `work_entry_type_id` is required for payroll calculations. If it is null the `_round_days` calculation evaluates an empty recordset, producing a [ValueError](https://github.com/odoo/enterprise/blob/39095789c2b6a7e558d11f479a249871b3b800b6/hr_payroll/models/hr_payslip.py#L1021
). 
While in this [PR](https://github.com/odoo/odoo/pull/254666/changes) made this field was made required in the
list view, it was missed in the form view. This allows users to save a holiday without a work entry type, crashing payslip generation later.

**Solution:**
Make the `work_entry_type_id` field required in the form view as well to prevent the creation of inconsistent public holiday records.

**Traceback:**
```.py

  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/hr_payslip.py",
line 1021, in _round_days
    day_rounded = float_round(days, precision_rounding=precision_rounding,
rounding_method=work_entry_type.round_days_type)
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/float_utils.py", line 152, in
float_round
    raise ValueError(msg)
ValueError: unknown rounding method: False
```

opw-6477587

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

Forward-Port-Of: odoo/odoo#285597
Forward-Port-Of: odoo/odoo#283762

Currently an exception is generated when the user tries to change the
value of `Prefix` or `Suffix` in sequence as the following steps
- Create a sequence with `Use subsequences per date_range` and
  add any `From` and `To` dates
- Save record > Change the value of `Prefix` or `Suffix`

Error: `TypeError: %d format: a real number is required, not NewId`

This issue was introduced by the recently refactored changes in commit [1],
which added an onchange method for the prefix and suffix fields.

When the user changes either field, the onchange is triggered and recomputes
all dependent fields, including `_get_number_next_actual` on
`ir.sequence.date_range`. During this computation, the record contains the
`NewId` record. As a result, using `%03d` to format the record ID raises the
reported error, since NewId cannot be formatted as an integer.

This commit fixes the issue by defaulting `number_next_actual` to `0`
when `_get_number_next_actual` is invoked with a `NewId` for the
related sequence while computing the value during `onchange`.

[1]: https://github.com/odoo/odoo/commit/387b2289da68454599666bf96844b22c41c5cc55


Sentry-7609468821

Forward-Port-Of: odoo/odoo#277766

The embedding model deprecation cron starts by searching for chunks that are embedded using a model that hasn't been deprecated. However, due to an optimization in the ORM (optimize_type_selection), the search doesn't return any result.

A domain that uses the 'not in' operator is converted by the optimization to use the 'in' operator and the values are replaced by the difference between the available selection values (self._selection) and the values in the domain. So, given that the selection values of the embedding_model field are the non deprecated embedding models and the search domain of the cron is ['embedding_model', 'not in', non deprecated embedding models] , the final domain will be
['embedding_model', 'in', non deprecated models list - non deprecated models list] = ['embedding_model', 'in', []] which will retrieve nothing from the DB because all records have an embedding_model.

The main issue is that the optimization assumes that the available selection values are static. However, an old embedding model can be deprecated and a new one added which makes the optimization fail. So, the selection values are changed to be computed dynamically which will be skipped by the optimization.

Forward-Port-Of: odoo/enterprise#128130

### Issue:
An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries
Some Italian banks reject SDD files containing this node

### Cause:
https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries
The original fix was intended for Nordea (Sweden) only, which requires this node explicitly
The assumption that other countries would accept it was incorrect

### Steps to reproduce:
- Install `account_sepa_direct_debit` and `l10n_it`
- Switch to the IT company
- In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042`
- Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount)
- Create and validate a Batch Payment with that payment
- Open the generated PAIN008 XML

Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present

opw-6530996

Forward-Port-Of: odoo/enterprise#130304