### Description of the feature this PR addresses:
**Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.**

A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190.

### Current behavior before PR:

Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it.
This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model).

**In practice, this separation is necessary because:**

- Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment.
- Withholdings made on these amounts must be declared in specific sections of Form 190.
- If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted.

### Desired behavior after PR is merged:

A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to:
- Correctly identify and calculate the related amounts.
- Report them separately in the AEAT Model 190.
- A new tax group has also been created to distinguish these withholdings from regular ones.

### Benefits:

- It allows you to correctly generate Form 190, separating income derived from and not derived from work disability.
- It facilitates the accounting and tax traceability of this type of income.
- It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing.
- It improves the flexibility of the Odoo tax system, adapting it to actual tax needs.

### Technical summary:

- A **new specific tax** has been created for withholdings associated with incapacity for work benefits.
- This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.**
- In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income.

The related issue: https://github.com/OCA/l10n-spain/issues/4416

### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies”

**Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group.

**Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections.

These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll.

Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations.

**Outcome:**

- Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**.
- Clean separation from other withholdings via the new tax group.
- Consistency between accounting, payroll, and the 190 export.

Would you accept this change?


@moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 

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

Forward-Port-Of: odoo/odoo#245553
Forward-Port-Of: odoo/odoo#232515

Currently, an error occurs when user creates a payment for an invoice.

**Steps to Reproduce:**

 - Install `l10n_uk_bacs` with demo data.
 - Switch to the `UK company`.
 - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`.
 - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero.
 - `Confirm` the invoice.
 - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`.

`ValueError: Expected singleton: res.partner.bank()`

This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment 
method. The constraint check bacs bank account trigger [1], but since the journal has no bank 
account number, it raises an error here [2].
Similar error also occurs when validating a batch payment [3].

This commit ensures that if the journal has no bank account, or if the bank account is invalid, 
the system raises the same validation error. In batch mode, it raises a UserError when the 
account is missing.

