Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2).

### Setup

* install `l10n_es_reports`
* switch to a Spanish company

### Steps to reproduce issue 1

* with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report)
* open the model 347 tax report

We would expect the new partner to be listed in the report, but they aren't.

### Steps to reproduce issue 2

* with a new partner, create and confirm an invoice for more than €3005.06
* if you open the model 347 report, you will see the new partner listed there
* go back to that invoice and register a payment for it.
* open the model 347 report again

We expect the new partner to still be listed, but they are not.

### Cause

issue 1: receipts are missing in the corresponding domains.
issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation.

opw-3816370

Forward-Port-Of: odoo/enterprise#60353
Forward-Port-Of: odoo/enterprise#59343

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Generate CFDI via "Send & Print" button

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

**Issue:**
A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called.

**Cause:**
The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one.

**Solution:**
"_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values.
These data were used to populate the external trade data of the CFDI.
"_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI.
It is used with a copy of the cfdi values to compute the values for the delivery address.

opw-3849153

Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user.

This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user.

Steps to reproduce the issue
============================
1. Create a new employee
2. Link that employee to a new user
3. Remove the user to the employee (unset Linked user field)
4. Log in as that new user
5. Go to timesheets app

Current Behavior
================
A traceback is occured because the rpc called returned an empty list instead of a list containing at least one object to get the billable target for the current user.

Expected Behavior
=================
The grid view of Timesheets app should be loaded as expected and the leaderboard should not be displayed since no data is found to get the billable target for that current user.

opw-3862635
opw-3866805
opw-3864353

# Introduction:

`JSON.stringify` was used to serialize the properties for the `/article`
command instead of the classical `encodeDataBehaviorProps` which also uses
`encodeURIComponent` above the `JSON.stringify`, to avoid having some special
characters as an attribute value.

# The issue:

`html_field.js:getEditingValue` is recovering the current value in the DOM using
`innerHTML` which converts some characters from tag attributes to HTML entities,
i.e.: `"` for `"`.

`mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a
string with HTML entities, and is returning a string without HTML entities.

The database value (without HTML entities) is later given to the `html_field` as
a prop and is used as a comparison reference (`updateValue`) with the current
value in edition (that is still being converted to have HTML entities). Since
both values are different, the field is considered as dirty and in need of being
saved, which will trigger a write, even though the normalized value is the
same.

# Fix:

Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor
attribute (like for any other Behavior) will prevent the use of characters that
are being converted to HTML entities.

In order to update existing `/article` blocks, the behavior will overwrite its
`data-behavior-props` attribute when it is mounted in edit mode.

task-3853291

Forward-Port-Of: odoo/enterprise#60775
Forward-Port-Of: odoo/enterprise#60177

**Steps to reproduce:**
	1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
	 and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
	2- Go to Time off module and select a date in the second allocation's period
	3- Click on the Time off type dropdown menu
	4- You will see the first allocation displayed not the second one

**Current behavior before PR:**
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381

**Desired behavior after PR is merged:**
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.

opw-3797696

## Problem
Before this commit, adding a dropdown to a kanban view via `web_studio` didn't work.
Steps:
- Install `web_studio`
- Install a module containing no dropdown on the kanban view (e.g. `sale_management`)
- Modify the kanban view of this module on studio
- Click on the 3 small dots on the kanban-card and add the dropdown
- Confirm
- Exit studio
- Try changing the color of one of the kanban-cards via the newly added dropdown
- Traceback

## Explanation
Here's how adding a dropdown to the kanban view normally works in studio:
Python:
- Create a new `x_color` field in the model
- Add this new field to the view in question
- Add a dropdown containing `.oe_kanban_colorpicker` and a `data-field` containing `x_color`.
- Change the attributes of the first element in the kanban-card to add a color="x_color".

Javascript:
If the color is changed, this code is triggered

https://github.com/odoo/odoo/blob/0fcb34dd3ba3bbd7f422c627e27c96089b29b044/addons/web/static/src/views/kanban/kanban_record.js#L302-L306

which dynamically updates the `colorpicker` field with the new value via the value of arch `colorField`.
Except that in our case `colorField` is `color` and not `x_color`.

Then, as the `web_studio` python code adds a `color="x_color"` attribute, instead of `colorField` it's `cardColorField`.

https://github.com/odoo/odoo/blob/3c356a40f7d6da5aff8a8e7f6ebb9ea8cc9b3861/addons/web/static/src/views/kanban/kanban_record.js#L266-L269

This code is obsolete because it adds `oe_kanban_color_X` to `o_kanban_record ` instead of adding it to its first child `oe_kanban_card`.

So we have several problems:
- Use of `cardColorField` instead of `colorField`.
- Color style added to wrong HTML element
- KanbanArchParser searches for the colorpicker's `data-field` only in `kanban-box`, whereas it is often (including in studio) put in `kanban-menu`.

## Commits
### Commit 1: [[FIX] web: Use kanban-menu template in arch kanban_arch_parser](https://github.com/odoo/odoo/pull/160483/commits/bb0cf9ef09ac29233b99b64077c9b31bcd4a04a0)

This commit modifies the way kanban_arch_parser retrieves `colorField`.

Previously, the parser tried to retrieve only `colorField`
(the `data-field` attribute of `.oe_kanban_colorpicker`) from `kanban-box`.
Except that in most cases `.oe_kanban_colorpicker` is defined in
`kanban-menu` and not `kanban-box`.

for example:

https://github.com/odoo/odoo/blob/31107fb4cc9cf5dc2da21cbfef58dae722c73922/addons/crm/views/crm_lead_views.xml#L554-L559
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project/views/project_task_views.xml#L544-L550
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project_todo/views/project_task_views.xml#L28-L31
etc.

As a result, this code was always ignored and we always fallback on `||"color"`.
```js
 const colorField = (colorEl && colorEl.getAttribute("data-field")) || "color";
