Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user.

Steps to reproduce:
-------------------
* Go to the **Time Off** app
* Select **Configuration** > **Time Off Type**
* Create a new time off type
  * Approval: By Employee's Approver and Time Off Oficcer
  * Requires allocation: Yes
  * Employee Requests: Extra Days Requests Allowed
  * Approval: Approved by Time Off Officer
  * Notified Time off officer: Mitchell Admin
* Select **Management** > **Allocations**
* Create a new allocation
  * Employees: Mitchell Admin
  * Time off time: The one created previously
* Validate the allocation
* Select **Management** > **Time Off**
* create a new time off
  * Employees: Any Employee A & Employee B
  * Time off type:
  > Observation: The new time off time is present in the name search while both employees don't have any allocation for it.

Why the fix:
------------
The name search searches for time off type with
```
['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]]
```
By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok

`has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138

`max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192

Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388

When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin.

The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form.

opw-3816442

Steps to reproduce:
-------------------
- create a product tag (eCommerce / Product Tags);
- go to a product page and open editor;
- edit the page adding a "Products" block;
- add the created product tag;
- remove it and save;

Issue:
------
No products are displayed, whereas without tags,
a default product set should be displayed.

Cause:
------
At first, when we don't have a tag, the domain determined for the search is `[]`, which returns a list of products.

When we add the tag, a domain will be built with the products linked to this tag: `['all_product_tag_ids, 'in', []]` (in the case of the use case above, there will be none). The attribute `data-product-tag-ids="[]"` is added to the dynamic snippet section.

Then, when we remove it, we will get the same domain: because the string `"[]"` is valid for the condition that checks whether `productTagIds` exists.

As a result, it will no longer be possible to obtain the default set for this block.

Solution:
---------
Try to reduce the domain to a list in all cases and compare its length. If it is empty, the domain must be an empty domain.

opw-3859482

Forward-Port-Of: odoo/odoo#161818

Description of the issue/feature this PR addresses:

Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access security errors without Administration/Settings.

Current behavior before PR:

When creating the first invoice, TicketBAI chain sequence does not exists therefore it is created, if user does not belong to Administration/Settings group, an access error is raised and invoice is not posted. In the same time, a write operation is done in the company to set the value of the sequence on l10n_es_tbai_chain_sequence_id field, and writing in a company only is allowed for users that belongs to Administration/Settings.

Desired behavior after PR is merged:

We make a sudo in self (res.company) with a user with account permission but not Administration/Settings, no errors are raised, invoice is posted and TicketBAI XML file is created and posted to the agency.


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

Forward-Port-Of: odoo/odoo#162433

Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount).

Step to produce:

