Description of the issue/feature this PR addresses:
- Viettel SInvoice will automatically change the signs of the amount values (except for unit price) we sent for credit notes (on accounts with data validation step). So the "right" values will appear in the portal. Currently (before the commit) the values have the wrong sign in the portal (because they are changed but we sent the right ones already).
- We need to retain the original signs of those values when submitting them to SInvoice.

Current behavior before PR:
- All the amount values, including `itemTotalAmountWithoutTax`, `taxAmount`, `itemTotalAmountAfterDiscount` and `itemTotalAmountWithTax` are sent to Viettel SInvoice in negative values for credit note. Viettel SInvoice changes the sign of these values to positive (which is not correct for credit note).

Desired behavior after PR is merged:
- Only the sign of `unitPrice` is changed when we send the credit note to SInvoice.

**Note:**
- The signs will not automatically be changed for accounts with data validation step removed. So this commit will break credit notes for them (since the signs are not automatically adjusted but our values have the wrong signs).

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

Forward-Port-Of: odoo/odoo#201993

**Description**
- The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be created.
However, this wasn't respected for `account.tax.group`. As a result, tax groups could still be created even when `force_create=False`, leading to null values in accounts fields like `tax_payable_account_id` and `tax_receivable_account_id`.

**The issue which prompted this patch:**
- A recent patch in upgrade: odoo/upgrade@d2d16a2321abb525fe3fe2c403f89009f51c1394 This patch was made to update the `reconcile` and `non_trade` flags on standard accounts due to recent changes across localizations. During the upgrade, we overrode the `write` method of `account.tax.group` to conditionally update these flags. However, in a client’s database, `account.tax.group` records were missing for the `l10n_pk` module, while the standard account records were present. When `try_loading` was triggered at the end, it attempted to `create` the missing tax groups. But since the create method is called during creation and does not include the conditional update logic for `reconcile` and `non_trade` the upgrade failed with the same error that the original patch aimed to resolve.

- To avoid such errors and prevent tax groups from being created with null account fields when `force_create=False`, this patch ensures `force_create` is respected for `account.tax.group`.

**Steps to reproduce:**
- Create a `v17` DB and install `l10n_pk`
- Delete the standard tax groups
- Upgrade to `v18`

OPW-4915394

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

Forward-Port-Of: odoo/odoo#219211

Scenario:

- configure turnstile in setting
- install website_mass_mailing
- drop the newsletter widget in any page

Result:

In saas-18.1, we get this traceback error and the turnstile code is not
working:

Uncaught Promise > this._turnstile.addSpinner is not a function

Cause:

- On November 2024, in saas-18.1 and over,
  37fb21911ef33885a3dae309158a359ed1a604e0 adds the addTurnstile method
  but not the addSpinner method
- On January 2025, in saas-18.2 and over,
  421c5e5c4ee6271bb1085b43505cc1c28b2cb574 moved
  addons/website_cf_turnstile/static/src/js/turnstile.js to
  addons/website_cf_turnstile/static/src/interactions/turnstile.js
- On January 2025, in saas-18.2 and over,
  22e777c046521f3f89b62caa5876680beb7f5aba rewrote the Turnstile class
  removing addTurnstile
- On February 2025, in 17.0 up to 18.0,
  7ec74bcc692fc1c0d89fbeb243eef31685996784 adds the addTurnstile and
  addSpinner method
- On April 2025, in 17.0 up to master,
  c48e74f57569a1670fee65d65625488846513d79 uses addTurnstile and
  addSpinner method and the old file link without being adapted in
  saas-18.1 and over

That last commit cause a traceback error in saas-18.1 up to master since
it was forward-ported without adaptation.

Fix: adapt the code for saas-18.1, more adaptation will be needed in
saas-18.2 and over since the turnstile code was rewritten.

Note: the code also modifies website_cf_turnstile to add the possibility
that there is no form around the turnstile elements (which is the case
for the subscribe (.js_subscribe) widget) in which case we fallbacks on
the parent element of the turnstile element.

