**Description of the issue/feature this PR addresses:**

When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database. 

**Current behavior before PR:**

You'll get this error:

```
odoo.service.db.restore_db(dbname, backup, copy, **extra_kwargs)
File "<decorator-gen-27>", line 2, in restore_db
File "/opt/ou/odoo/odoo/service/db.py", line 44, in if_db_mgt_enabled
return method(self, *args, **kwargs)
File "/opt/ou/odoo/odoo/service/db.py", line 360, in restore_db
env['ir.config_parameter'].init(force=True)
File "/opt/ou/odoo/addons/auth_oauth/models/ir_config_parameter.py", line 13, in init
oauth_oe = self.env.ref('auth_oauth.provider_openerp')
File "/opt/ou/odoo/odoo/api.py", line 611, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2059, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/opt/ou/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2052, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: auth_oauth.provider_openerp
Error: External ID not found in the system: auth_oauth.provider_openerp

```

**Desired behavior after PR is merged:**

No error will occur

The afflicted versions are AFAIK, **16.0**, **17.0**, **18.0**, and **19.0**


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

Forward-Port-Of: odoo/odoo#233633

## Dependent PR
https://github.com/odoo/enterprise/pull/98353

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

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

## Dependent PR
https://github.com/odoo/enterprise/pull/98456

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

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

Versions
--------
- 16.0
- 17.0
- 18.0

Steps
-----
1. Have a product that cannot be sold out of stock (but is in stock);
2. have a confirmed sales order for a portal user with said product;
3. as portal user, add the product to your cart;
4. go to My Account / Your Orders;
5. open the confirmed sales order;
6. click Order Again.

Issue
-----
The cart that was opened by the portal user now has OdooBot as Customer.

Cause
-----
The `_document_check_access` method returns a sale order record with `SUPERUSER_ID` in its env[^1]. Meanwhile, the `website.sale_get_order` method checks the current user's partner, and if it's different from the order's partner, it gets reassigned, assuming an address change[^2].

[^1]: https://github.com/odoo/odoo/blob/9eb0b12/addons/portal/controllers/portal.py#L439-L459
[^2]: https://github.com/odoo/odoo/blob/9eb0b12/addons/website_sale/models/website.py#L386-L404

Because `SUPERUSER_ID` is the user in the environment, the order's partner gets changed to OdooBot.

Solution
--------
After `_document_check_access`, add the request's user to the record's env.

opw-5097915

Forward-Port-Of: odoo/odoo#233204

[FIX] website: get scroll from document element for footer animation

__Current behavior before commit:__
Since [this PR], the scrolling is not done on `#wrapwrap` anymore.
Now when an animation is set on an element inside the footer it
will not appear if a slideout effect is set on it.

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Click on a column in the footer.
3. Set an "On Appearance" Animation on it.
4. Set the footer Slideout Effect to "Slide Hover".
5. Add some content on the page so that it's needed to scroll for the
footer to be visible.
6. Save.
7. Scroll to the footer.
=> The column doesn't appear.

[this PR]: https://github.com/odoo/odoo/pull/98429

---

[FIX] website: scroll on new entry in faq horizontal

__Current behavior before commit:__
Since [this PR][1], the scrolling is not done on `#wrapwrap` anymore.
Now when adding a new entry to the snippet faq horizontal, the page
doesn't scroll automatically to the new entry.

This behavior has actually never worked because [the PR that introduced
faq horizontal][2] was merged just after [the PR that moved the
scrolling to the document element][1]. 

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Drag a Text block
3. Choose the FAQ horizontal snippet
4. Click on "Add New"
=> The page doesn't scroll to the new entry.

[1]: https://github.com/odoo/odoo/pull/98429
[2]: https://github.com/odoo/odoo/pull/176438

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment.

Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices).

Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo.

Task-5187602
Original Task-5138081

Backport-[#230809](https://github.com/odoo/odoo/pull/230809)

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

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment.

Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices).

Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo.

Task-5187602
Community PR-[#232841](https://github.com/odoo/odoo/pull/232841)

Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880