```

Now `KanbanArchParser` checks both `kanban-box` and `kanban-menu` and
finally fallbacks to `color`.


### Commit 2: [Put kanban color classes in the right place](https://github.com/odoo/odoo/pull/160483/commits/73844cd42a389020bd4a7bd47ed48c4652fa7e4d)

After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.

The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).


A commit has also been made in the enterprise section to remove unnecessary code from the `web_studio` controller, which before this pull request was used to add a color="x_color" attribute that we no longer use.

https://github.com/odoo/enterprise/pull/60072


opw-3823860

Forward-Port-Of: odoo/odoo#160483

**[FIX] payment(_stripe): adapt validation currency to payment method**

When payment details are tokenized through a validation operation, the currency to use was usually (except overrides) chosen as that of the payment provider's company. This sometimes caused compatibility issues if the selected payment method did not support the company's main currency. For example, the SEPA Direct Debit payment method only supports the EUR currency.

This commit allows passing a payment method when getting the validation currency so that only supported currencies can be returned.

---

**[FIX] payment_(buckaroo, stripe): updated the PM based on provider codes**

When processing a transaction, the payment method was searched based on the received code (e.g., 'sepa_debit') that was compared with the `payment` module's generic codes (e.g., 'sepa_direct_debit'). This commit ensures that we now compare with provider-specific codes for Buckaroo and Stripe.

In practice, this mistake had little to no impact as most provider codes match the generic ones, and we fall back onto the payment method selected by the user if we can not find a more accurate one based on the code.

Versions
--------
- saas-16.3+

Steps
-----
1. Set timezone of User and browser to America/Los_Angeles;
2. go to Time Off;
3. click on calendar to create a new leave.

Issue
-----
Date defaults to the day before the selected date.

Cause
-----
Commit 0a0c6917b5e21e829e14ad271de6e2117e4a7126 added a TZ conversion in JS to add default start & end times for leaves. The issue is that it assumes the context values are always datetime strings, therefore always using `deserializeDateTime`, which does a timezone conversion from UTC to local time, which is incorrect when the context values are date strings.

For a UTC-7 zone like America/Los_Angeles, it deserializes a date string like `'2024-01-01'` to `'2023-12-12 17:00:00'` (7 hours before midnight). It then sets the start hour to 7, and serializes it back to UTC, adding 7 hours, resulting in `'2023-12-12 14:00:00'`. Instead, Jan 1, 7 AM in America/Los_Angeles should convert to `'2024-01-01 14:00:00'` UTC.

Solution
--------
Use `deserializeDate` instead of `deserializeDateTime` when the `default_date_{from,to}` in the context is a date rather than a datetime. This way, `'2024-01-01'` gets deserialized into `'2024-01-01 00:00:00'` local time. When this value gets used for the default hours, `'2024-01-01 07:00:00'` local time will get serialized to `'2024-01-01 14:00:00'` UTC as expected.

opw-3757712

Forward-Port-Of: odoo/odoo#161838

Given the changes in [1] and subsequently in [2], which in some way
counteract the RTL adjustment, it is necessary to eliminate the rtlcss
directive from the carousel CSS to ensure the correct behavior.

Steps to reproduce:

- Enter in edit mode.
- Drag and drop an image gallery and a carousel snippet.
- Navigate to the theme tab.
- Add an RTL language (Arabic, for instance).

Bug :

- The images slide in incorrectly during transitions. In RTL mode, when
  clicking on the left chevron, the next image should appear, not the
  previous one.

If we have three slides numbered 1, 2, and 3
- In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then
  back to 1.
- In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and
  then back to 1.

The directional Font Awesome icons (classes starting with `fa-` and
ending with `-right` or `-left`) are not flipped in the mobile viewport
as a result of [3]. Necessary adjustments have been implemented
to prevent this behavior.

Upon investigation, a more significant bug was discovered regarding the
'oi-...-[right/left]' icons. These icons were not flipped appropriately
in the frontend when the webpage context was set to an RTL language. A
pull request has been created and merged to address this issue [4].

More info on rtlcss [here]

[1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5
[4]: https://github.com/odoo/odoo/pull/157214
[here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip

opw-3747848

Forward-Port-Of: odoo/odoo#161770
Forward-Port-Of: odoo/odoo#154734

Start a SMTPS server with client certificate authentication. In Odoo configure an outgoing mail server with encryption="ssl/tls" and authentication="certicifate". Load a valid client certificate and key to use with the SMTPS server then test the connection.

The connection fails because the client certificate wasn't sent during the TLS handshake.

If you're having trouble running a SMTPS server, I made a script here: https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac It uses aiosmtpd, a light pure python smtp server, install it with pip. You'll need to copy your snakeoil ssl key + cert inside your /tmp directory and to expose them to your current user:

    # public cert
    cp /etc/ssl/certs/ssl-cert-snakeoil.pem /tmp

    # private key
    sudo cp /etc/ssl/private/ssl-cert-snakeoil.key /tmp
    sudo chmod 400 /tmp/ssl-cert-snakeoil.key
    sudo chown $USER /tmp/ssl-cert-snakeoil.key

[task-3703209](https://www.odoo.com/web#id=3703209&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#162259

As of April 1, 2024, the migration period set by the Peppol Authority of Finland for the requirement specified in the Peppol Authority Specific Requirements document has ended. According to this requirement, Finnish end users’ Peppol addresses (participant identifiers) must adhere to the ISO 6523 code list 0216 OVT-format. Other address types are not allowed for Finnish end users.

See also:
[Finland Peppol Authority requirements](https://peppol.org/wp-content/uploads/2023/08/Finland-Peppol-Authority-Specific-Requirements.pdf)
[Finland Peppol Authority website](https://www.valtiokonttori.fi/en/service/the-state-treasury-is-the-finnish-peppol-authority/#for-service-providers_authority-specific-requirements-in-finland)

It turned out that we have a few others that are no longer used on Peppol.
We will remove those in master as well.
See:
[Peppol codelists](https://docs.peppol.eu/edelivery/codelists/)

no task, reported by the Finnish Peppol Authoirty Team



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

Forward-Port-Of: odoo/odoo#162188
Forward-Port-Of: odoo/odoo#161898

No rounding in the query used to map sale.order.line to
the hr.expense, models leads to some records not being able
to be linked together, because of floating point errors.

Adding a rounding to the key price_unit,
and not filtering on price_unit. Then, using the rounded string versions
of the price_unit in the comparisons adds a more reliable approach.

task-3705179

Step to reproduce:
- Change the **[TRANS & ACC] ...**  product, setting a cusomer AND a vendor tax of 15%
- Create an expense using that product with a total amount of 316
- Report -> post the expense (report)
- Reset to draft the expense report
- **The SOL quantities aren't reset to 0**

Reason:
A price_unit used as a float, even rounded can have a floating point error that wasn't taken into consideration
so 14.00001 != 14.00 in the WHERE clause of the query would search for. Hence not matching properly



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

Forward-Port-Of: odoo/odoo#162175
Forward-Port-Of: odoo/odoo#154002