opw-4933957
opw-4925771

Before this commit, it was possible for the session to assign `0` as a login number. This resulted in order references containing `000` in the middle, leading to various issues. Additionally, other parts of the code that relied on the session's login number were also using an incorrect value.

This problem occurred because the `session.login_number` is not stable; it gets updated whenever the PoS session record itself is modified, potentially overriding a valid login number with `0`. The fix involves changing the code to use `odoo.login_number` instead, which provides a reliable and consistent login number.

To reproduce the issue:
1. Open one PoS session on two different devices.
2. Log in with an employee on the first device.
3. Log in with a different employee on the second device.
4. Create a new order on the first device. You would observe that the login number in the order reference is `0`.

opw-4861456

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

Forward-Port-Of: odoo/odoo#218370

**Current behavior before PR:**

**Issue 1:**

- Have a long text content in editable, making the container scrollable.
- Select first line of the text, in toolbar open color selector.
- Scroll down until the toolbar overflows and becomes hidden.
- Notice that the toolbar disappears when it overflows its container while color picker remains open, floating at the top of container.

**Issue 2:**

- Select a text having gradient text color.
- Open text color selector, switch to custom color picker.
- Notice that hex and rgba fields are empty and user is not able to apply color through it.

In colorpicker.js, the convertCSSColorToRgba method fails when attempting to convert a gradient color to RGBA. As a result,
colorComponents does not receive valid values and colorpicker doesn't work as expected.

**Issue 3:**

After merging commit [1], text color can be applied without removing or affecting the existing gradient color. In result, if gradient is fully selected then applying text color creates a new font tag inside gradient instead of replacing the gradient.

**Desired behavior after PR:**

**Issue 1:**

Now, when the toolbar overflows and gets hidden, the color selector becomes hidden along with toolbar.

**Issue 2:**

Now, if `convertCSSColorToRgba` fails to convert selected color to rgba color then default color `#FF0000`is assigned to color
components. This ensures that the colorpicker functions correctly.

**Issue 3:**

Now, if gradient is fully selected then,
- Applying text color removes existing text gradient.
- Applying background color removes existing background gradient.
- Applying text color doen't remove the existing background gradient.
- Applying background color doesn't remove the existing text gradient.

[1]: https://github.com/odoo/odoo/commit/938995744b15f345958a2d78a6c844dd5bf1ae6c

Enterprise PR: https://github.com/odoo/enterprise/pull/84579

task-4581884

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

Forward-Port-Of: odoo/odoo#202889

**Current behavior:**
Returning an intercompany dropship (product vendor is another
`res.company`) increases the original sale order line's
delivered qty.

**Expected behavior:**
The delivered qty should decrease once the return is completed.

**Steps to reproduce:**
1. Create two companies, enable all the inter-company
synchronization rules

2. Create a product with the dropship route and set the other
company as the vendor

3. Create a sale order for the dropship product, confirm

4. Confirm the corresponding purchase order -> validate the
dropship picking

5. Return the dropship picking

6. See the sale order line's delievered qty is wrong

**Cause of the issue:**
The dropship return move(s) are incorrectly flagged as outgoing.

**Fix:**
Use the `_is_dropshipped_returned()` method to filter these
moves from being considered outgoing.

Also added on to an existing dropshipping test so that there is
now coverage for this use-case when the vendor is not another
company, as this was previously not covered.

opw-4526750

Forward-Port-Of: odoo/odoo#200133

Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session.

Steps to reproduce:
-------------------
* Go in the setting and set up urban piper (no need for credentials) testing with random keys will do
* Go into the payment methods and take one of the urban piper one and assign it to a shop
* Open that shop
* Place an order and use the urban piper payment method
* Validate
* Try closing the session
> Observation: Nothing happen, we're now unable to select the menu. If doing
the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach

Why the fix:
------------
The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method.

Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method.

opw-4874699

Forward-Port-Of: odoo/enterprise#88156