This PR addresses the following issues:

**Issue 1: Date Misalignment**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.

**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.

**Expected Behavior:**
The date should align with the blog post content and tags preview.

**Issue 2: Some Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.

**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler 
function, which extracts the URL from the `value` attribute of the `<option>` tag.


**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.

**Issue 3: All Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.

**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.

**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.

task-3937884

Forward-Port-Of: odoo/odoo#230592
Forward-Port-Of: odoo/odoo#225845

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

### Steps to reproduce:
	- Install Time off apps
	- Create two consecutive allocations (e.g. one for 2025 and one for 2026)
	- Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan)
	- Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026)

### Cause:
When we are checking the leave duration after having a public holiday the  will return the attendance without
the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days.

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254

### Fix:
We check for public holidays in the interval we are fetching its attendance to avoid assuming it is an excess days in the leave

opw-5006119

Forward-Port-Of: odoo/odoo#230861
Forward-Port-Of: odoo/odoo#225433

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/odoo#224714
Forward-Port-Of: odoo/odoo#222093

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/enterprise#93442
Forward-Port-Of: odoo/enterprise#91825

Steps to Reproduce:

- Create a list in the editor.
- Apply a text color to an item.
- Change the font type of the text inside the list (e.g., to H1–H6).
- Apply a gradient color to text inside a list item.
- Move the cursor outside the list by pressing Enter twice and start typing in the new container.

Current behavior before PR:

- When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent.
- This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`.

Desired behavior after PR is merged:

- All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element.
- Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice.

task-5039499

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

Forward-Port-Of: odoo/odoo#231308
Forward-Port-Of: odoo/odoo#224262

When coming back to a view using the breadcrumb or with the view switcher, we want to restore the local state of the view as it was when we left it, in particular the scroll position. This is handled by the `useSetupAction` hook, for all views (except for the list as the scrolling container is custom, because of the fixed table header).

However, since [1], it was no longer working in kanban, pivot and list (mobile only). This was due to the fact that those views are now "lazy", i.e. they are rendered directly, without the data, such that the control panel is available asap. As a consequence, when `onMounted` is called (i.e. when the hook attempts to restore the scroll position), there's no scrollable content yet.

This commit fixes the issue by allowing the controllers to restore the scroll position themselves, when their content is ready. In addition, a custom treatment was necessary for the kanban view, in mobile *and* if grouped, as each column has its own vertical scrollbar.

[1] https://github.com/odoo/odoo/pull/205129

task~5086324

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

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

Steps to Reproduce:

- Create a list in the editor.
- Apply a text color to an item.
- Change the font type of the text inside the list (e.g., to H1–H6).
- Apply a gradient color to text inside a list item.
- Move the cursor outside the list by pressing Enter twice and start typing in the new container.

Current behavior before PR:

- When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent.
- This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`.

Desired behavior after PR is merged:

- All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element.
- Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice.

task-5039499

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

Forward-Port-Of: odoo/odoo#224262

*: pos_online_payment_self_order

Before this commit:
===============
- When paying with a QR code, the screen kept showing the QR code even after
the payment was completed.
- Closing the QR popup manually and performing another action resulted in
a `Finalize order` error.
- This happened because the WebSocket handler flow were not updating
the order state properly.

After this commit:
===============
- Ensure the frontend refreshes payment status directly from the server
when the current order is updated.
- Remove unnecessary synchronization calls to prevent stale state.
- The order is now correctly marked as paid, and no finalize error occurs
after closing the QR popup.