- Install a 'website_sale_loyalty' module.
- Navigate to the website / eCommerce / Loyalty / Discount & Loyalty to create a record.
- Set the Loyalty Program name and Program Type as 'Loyalty Cards'.(Ensure it's available on sale and the website.)
-  And add 'Rewards' and set a Reward Type as 'Discount' which is applied to on Cheapest Product.
 - Go to the website shop add any product on a card, Open a cart increase the quantity of the product, and claim the discount reward.
- Again go to Loyalty Program and open Loyalty Card, Open a record and add a Balance(greater than 200 as default reward points are 200) and copy 'Code'.
- Again go to the website shop and apply this code to claim a discount after a claim discount.
- Now remove all product quantity from a cart.

See Traceback:

```
AttributeError: 'bool' object has no attribute 'price_unit'
  File "odoo/http.py", line 2252, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1828, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1848, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1826, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1833, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2058, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/website_sale_loyalty/controllers/main.py", line 126, in cart_update_json
    return super().cart_update_json(*args, set_qty=set_qty, **kwargs)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/website_sale/controllers/main.py", line 817, in cart_update_json
    values = order._cart_update(
  File "addons/website_sale_loyalty/models/sale_order.py", line 174, in _cart_update
    self._update_programs_and_rewards()
  File "addons/website_sale_loyalty/models/sale_order.py", line 60, in _update_programs_and_rewards
    return super()._update_programs_and_rewards()
  File "addons/sale_loyalty/models/sale_order.py", line 802, in _update_programs_and_rewards
    values_list = self._get_reward_line_values(reward, coupon, product=reward_key[3])
  File "addons/sale_loyalty_delivery/models/sale_order.py", line 64, in _get_reward_line_values
    return super()._get_reward_line_values(reward, coupon, **kwargs)
  File "addons/sale_loyalty/models/sale_order.py", line 573, in _get_reward_line_values
    return self._get_reward_values_discount(reward, coupon, **kwargs)
  File "addons/sale_loyalty/models/sale_order.py", line 321, in _get_reward_values_discount
    discountable, discountable_per_tax = self._discountable_cheapest(reward)
  File "addons/sale_loyalty/models/sale_order.py", line 211, in _discountable_cheapest
    discountable = cheapest_line.price_unit * (1 - (cheapest_line.discount or 0) / 100)

```

The issue occurs when attempting to remove all product quantities from a cart. At this point [1], a bool value  'False' is returned, and the system attempts to get a value of 'price_unit' from it [2].

link [1]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L187-L195

link [2]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L205

This commit resolves the issue, If the _cheapest_line() method returns False then also returns False from _discountable_cheapest(), To raise an error at [3].

link [3]:  https://github.com/odoo/odoo/blob/cbc40eccf576c499709f7825edad9a3b3ce7a22d/addons/sale_loyalty/models/sale_order.py#L317-L333

sentry-5119007021

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

Forward-Port-Of: odoo/odoo#163055

[FIX] mrp_subcontracting: fix origin moves on backorder

This commit reverts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and 7a78839ca6cf45ddec7adb59051da132e0ebceb4

The commits above try to split the origin moves during a split (backorder).
However, if you create a subcontracting backorder by manipulating the stock.move.line qty_done, then it creates an issue were the production_id is not linked to the backorder.

HOW TO REPRODUCE:
- Create product FNS (storable)
- Create subcontracted BoM for FNS
- On Operation type 'Receipt', set Show Detailed Operations = True and Pre-fill Detailed Operations = True
- Create PO for 10 units of FNS -> Confirm
- Go to Receipt > Detailed operation > Set quantity = 1 > Validate (with backorder)
- Repeat step above on the created backorder

OR

- Create storable product FNS tracked by serial number
- Create subcontracting BoM, with strict consumption
- Create PO for 10 units of FNS -> Confirm
- Open detailed operation, add 2 lines with SN, confirm, Validate & create backorder
- Redo the same step with backorder receipt

---

https://github.com/odoo/odoo/assets/29302288/4c9de2b7-2a65-4e18-8a4b-c9faadf68d17

---

OPW-3838250
OPW-3812937

Forward-Port-Of: odoo/odoo#161323

Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue:

```py
move = self.init_invoice(
    move_type='in_invoice',
    partner=self.partner_a,
    amounts=[1000.0],
)

move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()

for line in move.line_ids:
    self.assertEqual(line.date, move.date) # will fail
```

### Cause

The `date` of a move is a computed field dependent on the move's `invoice_date`. The `date` of a move line is a related field, pointing to its parent move's `date` (note: related fields are computed fields). During a flush, the system recomputes all fields that need to be. Here, the system first processes 'account.move.date' and calls its computation (`_compute_date`). However, the `_affect_tax_report()` call within `_compute_date` triggers a recalculation of `account.move.line.date`, but as this happens within `_compute_date`, the invoice lines' `date` is recalculated using the old invoice `date`.

### Fix

Force a recalculation of the invoice lines' dates whenever the invoice's date is changed.

opw-3759472
opw-3875405
opw-3872006
opw-3884013

Forward-Port-Of: odoo/odoo#163491
Forward-Port-Of: odoo/odoo#162956

Steps to reproduce the problem:

1. Add a many2one field to lines of a model, example: sale.order.line
2. Add it to form view of the lines with a domain
3. Click on Search more... option
4. You will see results out of the scope of the domain

In the getDomain is passed an object that has only the key fieldName but for knew in what view is the field placed it needs to be provided the key viewType, this both are placed on the class object this.recordParams builded at:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L129

If this key is not provided the viewType is beeing filled with the element viewType, this element is the record opened placed in the parent view, so by default if will be kanban or list. So if the domain is filled just in the form view, the search panel will get the domain [], so all the entries will be displayed and they will be able to be selected.

If we see the next line:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L431 We will see that getContext is getting this.recordParams as argument, for the same reason that the domain should have it.

With this changes the getDomain method is getting the viewType to take the domain instead of the viewType of the lines displayed on the parent view.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#163297
Forward-Port-Of: odoo/odoo#162983

Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse method.

With this commit, the behavior is adjusted so that phone numbers are only written in the inverse method on the partner if there is a number present on the applicant. This prevents the inadvertent removal of phone numbers on the
 partner when creating new applicants for existing partners.

Additionally, this commit ensures that phone numbers from the partner are computed on the applicant as if they were related non-stored fields. This avoids the need for manual re-encoding of numbers later and prevents the inverse method from being forced again.

Furthermore, to optimize the process, email changes are now only processed using the inverse method if the normalized version of the email is different. This prevents unnecessary method calls on the highly used res.partner model when the email is updated, particularly for cases where the normalized version remains the same.

Previously, changing the partner's email from `jke@odoo.com` to `"JKE" jke@odoo.com` would resend all waiting sign requests because the normalized versions of the email were distinct. While ideally, this check could be performed within the sign request code itself, this optimization now helps prevent unnecessary overrides across all modules simultaneously.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported.

Original commit message:
Since [1] when uploading images from URL the data is downloaded and then hosted on the Odoo instance. As stated in its task (task-3129360) it should not have been applied to document URLs.
Because of this, when hitting a CORS issue to fetch binary data, we try to fetch the data through an `<img>` element by setting its `src` field
- which also fails when the data is not an image.

This commit makes the changes of [1] specific to image uploads and restores the previous behavior for other files.

Steps to reproduce:
- Drop a "Text - Image" snippet.
- Double-click on the image.
- Go to the Documents tab.
- Click on "Add URL".
- Enter an example PDF URL. E.g.: https://www.africau.edu/images/default/sample.pdf
- Click on "Add URL".

=> Fails because of a CORS issue.

[the original commit]: https://github.com/odoo/odoo/commit/238566d1dea29fd11353e7e6529d29843c4f658b
[1]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a

task-3493618