### Issue:
When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set 
A missing required fields error is raised

### Cause:
This PR: https://github.com/odoo/odoo/pull/238911
introduced a required field to prevent an error modal from appearing 
While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically

### Fix:
A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date

The validation modal is still enforced afterward to ensure data consistency in case of manual edits

### Steps to reproduce:
- Install `account`
- In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only`
- Create and print an invoice (any data) or use an existing one
- Import it into Vendor Bills
- Click Digitize Document

### Before the fix:
A missing required fields notification is raised, preventing digitization

opw-5886012

Forward-Port-Of: odoo/enterprise#112585

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355

Forward-Port-Of: odoo/enterprise#112638

# How to reproduce
- Install the eLearning module
- Log in as a portal user
- Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course)
- Go to Courses > View your profile (on the right side) > Edit Profile
- Edit any value and confirm by clicking on the Update button

# The problem
The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records"

# Why
In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe :

https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615

This was the case because we preventively filtered only the safe fields in the save controller :

https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153

In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled :

https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884

One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed.

# Proposed solution
We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo`

opw-6032339

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

Forward-Port-Of: odoo/odoo#256888

Issue:
Export XML button doesn't produce the same file as the send button.

Steps to reproduce:
- Company in Spain with Peppol (work with any Peppol country)
- Partner in Croatia
- Select eInvoice Type as "EU Standard (Peppol Bis 3.0)"
- Create an invoice
- Confirm it
- Click on the Wheel -> Download

Current behavior:
- without l10n_hr_edi: only "PDF" and "PDF without Payment"
- with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file

Cause:
"Export XML" button appear only if:
- there is a default ubl option for the partner country
- there is an XML attached to the invoice when clicked it exports the corresponding one.

Whereas, the 'send' button rely on:
1) the partner defined edi format,
2) the default ubl option for the partner country
3) "ubl_bis3"

To be noted:
The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice.

opw-5943500

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

Forward-Port-Of: odoo/odoo#257990
Forward-Port-Of: odoo/odoo#253650

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product.

Steps to produce:
---
- Install the `eCommerce Rental with Stock Management` module.
- Create a rental product and set Quantity On Hand to 1.
- Under the Sales tab, disable `Sell when Out of Stock`.
- Under the Rental Prices tab, add pricing.
- Go to `website > ecommerce > products > product ribbons`.
- Open `out of stock` ribbon > set assign as `when out of stock`.
- Create and Confirm a rental order for that product and validate the pickup.
- The product's Quantity On Hand drops to 0.
- Opening the product on the website

Observation:
---
- The product shows the out-of-stock ribbon.

Cause:
---
- At [1], the or condition evaluates to True because the ribbon is configured
  as `when out of stock`, `Sell when Out of Stock` is disabled under the
  Sales tab, and `_is_sold_out` also returns True since the quantity dropped to
  0 after the pickup was validated. As all conditions are met, the ribbon
  is returned and displayed without ever checking whether the product is
  a rental.

Skip the out-of-stock ribbon assignment for rental products, since their
stock availability is time-based.

[1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28

opw-6081483
---

Forward-Port-Of: odoo/enterprise#113280
Forward-Port-Of: odoo/enterprise#112660

When creating tasks from a project template via a Sales Order, the main
task is created with its sale_line_id set correctly, but subtasks from
the template do not inherit the sale_line_id from their parent.

Steps to reproduce:
1. Create a project template with a parent task and subtasks
2. Create a service product that uses this project template
3. Create and confirm a Sales Order with this product
4. Check the created tasks: main task has sale_line_id, subtasks don't
5. Log hours on a subtask: the timesheet's so_line remains empty

Root cause:
When copying a project template, the copy_data() method for subtasks
was resetting the default dict to only contain 'parent_id': False. This
meant that whitelisted fields like sale_line_id from the parent task
were not propagated to the subtasks during the copy operation.

Solution:
When copying from a template (copy_from_template context), preserve
whitelisted fields (including sale_line_id) in the default dict before
copying subtasks. This allows subtasks to naturally inherit sale_line_id
from their parent during creation, so the compute method works correctly.

opw-5185519

Forward-Port-Of: odoo/odoo#236342