Issue:
===============
- The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION`
was fetching the full `pos.order` unnecessarily, because the order state is
already updated by another WebSocket flow.
- `notify_synchronisation` in the self order flow was redundant, as updates
are already handled in the `pos_self_order` module’s `pos.order` file.

Task - 5107009

Forward-Port-Of: odoo/odoo#229847

## Versions
18.0 > 18.3
Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6

## Issue
Importing products (with file fields) from XLSX file triggers an error or does not update when uploading related PDF files.

## Steps to reproduce

https://github.com/user-attachments/assets/7f4c1faf-de8c-4923-a50e-cce77071679d

*Requires Studio app*
- Go to any product's backend page and open Studio customization:
  - Add a "File" field to the product page and link it to a "PDF Viewer" widget;
  - Keep the field name ("New File");
  - Save and close.
- Go to the products' list view in debug mode and select a product (e.g. Acoustic Bloc Screens) to export (via "Actions"):
  - Check the "import-compatible" checkbox;
  - Remove all fields to export;
  - Look for "file" in available fields:
    - Add the "New File (x_studio_binary_field_xxx_xxxxxxxxx)" field;
    - Add its related "Filename for x_studio_binary_field_xxx_xxxxxxxxx (x_studio_binary_field_xxx_xxxxxxxxx_filename)".
  - Export in XLSX format.
- In your computer's file explorer:
  - Download or create a PDF file and copy its name;
  - Open the XLSX file and paste the PDF filename in the 2 empty columns;
  - Save and close the file.
- In the products' main view click "Import records" action button:
  - Click "Upload Data File" and select the XLSX product file.
  - Click "Upload your files" in the "Files to import" section on the left and select the PDF file.
  - Click "Test" or "Import"

## Cause
This upload feature has been described in task 4077715. This specific lines seems to be based on another one a bit further in the code: https://github.com/odoo/odoo/blob/e42f5bee59daa0e270ae4803cc827009974da232/addons/base_import/models/base_import.py#L1289

## Fix
Allow all files base 64 conversion by removing a restriction on images only.

opw-4931579

Forward-Port-Of: odoo/odoo#229648

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment 
→ try to Validate → traceback occurs.

**Issue:**
- A traceback is raised when validating a payment in the POS screen.

`undefined
TypeError: Cannot read properties of undefined (reading 'services')
    at OrderPaymentValidation.beforePostPushOrderResolve`

**Cause:**
-  ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.

https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24

**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
  `this.orm.call` to correctly access the environment and execute data calls
  during payment validation.

> Reference:

https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10

[Related Community PR](https://github.com/odoo/odoo/pull/230069)

**opw - 5137557**

Forward-Port-Of: odoo/enterprise#96284

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

Forward-Port-Of: odoo/enterprise#97003
Forward-Port-Of: odoo/enterprise#89089

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#93647
Forward-Port-Of: odoo/enterprise#89290

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

Forward-Port-Of: odoo/enterprise#96927
Forward-Port-Of: odoo/enterprise#89089

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

Forward-Port-Of: odoo/odoo#231148
Forward-Port-Of: odoo/odoo#202076

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

This PR addresses the following issues:

**Issue 1: Date Misalignment**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.

**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.

**Expected Behavior:**
The date should align with the blog post content and tags preview.

**Issue 2: Some Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.

**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler 
function, which extracts the URL from the `value` attribute of the `<option>` tag.


**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.

**Issue 3: All Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.

**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.

**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.

task-3937884

Forward-Port-Of: odoo/odoo#230592
Forward-Port-Of: odoo/odoo#225845

### Steps to reproduce:
1. Install mrp + purchase
2. Create a new product (A)
   1. Add the Buy route on the product
   2. Add a vendor line on the Purchase tab
   3. Set the quantity on hands to 2000
3. Create a second product (B) with manufacturing route
4. Create a BoM for this product (B)
   1. Add the product (A) as the component with 1 quantity
   2. Create a new operation with a duration of 600:00
5. On the product B's page, click Replenish
   1. Put 10 quantities to replenish
   2. Select the manufacturing route and confirm
6. Go to the BoM and open the BoM overview
7. 'Impossible to plan. Please check the workcenter availabilities.'

https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715


### Before this commit:
When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed.

### After this commit:
If the quantity producible cannot be planned, we retry automatically with the requested quantity.

opw-5031724

Forward-Port-Of: odoo/odoo#229745
Forward-Port-Of: odoo/odoo#227433

**Steps to reproduce:**
- Set your database in a language with a "," as a decimal separator, such as French
- Make a purchase, chose a payment method
- Before paying, click any +10/20/50 button
- The price will be multiplied by 100, then add the desired amount

**Why the fix:**
There were two places where the decimal separator was causing issues.

First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers.

Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number.

We now convert the numbers and the strings using the correct decimal separator.

opw-5126224

Forward-Port-Of: odoo/odoo#229735

**PROBLEM**
When hiding a HtmlField field from a view with pending images in it, there is a traceback.

**STEP TO REPRODUCE**
1. Using studio, create a HtmlField on the view of your choice.
2. Add a checkbox next to it, and link the HtmlField visibility to the button.
3. Add a image to the HtmlField (don't save the record !)
4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image).

**CAUSE**
commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed.

**FIX**
We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)`

