## Versions
17.0+

## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.

## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*

- Go to the Contacts app:
  - Create a new contact:
    - Name: C1;
    - Contacts & Addresses:
      - Delivery Address (Add 2 new addresses):
        - D1;
        - D2.
  - Click the "Sales" action button:
    - Create a new SO for C1 (pre-filled):
      - Invoice Address: C1, D2;
      - Delivery Address: C1, D2;
      - Add any product with:
        - Quantity: 1;
        - Delivered: 1.
      - Create the invoice and confirm it.
- Go back to Contacts and look for C1:
  - Click the the "Sales" action button:
    - Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
  - Create a new SO and select C1 as customer;
  - Delivery Address retrieves "C1, D2" as it is the preferred address.

## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354

## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534

opw-4916381

Forward-Port-Of: odoo/odoo#225189

**Steps to reproduce:**:
- Install the module "account_reports_cash_basis"
- Create a new account
- Create an invoice with a line in the newly created account
- Create a number of payments on the invoice
- Go to general ledger, and set method to cash basis
- Set limit to a value less than the number of payments
- Open the account on the general ledger, and click on load more

**Issue:**
After clicking on 'Load more', we get a traceback due to duplicate lines

**Cause:**
The same aml can return multiple results when using "account_reports_cash_basis" module. While this has been taken into consideration for each batch of lines loaded into the report (we won't get the same line referenced two times in the same batch, since they are grouped together), if we load a new batch by clicking "Load More", we can potentially get a line that was referenced in the first batch, and we get an error for having two lines in the report referencing the same thing.

**Solution:**
We add a add a GROUPBY statement in the query of _get_aml_values()
This will add up all the cash basis lines in the query itself.

opw-4635115

Forward-Port-Of: odoo/enterprise#93904
Forward-Port-Of: odoo/enterprise#86817

Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
  - 0.049216958195 for day 1
  - 0.053418803419 for day 2
- Create an invoice in USD as follows:
    - line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI

Issue: Payment validation will fail with error

Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862

This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.

opw-4750981

Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768

The way the score bars were animated was a bit confusing. We simplify the
animation by:
- Showing the score accumulated so far without the question
- Animating the score bar towards the accumulated score with the question
- Animating the numerical score on the left towards the accumulated score with the question while fading the numerical score increment on the bar ("+ x p")
- (reordering participants)

We also fix the size of the leaderboard as it was too small to display the score correctly.

How to reproduce
- Create a scored survey with time reward
- Add a question to get the name and toggle the nickname option
- Add a question with an answer that grants n points
- Start a live session
- After a user has completed the question
- Display the leaderboard

The score animation is confusion as it was going through:
- Showing the score accumulated so far without the question
- Animating towards 0: showing a minimal bar due to the minimum size of the score bar
- Animating towards the score question (on top of the minimal bar)
- And finally adding the score accumulated so far without the question

Task-4893763

Forward-Port-Of: odoo/odoo#224996

__Current behavior before commit:__
The background position overlay action allows the user to move the
background image of the editing element. To do that it copies it inside
an overlay which is outside the iframe since the [Website refactoring].
This creates multiple challenges because the overlay needs to perfectly
align with the editing element behind it which is not a trivial task for
several reasons:
- The iframe can have different sizes and positions when toggling the
mobile preview.
- The editing element can be anywhere on the page, and it can move if
the user scrolls.
- Some scroll effects depend on the dimensions of the viewport which is
different in and out of the iframe.

Furthermore the `overlay` plugin currently used is designed for
contextual menus and pop-ups. It forces the overlay content to always be
fully visible in the window and it hides the content if it is bigger.
This makes it unsuitable for the purpose of positioning a background
image.

Here are several bugs that arise from the above:
- The overlay doesn't appear if the editing element is taller than the
window.
- When the overlay is open, it's only possible to scroll while the mouse
is hovering the scrollbar.
- The overlay image doesn't follow the editing element after scrolling.
- The overlay dark mask doesn't cover the whole iframe window.
- The loading spinner and its dark overlay is displayed while the
background position overlay is on.
- If the Scroll Effect is set to "Zoom Out" with maximum intensity, the
overlay is not correctly positioned.
- If the Scroll Effect is set to "Fixed", the overlay **is** correctly
positioned but the background position doesn't align with the one behind
it.
- In the mobile preview the overlay doesn't cover the iframe.
- etc.

__Description of the fix:__
Several things are now done differently to fix these issues:
- The `overlay` service is used instead of the plugin. This way we have
a better control over the positioning of the overlay.
- The overlay positioning is more robust to take into account the mobile
preview iframe position, the page scrolling and a possible browser zoom.
- We stop using an image copy, instead the editing element
`background-position` is directly modified making it a perfect wysiwyg.
To do this, the overlay dark mask is kept but the portion in front of
the editing element is cut-out to highlight it. An invisble dragger
element is there to be able to listen to mouse event for the dragging.
Also, the content of the section is made invisible so that only the
background is shown.

[Website refactoring]: https://github.com/odoo/odoo/pull/187419

Related to task-4367641

Description of the issue this PR addresses:

Issue 1:

Steps to Reproduce:

- Open the website.
- Create a mega menu.
- Enter edit mode.
- Change the mega menu template to “Cards”.
- Click on any option available in the mega menu.
- A link popover will open.
- Click the Edit link button in the popover.
- Click the Apply button to save the link.
- A traceback occurs.

The error occurs because the text-wrap class is applied to the link. When the
hasColor method is triggered, it checks whether a.nav-link has a text color
class. However, TEXT_CLASSES_REGEX incorrectly matches text-wrap as a color
class. As a result, the removeColor method attempts to remove it and triggers
_applyColor to remove the color, but in _applyColor method it does not find any
color to remove on selected text. As a result, the removeColor process enters an
infinite loop, which eventually leads to a traceback.

Solution:

Update TEXT_CLASSES_REGEX so that it only matches valid text color classes and
excludes formatting classes such as text-wrap, text-center, etc.

Issue 2:

This commit ensures that the remove format action is disabled when a button
(.btn element) has custom color or background color applied.

Because buttons include padding, there is no proper way to remove a background
color from a partially selected button, so the action must be ignored in this
case.

task-5062715


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

Forward-Port-Of: odoo/odoo#226369
Forward-Port-Of: odoo/odoo#225477

In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated.

To reproduce:
1- Create a product and add quantity on stock.
2- Uncheck `Conitnue Selling` in `Out-of-Stock`
3- Publish the product on the website
4- Create a gift card
5- Add the product to the cart using portal user
7- Using admin user, set the quantity to less than ordered quantity
8- Using portal user, proceed to payment, and use the gift card. Then checkout.
9- As you see, the order is validated

The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`.
However, when checking out with gift card, this method is not called.
To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0)

opw-4941658


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

Forward-Port-Of: odoo/odoo#226394
Forward-Port-Of: odoo/odoo#222306