[1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58

[2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19

[3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74

sentry-7259107152

Steps to reproduce:
------------------------------
1. Install Subscription module
2. Create a new subscription and confirm it
3. Create an invoice from the subscription.
  * Register a payment and ensure the invoice is in the Paid state.
4. Go back to the subscription and close it with any reason
5. Open the related invoice.
  * Create and Confirm Credit Note.
  * Register a payment for the credit note.
6. Go back to subscription

Observation:
------------------------------
The subscription is automatically set back to `In Progress` even  though it was previously churned.

Issue:
------------------------------
The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid.

Solution:
------------------------------
Add a condition to exclude refund invoices from the reopening logic

opw-5947999

Forward-Port-Of: odoo/enterprise#108487

Prerequisites:
------------------------------
1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket
2. From Settings, create one Alias Domain

Steps to reproduce:
------------------------------
1. Install Helpdesk module
2. Open Helpdesk Team > Settings
3. Inside Channels, Set the mail used for the incoming server and the alias created
4. Set Accept Emails From to Everyone
5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`)
6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail.
7. Open Incoming mail sever  > Click on Fetch Now
8. Open Created Contact

Observation:
------------------------------
The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost

Issue:
------------------------------
After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update.

https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369

Solution:
------------------------------
Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails

Note for reviewer
-----------------------------
After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address.

That said, we should also avoid automatically clearing or altering the existing value in the field.

Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint.


opw-5478067

Forward-Port-Of: odoo/enterprise#107808

Steps to reproduce:
- Activate the GS1 nomenclature
- Create a product "P1" with the barcode: 15099590225865
- Create an internal transfer with one unit of P1
- Go to Barcode > Operations > Internal Transfers
- Scan the barcode: 15099590225865 to filter transfers by this product barcode

Problem:
An validation error is raised:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined rules.
For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in   filter_on_barcode
and explicitly reset parsed_results to False, allowing the normal filter
on product resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product is correctly filtered

opw-5929064

Forward-Port-Of: odoo/enterprise#110679
Forward-Port-Of: odoo/enterprise#110636

An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation

Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```

Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown

Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.

Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.

target: saas-18.4
task-6034836

Forward-Port-Of: odoo/enterprise#110568

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

Forward-Port-Of: odoo/enterprise#106881

Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1".

In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed.

Solution: we should never have considered anything else than left-button actions anyways.

[1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb
[2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185
[3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28
[4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3

task-6055182

## [FIX] account: sequence mixin cache on cr.cache instead of precommit
The aim of this commit is to prevent the creation of Savepoint in chain.
This is achieved by preventing the `sequence.mixin` cache to be cleared
as soon as a flush happens and to prevent the `bank.statement.line`
creation to clear the cache.

### Context:
During an import of document, like a big CSV of bank statement for
example, if any issue arises, the ORM rollback to the savepoint of
import and retry to import one record at a time and rollback again
later on to collect the errors and show the faulting line to the
customer.

### Cause:
1) As we flush for every single record, the `precommit.data.cache` gets
   cleared during the flush and the `sequence.mixin` cache gets wiped
   out.
2) The creation of bank statement set the name of its move_id to False
   which results in the `sequence.mixin` code to clear its own cache by
   itself.
   [name set to False](https://github.com/odoo/odoo/blob/1361c0bc98c91f1e601b0fc3beaa948df3a3bfcd/addons/account/models/account_bank_statement_line.py#L410-L412)

Both (1) and (2) results in the sequence.mixin code to recreate the
cache and, for that, to create a new Savepoint.
This is done at each iteration of the import loop which could results
in this case in 300+ savepoints existing at the same time eating all
Postgres shared buffers memory putting the whole production database
on its knees.

task-id: None (investigated for odoo.com)

Forward-Port-Of: odoo/odoo#250827

Backport of https://github.com/odoo/odoo/pull/249869

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

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

When vendor bills digitization is deactivated, subscribers to the "Purchases" journal are not notified when a vendor bill is sent to the email alias set on the "Purchases" journal

Steps to reproduce:
1. Install Accounting
2. Go to Settings > Accounting > Digitization and set Vendor Bills to "Do not digitize"
3. Go to Settings > Technical > Email > Alias Domains and create a new alias domain (e.g. "odoo.com")
4. Go to Settings > Technical > Email > Incoming Mail Servers and create a new incoming mail server (e.g. "megu@odoo.com", you may need to setup POP access on your email address and create an app password, see https://support.google.com/mail/answer/7104828)
5. Go to Accounting > Configuration > Journals and open journal "Purchases"
6. Go to Advanced Settings tab and set the Email Alias and the Send Copy To fields (e.g. "megu@odoo.com" for both)
7. Send a mail with an attachment to the email alias set on the "Purchases" journal
8. Go to the previously created incoming mail server and click on Fetch Now
9. Go to Settings > Email > Technical > Emails
10. No email has been sent to the subscriber of the "Purchases" journal

Issue:
`_extend_with_attachments` returns None if the OCR import failed https://github.com/odoo/odoo/blob/b44295bb6ce621ff87cbc96860492650d90d0ad7/addons/account/models/account_document_import_mixin.py#L340-L349 which prevents the call to method `_notify_invoice_subscribers`

Solution:
Send an email regardless of the result of the OCR import

opw-5914096

Forward-Port-Of: odoo/odoo#252442

Trying to investigate this common issue:

https://runbot.odoo.com/runbot/build/104596176 script timeout exceeded -> internal error during screenshot + timeout error when trying to shut down service workers (but oddly `Page.stopLoading` worked so the browser might not be entirely hosed?)

https://runbot.odoo.com/runbot/build/104598123 and https://runbot.odoo.com/runbot/build/104599315 only parsed a timeout during service workers shutdown, but looking at the logs they actually have the same error, it's just that the in-band error is suppressed by the retry, but then the traceback finder goes and triggers on the TB it finds in the logs (but only the last link of the TB so the thing is cut off):
```

2026-03-19 03:48:11,239 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Asking for screenshot 
2026-03-19 03:48:11,241 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Couldn't capture screenshot: Internal error 
2026-03-19 03:48:21,249 26 _WARNING 104599315-saas-19-1-all odoo.tests.common: Error during browser shutdown 
Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 2566, in browser_js
    self.fail(str(error))
  File "/usr/lib/python3.12/unittest/case.py", line 715, in fail
    raise self.failureException(msg)
AssertionError: Script timeout exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1664, in _websocket_request
    return f.result(timeout=timeout * self.throttling_factor)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 458, in result
    raise TimeoutError()
TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1375, in _ws_winddown
    self._websocket_request('Runtime.evaluate', params={'expression': """
  File "/data/build/odoo/odoo/tests/common.py", line 1666, in _websocket_request
    raise TimeoutError(f'{method}({params or ""})')
TimeoutError: Runtime.evaluate({'expression': "\n            ('serviceWorker' in navigator) &&\n                navigator.serviceWorker.getRegistrations().then(\n                    registrations => Promise.all(registrations.map(r => r.unregister()))\n                )\n            ", 'awaitPromise': True})
```

Issue before this commit:
=========================
Clicking Produce All on a Manufacturing Order as a user with Manufacturing and Timesheet rights raised an AccessError.

During Manufacturing Order completion, Odoo creates analytic lines for work center cost distribution and links them to the work order through the wc_analytic_account_line_ids Many2many field. With the stricter ORM security checks, linking records in a Many2many field requires read access to those records. Since analytic lines are created using sudo() but the relation update runs under the current user's permissions, the operation fails due to timesheet-related record rules.

Steps to Reproduce:
=========================
1. Install mrp_account and hr_timesheet modules.
2. Create a Work Center with an analytic distribution.
3. Create a Product with a Bill of Materials (BoM) that includes a work order using the created Work Center.
4. Log in as a non-admin user with Manufacturing and Timesheet permissions.
5. Create and confirm a Manufacturing Order for that product.
6. Click Produce All.

Cause of the Issue:
=========================
Analytic lines are created with sudo(), but when linking them to the work order through the Many2many field wc_analytic_account_line_ids, the ORM checks whether the current user has read access to those records. Due to timesheet record rules restricting access to analytic lines, the linking operation raises an AccessError.

With This Commit:
=========================
This commit allows users to complete Manufacturing Orders without encountering access errors when analytic lines are linked to work orders, while preserving the existing analytic distribution and security logic.

For Reference: [Security checks on Many2many](https://github.com/odoo/odoo/pull/217277/changes#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aR1467)

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1HsZjpFSsnsYxZ4xwM8CBDeLhlcIHIP5t/view)

opw-5971807

Forward-Port-Of: odoo/odoo#253496

### Steps to reproduce:

- Impersonate a user with only Inventory user access rights
- Inventory > Operations > Adjustments> Physical Inventory
- Select any quant in the list > Print > Count Sheet
#### > Access Error: You are not allowed to access 'System Parameter' (ir.config_parameter) records.

### Cause of the issue:

The template of the count sheet relies on the `get_param` methods of the `ir.config_parameter` model which requires read access rights on the model:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/addons/stock/report/report_stockinventory.xml#L36-L39 https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/models/ir_config_parameter.py#L59-L69 This access right is limited to the the `base.group_system` (admin) user group:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/security/ir.model.access.csv#L118

opw-5959200

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

Forward-Port-Of: odoo/odoo#253251

When opening invoice HTML preview in the portal, the layout was displayed in LTR
even if the invoice partner language was RTL (e.g. Arabic). This happened when
the portal user language was LTR. PDF structure was correct, but HTML preview had
wrong text flow and alignment.

Root cause was that RTL asset processing depends on `env.lang`, not on `t-lang`
in templates. Since the ORM context language remained the portal user’s language,
CSS was compiled in LTR and hardcoded `direction: ltr;` rules from `report.scss`
were overriding the `<html dir="rtl">`.

To fix this, the portal controller now checks the partner language and, if it is
RTL, updates the request context before rendering. This ensures `_render_qweb_html`
runs with the correct `env.lang`, triggering proper RTL CSS conversion via rtlcss.

Additionally, the subtotal section in the Saudi invoice report could have its
values visually cut due to insufficient width allocated to the tax totals
column. The column width has been slightly increased to ensure totals are
properly displayed.

task-5878719

Forward-Port-Of: odoo/odoo#248822

If an order in overpaid using bank, no move line is created for the change.

Steps to reproduce:
-------------------
* Make an order, add a customer
* During payment, select invoice, pay more than the order amount with bank pm
* Validate
* Close register
* Check customer
> Observation: It says we owe the customer money, although change was given.

Why the fix:
------------
Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it.

Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted.

opw-5149700

Forward-Port-Of: odoo/odoo#254125
Forward-Port-Of: odoo/odoo#247621

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

Forward-Port-Of: odoo/odoo#250998
Forward-Port-Of: odoo/odoo#243812

Under some conditions, it is currently not possible to render the preview of
some layouts

To reproduce the issue:
(Need `l10n_din5008`)
1. Open Settings more times than the number of companies in the database
   - (We actually need to increase the psql sequence of its table...)
2. Configure your document layout
   - Layout: DIN 5008
3. Click "Preview Document"

Error: an error is displayed: "Missing record: Record does not exist or has
been deleted. (Record: res.company(4,), User: 2)"

When clicking on _Preview Document_, we are actually requesting
`/report/pdf/web.preview_externalreport/4`
Where we have both the report name and the `docids` (equal to `4` in the above
example). Since we are calling it from the `res.config.settings`, we provide
the doc IDs with the ID of the `res.config.settings`. However, the report is
based on the `res.company` model:
https://github.com/odoo/odoo/blob/2f64f909d2f20cc8c0a8e95ba7d17348b9b015e6/addons/base_setup/views/res_config_settings_views.xml#L90
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L1006-L1010
As a consequence, the mechanism will try to render the report using the
company with ID equal to the ID of the config settings, which does not make
sense. This is the reason why, at some point, it can lead to a `Missing
Record` error.

That said, the case is working well on previous versions because we were
defining a global `o` variable before rendering the template, cf for
instance on Odoo 19, L896:
https://github.com/odoo/odoo/blob/1c2e17718e6f2a11d93585f0ea3ba3abee5a4a41/addons/web/views/report_templates.xml#L893-L897
Thanks to that variable, DIN 5008 side, we ignore the `docs`, cf here for
instance:
https://github.com/odoo/odoo/blob/dae4fd0000080ba6395b370e25d3f13f1becd74e/addons/l10n_din5008/report/din5008_report.xml#L96

On Odoo 19.1+, this global variable has been removed by [1]. This commit is
actually the result of a script (cf its description). Since the script
hasn't detected the use of `o`, it moved its declaration inside the previous
`t-call`, L829:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L827-L830
This was a mistake since the global variable is sometimes used. Long story
short, the script didn't see the dynamic `t-call` inside the template of
`web.external_layout`:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L758-L761

We have therefore decided to revert this part of the commit and apply the
same logic to its siblings `preview_internalreport` and `preview_layout_report`

[1] https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829

OPW-5951003

Before this commit, when page loading in the webclient while not using Discuss (Discuss app closed, no chat window and bubble), the messaging menu counter could be wrong.

Steps to reproduce:
- Open Discuss app
- Make a new channel
- Post a message in this channel
- Mark conversation as unread
- Open Advanced settings of this channel
- Archive this channel
- Go back to home menu
- (make sure no chat windows and chat bubbles are open)
- Reload the page

=> The counter of messaging menu should be over-estimated by 1. For example if all conversations are read, counter is 1 instead of 0. Opening the messaging menu refreshes the counter to correct value 0.

This happens because when using Discuss, the counter is deduced from all channels that have been fetched and for which current user is a member of these channels. Implicitly, archived channels are filtered out.

However when not using discuss, the channels as member have not been fetched, and instead an estimation of the counter is fetched from server. This counter was computed on channel members that have unread messages. When a channel is archived, that doesn't mean the members are archived too. In the steps listed above, the self member is still active. As a result, the self member of this archived channel had contribution to the counter estimation, hence the value of 1 instead of 0.

This commit fixes the issue by keeping computation on channel members but it checks also that the channel is active, as the resulting counter is based on active channels.

This commit also fixed a similar issue where the counter was wrongly taking muted channels into account on the global counter when not using Discuss. This lead to a similar problem on non-archived but muted channels were they contribute in the estimated counter but not in the actual in-use counter.

Task-6014754

Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres.

Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error.

The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemps to decode it. The `b64decode` function silently discard non-b64 characters and only complain if the final thing lacks the b64 `=` padding (to make the length a multiple of 4).

So when it downloaded something, it downloaded crap.

The thing actually is:

* Binary fields, accept raw bytes, store raw bytes in db.
* Image fields, reject raw bytes, want base64, store base64 in db.

When reading Image fields it is easy: always decode the base64.

For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the beginning.

**Binary-field with non-b64 value** (original fix)

Forward-Port-Of: odoo/odoo#214412
Forward-Port-Of: odoo/odoo#213997

**binary can store raw bytes** (fix of *Binary-field with non-b64 value*)

Forward-Port-Of: odoo/odoo#214915
Forward-Port-Of: odoo/odoo#214758

This PR contains the squashed code of the above two PRs.

Forward-Port-Of: odoo/odoo#253382
Forward-Port-Of: odoo/odoo#249544