opw-5061820

Forward-Port-Of: odoo/odoo#230980
Forward-Port-Of: odoo/odoo#227482

Currently, an error occurs when trying to preview the first page of a PDF 
attachment in Discuss if the PDF is `encrypted` or contains `invalid encoding`.

**Steps to produce:**

- Install the `mail` module.
- Open `Discuss` and attach the encrypted file [1], or the invalid PDF file [2].

(`Note`: Ensure Python version 3.12+ is used.)

**Error:**
`PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm`
`UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte`

**Root cause:**
At [3], `extract_page` directly calls `PdfFileReader`, when it fails to read or 
decrypt the file, Python raises an error.

**Fix:**
This commit prevents errors when a user attaches a PDF file that is unreadable 
or encrypted.

[1]:
https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing

[2]:
https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/11cbbb85b1ee2a620d752b79e86fc51a8e3b33e4/odoo/tools/pdf/__init__.py#L227

sentry-6912765819

Currently, an error occurs when a user selects a mail template after removing their company logo.

**Steps to replicate**
* Install `mass_mailing`
* Companies > YourCompany > Remove company logo
* Email Marketing > New > Start From Scratch

**Error:**
```
`QwebError:
Error while rendering the template:
    KeyError: 'user'
    Template: mass_mailing.s_mail_block_header_social
    Reference: 805
    Path: /t/section/div/div/div[1]/div/a/img
    Element: <img class='o_b64_image_to_save o_editable_media' t-att-src='image_data_uri(company_id.logo if company_id.logo else user.company_id.logo)'...`
```

**Root cause:**
* This error occurs because [1] tries to access `user` after the company logo is removed. As shown in [2], `user` isn’t in values but exists in `env` or as `user_id` ,causing a key error and a qweb exception.
* The template change that introduced this behavior was made after commit [3].

**Solution:**
* Show the logo only if at least one is available, similar to the approach in `18.4` [4]. Without this condition, the template fails when both the selected company and the user's default company are the same and have no logo. This leads to a type error at [5] because accessing the logo through the user returns `False`, and a boolean is not subscriptable.

[1]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/addons/mass_mailing/views/snippets/mass_mailing_headers_snippets.xml#L9-L10 
[2]:
https://drive.google.com/file/d/1XwASk3CGcfkVk7sifuqZE7t_QtCZpuRU/view?usp=sharing 
[3]:
https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6#diff-8f450b28258a6e33b353e751dcb8c71e5ac6c93743efe6eea35a8744d9f7d6b5 
[4]:
https://github.com/odoo/odoo/blob/3a712861be1e3536e593a94e741457840da46907/addons/mass_mailing/views/snippets_themes.xml#L90 
[5]:
https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/odoo/tools/image.py#L562

sentry-6923986938

## Versions
18.0 > 18.3
Solved from 18.4 thanks to e0e46b5c15d53d7aab69a9c4bf39d9b2a412efc6

## Issue
Importing products (with file fields) from XLSX file triggers an error or does not update when uploading related PDF files.

