If a fiscal position is not related to any tax, when selecting said fiscal position in the pos, the tax from the product is kept. When looking at the paid order in the backend the tax is removed on the order line and the price unit and price with taxes are different (although no tax recorder on the line).

Steps to reproduce:
-------------------
* Create a fiscal position and assign no tax to it
* On the pos config, add this fiscal position and the domestic one to the available fiscal positions
* Open pos session
* Select a product that has a 15% tax
* Change the fiscal position to the one just created
> Observation: We still see that the tax is computed based on the 15%
* Pay the order
* Go see the order in backend
> Observation: price unit: 100, no tax, price with taxes 115

Why the fix:
------------
A recent refactoring happened on the accounting side related to fiscal positions: https://github.com/odoo/odoo/commit/9a97157920c845120861dda49d81d3150e015974

https://github.com/odoo/odoo/blob/e284dfd80bde632e6446fc0b8d3276689da35200/addons/account/models/partner.py#L155-L163

The behavior after this refactoring is the following: When changing fiscal position:
- If the original tax is available for the fiscal position, we use it
- If the original tax is not available but the fiscal position has an available tax that is set to be replacement for the original one, we use the replacement tax
- If the original tax is not available but the fiscal position has an available tax which is NOT a replacement for the original one, we keep the original one
- If the fiscal position has no tax available, we remove the tax

In this fix we apply the same logic inside the pos.

Without the fix we would keep the original tax in the frontend but when passed in the backend the tax with fiscal position was recomputed with the logic from accounting. This explained the difference we observed.

opw-4978056

Forward-Port-Of: odoo/odoo#223164

This PR is made of 3 small commits:

- `[FIX] iot_drivers: fix blank homepage after checkout`
  Due to the `odoo.service` starting before the `rc.local` file has finished updating the Odoo code, you can end up with the old Python code running but the updated JS code loading in the browser. This can lead to a blank screen as a traceback occurs trying to read the MAC address.
  
  We fix this in two ways:
  - A quick fix, which is just making the JS code robust to the missing value to avoid crashing.
  - A proper fix that will require a new image, as it modifies the `odoo.service` file to add `rc-local.service` as a dependency. This means Odoo will not start until `rc.local` has finished executing.


- `[FIX] iot_box_image: set http_interface explicitly`
  From Odoo 19.0, a warning is logged when your `http_interface` config
  setting is not explicitly set. From Odoo 20.0, the default value will
  change from `0.0.0.0` to `127.0.0.1`, which would break the IoT box as
  it would only listen to localhost requests.
  
  To fix this we explicitly set the `http_interface` value to `0.0.0.0` in
  `odoo.conf` so that the IoT box will listen to all requests.


- `[FIX] iot_drivers: use FETCH_HEAD when checking out`
  The current 25.07 IoT box image cannot checkout to 19.0 databases due to
  an issue where the `git reset origin/19.0 --hard` command fails. In the
  other places where we use `git reset` in the IoT box this was fixed by
  using `FETCH_HEAD` (an alias for the last branch that was fetched).
  
  In this commit we apply the same fix to the `upgrade.py` checkout.

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

Forward-Port-Of: odoo/odoo#228231

#### First fix because SelectMenu tests where not passing as I just switched to Firefox:

The groups sorting function in the SelectMenu component (`groupsList.sort`)
was not anti-symmetric, when either group_1 or group_2 was falsy, both
sortFn(group_1, group_2) and sortFn(group_2, group_1) would return 1 where
it should return -1 in one of the cases.

This issue only occured as Firefox seem to have a slightly different sorting
algorithm, which would cause (group_2, group_1) to be called instead of
(group_1, group_2), raking the group_2 before group_1.

Thi commit fixes that by making the function more consistant at handling
falsy values.

This is probably better explained here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#description

#### And the task related fix:

This commit prevents arrowleft and arrowright hotkeys to trigger on other
parts of the UI when navigating a dropdown.

