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

Since commit 42be7cebc84ac4af36104b6d2eba9d3e5d115005, filtering mail templates on their category triggers a search on `ir.model.data` to avoid a memory error on a database having a lot of mail templates.

However, regular users don't have a read access to this model, so when a user tries to filter on the template category, they get an `AccessError`.

With this commit, we add a `sudo()` on the search on `ir.model.data`, so that this error doesn't occur any more.

To reproduce the issue on a runbot, follow these steps:
- connect as *demo* on a 18.0 database
- open a *Sale Order* or a *Purchase Order*, and click on *Send by email*
- in the modal dialog, click on the vertical three dots to select a template
- if *Search More...* is not available, save the template several times with different new names until *Search More...* appears on the list
- click on *Search More...*
- in the *Search...* field, click on one of the *Base Templates* or *Custom Templates* filters
- boom! `Access Error, You are not allowed to access 'Model Data' (ir.model.data) records.`

**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

When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system parameter.

This was due to the `_send_invoice` method in `payment_transaction` calling `_generate_and_send_invoices` without passing the configured template.

This commit modifies the `_send_invoice` method to retrieve the 'sale.default_invoice_email_template' system parameter. If found and valid, the corresponding mail template record is passed in the context to `_generate_and_send_invoices`, ensuring the correct email template is used for auto-sent invoices after online payments.

Added unit tests for the different scenarios.

## Reproduction Steps:
1.  **Enable Auto-invoicing:** Go to Sales > Configuration > Settings. Under "Invoicing," enable "Automatic Invoicing." Set a specific email template in "Invoice Email Template" (e.g., "Customer Invoice"). Save.
2.  **Configure Payment Acquirer:** Go to Invoicing > Configuration > Payment Acquirers. Activate and configure any payment acquirer (e.g., Bank Transfer). Ensure it's published.
3.  **Create Sales Order:** Go to Sales > Orders > Quotations. Create a new SO, add a product, and Confirm it.
4.  **Simulate Online Payment:** As a customer, navigate to the SO's public portal link. Click "Pay Now," select the configured acquirer, and complete payment.
5.  **Observe the Issue:** Check the communication history on the generated invoice. The email will have been sent using Odoo's default invoice template, ignoring the configured setting.

opw-4865475

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

**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

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