## Steps to reproduce

https://github.com/user-attachments/assets/7f4c1faf-de8c-4923-a50e-cce77071679d

*Requires Studio app*
- Go to any product's backend page and open Studio customization:
  - Add a "File" field to the product page and link it to a "PDF Viewer" widget;
  - Keep the field name ("New File");
  - Save and close.
- Go to the products' list view in debug mode and select a product (e.g. Acoustic Bloc Screens) to export (via "Actions"):
  - Check the "import-compatible" checkbox;
  - Remove all fields to export;
  - Look for "file" in available fields:
    - Add the "New File (x_studio_binary_field_xxx_xxxxxxxxx)" field;
    - Add its related "Filename for x_studio_binary_field_xxx_xxxxxxxxx (x_studio_binary_field_xxx_xxxxxxxxx_filename)".
  - Export in XLSX format.
- In your computer's file explorer:
  - Download or create a PDF file and copy its name;
  - Open the XLSX file and paste the PDF filename in the 2 empty columns;
  - Save and close the file.
- In the products' main view click "Import records" action button:
  - Click "Upload Data File" and select the XLSX product file.
  - Click "Upload your files" in the "Files to import" section on the left and select the PDF file.
  - Click "Test" or "Import"

## Cause
This upload feature has been described in task 4077715. This specific lines seems to be based on another one a bit further in the code: https://github.com/odoo/odoo/blob/e42f5bee59daa0e270ae4803cc827009974da232/addons/base_import/models/base_import.py#L1289

## Fix
Allow all files base 64 conversion by removing a restriction on images only.

opw-4931579

This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 

1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere.

2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. 

As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed)

task-4650439

Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise)
references the field `payment_method_code` from `account.payment.register`.
This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`.
This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail.

To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module.
I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)).

Here’s a screenshot of the error (runbot)
<img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" />

Here’s the screenshot after changing to this commit
<img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" />

[OPW](https://www.odoo.com/es_ES/my/tasks/5139827)
[PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)

@moduon MT-12067

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

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Forward-Port-Of: odoo/enterprise#95989

In certain conditions some draft orders could be saved on the server but you wouldn't be able to delete them. This prevented you to close the PoS.

Steps to reproduce:
-------------------
* Use a PoS that is NOT a restaurant
* Make sure the PoS has a preparation display
* Open the PoS
* Leave the first order empty and create a new one
* In the second order add any items
* Go back to the first order, add items and validate it
* Delete the second order from the order list
* Now try to close the session
> Observation: You will get an error saying you still have draft order

Why the fix:
------------
When you have a preparation display linked to the PoS, when you pay an order it will synchronize all the order of the PoS. So the draft order will be saved on the server. But when deleting it, it is not deleted from the server because the function `isOpenOrderShareable` would return false. To fix this we make sure to delete the order from the server if the order has a server_id.

opw-4946204

17.0+

In the Barcode app, users can fully validate a Manufacturing
Order (MO) without scanning or adding quantities, even when the
`Allow full order validation` option is disabled in the
Manufacturing operation type. This behavior is inconsistent with
other operations like pickings, where the setting is correctly
enforced.

- In Inventory / Configuration / Warehouse Management / Operations Types:
  - Open `Manufacturing` operation type:
    - Under `Barcode App` tab, uncheck `Allow full order validation`;
- In Manufacturing / Operations / Manufacturing Orders:
  - Create a new MO wit any BoM and confirm it;
  - Make it available for production (add stock on products if needed);
- In Barcode App:
  - Move to `Manufacturing` and find your MO then click on it;
  - Without adding quantities, click on `Produce`:
    - The final product is considered as created.

**CAUSE**
When a picking type is scanned from the barcode main menu, the
picking type's config is not loaded. This results in (among
other options) the full validation option is not properly set
once inside the barcode component.

**FIX**
Use the picking type record of the scanned mrp operation to get
the config and any required default records in the barcode cache
upon the intial load.

opw-4461309