Enterprise: https://github.com/odoo/enterprise/pull/94478
Task: [5048895](https://www.odoo.com/odoo/project.task/5048895)

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

This commit fixes an issue with containers inside iframes that renders the position computation for the popper incorrect.

The problematic situation arises when the popper needs to be positioned near an element inside an iframe and the base container used for the computation is inside the same iframe.
This case happens in the mass_mailing builder when in the mobile preview as the iframe is centered in the viewport and the element that enables the scrolling when overflowed is also inside the iframe.

When in this case, the min and max values for the variant and the direction are computed on a container that is really smaller than the viewport. Meaning that when this happens the popper is positioned on the left of the iframe, which is completely incorrect.

To fix this issue, when we detect that we are indeed in the problematic situation, we add the left and top values of the iframeBox to direction{Min/Max} and variant{Min/Max}. This way the variantOffset is computed based on the position of the container adjusted to the iframe.

before:
<img width="3021" height="1549" alt="image" src="https://github.com/user-attachments/assets/f6c6f3b7-cdd1-4699-97ab-732ef3ec5ff1" />

after:
<img width="3099" height="1502" alt="image" src="https://github.com/user-attachments/assets/00c06936-de4d-48a0-b4f7-19cab3fc821d" />


task-5109138

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

Steps to Reproduce:
------------------
- Open Helpdesk.
- Go to Configuration → Helpdesk Teams.
- Create a new team.
- Enable the Billing feature and assign a project to this team.
- Set the project’s Company field to Null.
- Create an employee for the current user in another company.
- Ensure the user has employees in both companies.
- Create a new ticket (or open an existing one) in the newly created team.
- Try creating a new timesheet → a Validation Error is raised.

Root Cause:
-----------------
When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs.

**This happens because:**

- The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216
).

- Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. 

Issue Faced:
-------------
In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82),
 which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. 

OPW: 5004092

Forward-Port-Of: odoo/enterprise#95226
Forward-Port-Of: odoo/enterprise#92507

## Commit 1:
*: point_of_sale, pos_loyalty, pos_online_payment, pos_sale,
pos_self_order

Before this commit, when syncing records from the server, local
records that were not yet synced (isSynced=false) could be lost
if they were not present in the server response. This could happen
for example when a record was created locally and the server
response did not include it.

This commit fixes this issue by ensuring that local records are
always kept when syncing, even if they are not present in the
server response. This is done by merging the local records with
the server records based on their keys.

---

This commit also replace all checks of the form `typeof id === "number"`
with `isSynced` checks. This is because the `id` of a record can be a
temporary string id before it is synced with the server.


## Commit 2
Before this commit, `table_access_token` was used to retrieve a
customer's orders, making it possible to “share” orders between multiple
devices by scanning the same QR code.

This caused comprehension and synchronization issues. This commit
rectifies this by only taking into account order-related information.
- `write_date`
- `state`
- `access_token`

If a user's device contains this information, they will be able to
retrieve their orders.

These changes are related to commit
https://github.com/odoo/odoo/commit/b903acd72142757bfdfc31c51d78b39c8e8786b9,
which adds the `self_ordering_table_id` field, allowing multiple orders
from Self Order to be linked to the same table at the same time.

Description of the issue/feature this PR addresses:
When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen.
Steps to reproduce:
- Create POS & setup POS online payment (use Demo online payment)
- Open POS, add a product, go to payment screen, select the online payment method
- Let it go to idle state (triggered by useIdleTimer)
- Move the cursor, or at least make it back to active state
- You'll see the screen be redirected to first screen
- Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there

Alternatively take a look at the recording:
https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735

Current behavior before PR:
- Because it bounces to first screen, when attempting payment the pos does not have the order state 

Desired behavior after PR is merged:
- Do not redirect if in payment screen, so that order context won't be lost

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

Forward-Port-Of: odoo/odoo#215651
Forward-Port-Of: odoo/odoo#202220