[IMP] html_builder, *: improve the logic of the translation plugin
*: website

The goal of this commit is to improve the logic of the
`TranslationPlugin` plugin. Indeed, we do not want this plugin to handle
the addition of the `o_editable` class to html elements. Instead we let
this task to `SetupEditorPlugin` as usual. The problem is still that
some html elements have translatable attributes and those elements will
not have the `o_editable` class as they do not have the branding (oe
data information). To handle those, a new `o_editable_attribute` system
class is added on them. Thanks to those classes, we know which nodes are
translatable (elements that are editable and elements with the
`o_editable_attribute` class have an attribute that is translatable).
The advantage of handling the translation that way is that we do not add
the `o_editable` class on elements that are not savable. This is better
also in order to not add the `contenteditable` attribute abusively.

Related to task-4367641

**Issue:**

Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself.

**Cause:**

The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access.
https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76

https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117

**Steps to reproduce:**

1. Create a private project (`privacy_visibility == 'followers'`)
2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access
3. Add Marc Demo as a follower of a task in that private project
4. Have another user log time on that task
5. Log in as Marc Demo

Marc cannot see the other user's timesheets, neither on the task form nor in reporting.

opw-5022877

Forward-Port-Of: odoo/odoo#224025

Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > Click on `Edit` > `Drag and drop` form.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - Submit the form, and the error appears in the logs.

`KeyError: 'website_form_signature'`

This error occurs when submitting the "Send Email" form from the
website. When the user chooses the model Outgoing Mails (mail.mail),
the email_to hidden field is not added. This is because email_to is only
added when the recipient email value is changed from the sidebar via
apply [1]. As a result, the email_to hidden field is missing from the form.
And the website_form_signature is added from [2], but due to the
condition at [3], the code at [2] is not executed. When it is accessed
at [4], KeyError is raised.

This commit ensures that when the user selects the action model,
if there is a hidden field email_to, it is added to the form with its
default value.

[1]: https://github.com/odoo/odoo/blob/3b16debc6d6557334082fdf841b20ef0e31fc9d2/addons/website/static/src/builder/plugins/form/form_option_plugin.js#L863

[2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

Related Community PR: https://github.com/odoo/odoo/pull/226598

sentry-6746753251

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

## Issue:
For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule

## Cause:
When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()`
This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end)
These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed:
https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393
We want to use the calendar itself as the calendar resource to get the `work_hours_data`

## Steps to reproduce:
- On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week
- Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6)
- In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values)
- Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off

opw-4881758

Forward-Port-Of: odoo/odoo#225876

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404

The system will crash with error when try to create a analytic item.

**Steps to Produce:-**
1. Install the `Accounting` module with demo data.
2. Go to `Settings > enable Analytic Accounting`.
3. Navigate to `Accounting > Customers > Invoices`.
4. Create a new invoice with total amount = 0 and confirm it.
5. Go to Accounting > Accounting > Transactions > Analytic Items.
6. Create a new Analytic Item and:
   - Set a value in the `Project` field.
   - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save.

**Error:-**
`ZeroDivisionError: float division by zero`

**Cause:-**
- At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error.

**Solution:-**
- Added a condition to compute only when line.balance exists; otherwise,set the value to 100.

[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251

**sentry-6844926153**

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

Forward-Port-Of: odoo/odoo#226148
Forward-Port-Of: odoo/odoo#225068

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

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code to the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this.

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Enterprise PR:
https://github.com/odoo/enterprise/pull/92310
Ticket:
opw-4755357

Forward-Port-Of: odoo/odoo#228108
Forward-Port-Of: odoo/odoo#223517

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
 
    def _can_be_invoiced_alone(self):
        """ Whether a given line is meaningful to invoice alone.

        It is generally meaningless/confusing or even wrong to invoice some specific SOlines
        (delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
        in the SO.
        """
        self.ensure_one()
        return self.product_id.id != self.company_id.sale_discount_product_id.id

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_reward_line

We just have to be careful not to accidentally include delivery fees because of

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_delivery

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357

Forward-Port-Of: odoo/enterprise#95262
Forward-Port-Of: odoo/enterprise#92310

The system will crash with error when try to create a analytic item.

**Steps to Produce:-**
1. Install the `Accounting` module with demo data.
2. Go to `Settings > enable Analytic Accounting`.
3. Navigate to `Accounting > Customers > Invoices`.
4. Create a new invoice with total amount = 0 and confirm it.
5. Go to Accounting > Accounting > Transactions > Analytic Items.
6. Create a new Analytic Item and:
   - Set a value in the `Project` field.
   - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save.

**Error:-**
`ZeroDivisionError: float division by zero`

**Cause:-**
- At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error.

**Solution:-**
- Added a condition to compute only when line.balance exists; otherwise,set the value to 100.

[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251

**sentry-6844926153**

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

Forward-Port-Of: odoo/odoo#226148
Forward-Port-Of: odoo/odoo#225068

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404

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

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

### Steps to reproduce:

- In the settings website > Shop:
    - Disable `Out-of-Stock: Continue Selling`.
    - Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
    - COMP, put 1 unit in stock.
    - KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product

### Cause of the issue:

The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.

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

Forward-Port-Of: odoo/odoo#222945

## Issue: ##
When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain
The keep_done option on the activity_type should be activate to keep old activities
The same issue occured in Activities in the Settings App in Debug Mode, with the Custom Filter on Date Done

## Cause: ##
The domain in the search doesn't include inactive activities
There is a lot of active test in the query

## Fix: ##
When there is `date_done` in the filtered domain in functions `search_fetch()` and `_search()` in `mail_activity_mixin`, we add `active_test=False` to self context
We also do tha same in the `_search()` of `mail_activity` to handle the Settings case

The `search_fetch()` override is needed for App like CRM to make the full query to be executed with the `active_text` context or some informations are lost
If this method doesn't include the context, the lead appeared but the linked Activities aren't fetched completely

## Limitations: ##
Fixing that way can cause to get too many elements, because it will remove all the (active=True) from the all query
This can lead to display inactive or archived leads in CRM, or any archived and inactive data with done activities

## Steps to reproduce: ##
- Open the CRM App
- Go to Configuration > Activity Types
- Select Call
- Toggle Keep Done to enable
- Go in the CRM Pipeline
- Mark any Call activity as Done
- Add a Custom Filter
- Set to Activities > Done Date (keep the default value for today)
- Apply the filter using the Add button
- Before the fix, there is nothing in the filtered pipeline

opw-4744974

**Issue -->**

When a kit/phantom BOM is used, quantity calculation for a product is overridden in `_compute_quantities_dict()`. During this override, BOMs are mapped to either `product.product`s, or when none is specified for a BOM, to a parent `product.template` instead. This causes redundant quantity computations in the case where a BOM is mapped to a `product.template` with many variants which all in turn share one BOM record. This can happen when variants configured to be automatically created for product attributes, for example. At scale the redundant quantity computation becomes costly when repeated for every `product.product` under a single `product.template`, when all of them share the same BOM.

**Solution -->**

As quantities are calculated, we can cache the results of the costly `explode()` method in cases where a product's BOM is associated only with a `product.template` record, and not a `product.product`. Due to how BOM kits are identified and mapped by the domain in `_bom_find()`, any product which has been mapped to a BOM record associated only with its parent `product.template` will share an identical quantity calculation. This eliminates unnecessary recalculations for product variants which share the same BOM record.

**Benchmark -->**
`web_search_read` on `product.template` with several records having ~1,000 `product.product` variants 

| Before Fix | After Fix |
|--------|--------|
| ~24-40s | ~1s |

opw-5051773

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404