The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment

The Nilvera client returns base64-encoded PDF content from the GET pdf
endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string
directly into the `ir.attachment.raw` field without decoding. Because
the field is binary, the base64 ASCII text was UTF-8 encoded on the disk,
leaving the files unreadable in browsers.

This commit introduces a migration script to fix this.

For newly downloaded attachments, 35fd6ce handles the decoding.

task-6377121

This fix prevents payment document creation from failing when accounting views pass an unrelated document type value. If the incoming type is not valid for Documents, the system now uses the standard default so EDI payment updates can proceed normally.

In certain scenarios, a default_type context can be passed during document creation, and this value may not exist in the type selection field, as it may come from a type in another model.

Steps to reproduce using MX EDI update payment:
- Setup a Mexican company with MX EDI
- Install the documents_account module and create a folder for journals where you will place customer payments (ex: journal PAY/)
- In accounting views, group journals by type, which will adds default_type = <journal type> when opening entries from this view
- From this view, open the Customer Invoices journal, create and post an invoice
- Register a payment, and then click on Update Payment button, which will triggers an EDI document creation with default_type="sale" in the context, causing the error 'ValueError: Wrong value for documents.document.type: "sale"'

This fix falls back to the default document type if the type in the context is not in the selection, preventing the error and allowing the document to be created correctly.

opw-5742850
opw-6182877

Refreshing an accounting report now clears the previous search from the session, so downloaded Excel files reflect the partners currently shown on screen. This avoids confusing mismatches where the page shows all partners but the export still contains only an earlier search result.

**Steps to reproduce:**
- Install account_reports
- Open "Partner Ledger" (make sure there are several partners)
- Make a search to only display 1 partner
- Download XLSX
- Without changing the search text, refresh the page
- Download XLSX again

**Issue:**
After refresh, the search text is empty and all the partners are displayed in the report.
However, in the XLSX file, only the partner from the previous search is present.

**Cause:**
The current search is kept in the session and used when getting the XLSX.
When refreshing or leaving the page, it's still kept in the session even if the search bar has been reset.

opw-6333212

`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`. Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become `["P00001", "P00002"]`. That still leaves a bad case: blank or whitespace-only content still produces empty refs. For example, `","` becomes `['', '']`, and since https://github.com/odoo/odoo/pull/225294 on 18.4+ during foward port it's gotten even worse: " commission" becomes `['', 'commission']`

`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`.

Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become `["P00001", "P00002"]`.

That still leaves a bad case: blank or whitespace-only content still produces empty refs. For example, `","` becomes `['', '']`, and since https://github.com/odoo/odoo/pull/225294 on 18.4+ during foward port it's gotten even worse: " commission" becomes `['', 'commission']`

This problematic because `invoice_origin` does not always contain real PO refs. Since odoo/odoo#207037, XML imports can also fill it with concatenated line descriptions which contains arbitrary text. We recently hit this on odoo.com with a Peppol bill where this led to parsed refs including `''`.

Once `['']` is passed to `_match_purchase_orders()`, POs with an empty `partner_ref` can enter the candidate set. From there, the normal amount or line matching can link the bill to a wrong PO (which will always happen with the number of POs and PO lines we have on prod)

odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again. task-6279460

odoo/odoo#155588 was a workaround to the lack of location permissions in the iOS app, skipping geolocation entirely for check in/out. Since odoo/mobile#118 added support for them, we can now revert that fix so iOS users get prompted for their location again.

task-6279460

Once a ZATCA invoice is posted, the "Reset to Draft" button is still shown on the form until the chain index is set on the move. In that window, a user can click it (or force it visible from Studio on an already-accepted invoice) and reset the move to draft, even though it has been -- or is about to be -- submitted to ZATCA. The invoice can then be resubmitted, breaking the ZATCA chain. Steps to reproduce: 1. Configure a SA company and set up ZATCA. 2. Create and post a customer invoice. 3

Once a ZATCA invoice is posted, the "Reset to Draft" button is still shown on the form until the chain index is set on the move. In that window, a user can click it (or force it visible from Studio on an already-accepted invoice) and reset the move to draft, even though it has been -- or is about to be -- submitted to ZATCA. The invoice can then be resubmitted, breaking the ZATCA chain.

Steps to reproduce:
1. Configure a SA company and set up ZATCA.
2. Create and post a customer invoice.
3. On the posted invoice, click "Reset to Draft" -> the move becomes draft, while the ZATCA submission still goes through.

Fix:
- Add a user error on account.move.button_draft if the invoice has l10n_sa_chain_index set

task-6208977

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

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing. Steps to reproduce: - create a product in Units with available stock - create a delivery for 2 Dozen of it and mark it as todo - in the detailed operations, change the unit of the move line to Units (24) - lower the

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image. This fixes the issue by showing a placeholder icon if no module is found for the activity group. opw-6282451 Previous behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" /> New behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attac

When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image.

This fixes the issue by showing a placeholder icon if no module is found for the activity group.

opw-6282451

Previous behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/1e4fc1d5-3a35-4193-80fc-f6d161776e2e" />

New behavior:
<img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/6ed5ca8b-8481-470f-b7c6-dd59c616125e" />

(Original PR: https://github.com/odoo/odoo/pull/268957 Re-based on 17.0 as its the earliest version affected, so it can be forward-ported to future versions)