### [FIX] l10n_co_edi: add a test for the vendor document
Previously there was no test for the vendor document.
This commit adds a (simple) test.c

In the next commit of the same PR the code for the vendor document had to
be adapted while keeping the result the same.
This test helps in making sure nothing went wrong.
The reason was that the electronic invoice and vendor document share
some common code / logic but the shared parts had to be changed for an
update to the electronic invoice spec (Anexo 1.9).
(See the next commit for details)

### [FIX] l10n_co_edi: update for anexo 1.9
The spec for electronic invoices in Colombia was updated and is now
known as Anexo 1.9.
This commit updates the electronic invoice to meet the new  spec

A bit part of the new spec is the conversion of many fields from document to company currency / COP.

There is also a vendor document. But it follows a different spec.
Thus some shared logic / section with the electronic invoice was updated
so that the vendor document remains unchanged.

The following sections were removed since they are obsolete and also (basically) dead code:
  * OVT section: dead code
  * FE1 section: content is dead code

Previously when creating a credit note from an invoice with the
reversal wizard (account.move.reversal) there was the following bug.
The Credit Note Concept (l10n_co_edi_description_code_credit on account.move) was set
after posting. This was corrected in this commit (since a validation on post
was added to check that the concept is there).

### task
task-3639271

### related PRs
forward-port of 
https://github.com/odoo/enterprise/pull/54086 (15.0)
https://github.com/odoo/enterprise/pull/55268 (16.0)
https://github.com/odoo/enterprise/pull/55274 (saas-16.3)

### Issue:

Tours from `tour_shopfloor.js` fail in "No demo" databases.

### Explanation:

This is due to the setting `group_mrp_routings` being disabled.
When it is enabled, a pop-up appears when entering Shop Floor and the tours take it into account since the setting is enabled with Demo Data.
When it is disabled, the pop-up does not appear, and the tests fail at the first step because of it.
https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L107 https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L114-L119

### Fix:

Due to both tests failing for the same reason, the setting will automatically be enabled in `setUpClass`.
`test_shop_floor` also needs an employee named 'Marc Demo', adding the creation of the employee for "No demo" databases. https://github.com/odoo/enterprise/blob/74e0f4fec69d6512e213312bf42f3d743f7a27b3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L28-L31

error-60565
error-58036

#### [FIX] core: add invalidation of Environment's _cache_key.

Changing the environment in method create() to force bin_size=False
looks harmless, but it actually breaks many tests, in particular in
module account.  The reason is that company_dependent fields are read at
the wrong place in the cache.  And this is because `env._cache_key` can
be polluted with old data.

Make sure that `_cache_key` is cleared when resetting all the lazy
properties on the environment.  Only the change in res_user.py makes it
work, but let's not tempt the devil.

Side note: I hate caches.

#### [FIX] test_new_api: test's change that already works

Add some test cases, and also remove useless flush/invalidate.

#### [FIX] core: fix create/write on binary fields
When invoking create() or write() with a binary field, the cache of the
field was incorrect if bin_size=True was in context.  Force context with
bin_size=False when putting a binary value in cache.  It is particularly
important to have coherent values in the cache for `web_save`.

Also, because an environment with bin_size=False won't return the same
context cache key as one with bin_size=None, it leads to have a cache
inconstistency when we write with bin_size=False.  Change Environment
method cache_key() to return the same cache key when bin_size is absent,
bin_size=None or bin_size=False.

Tests on binary fields have been updated to not rely on flush and
invalidate.  We also created specific tests for the binary write() path.

#### [FIX] core: cache inconsistency when assigning related resized image field

After writing or creating on a related Image field, its cache contains
the full-size image instead of the resized one (according to its
attributes max_width and max_height).  Fix it by re-setting the
the resized image on the cache at the end of the inverse method.

#### [FIX] core: flush non-attachment binary field when necessary

Non-attachment binary field needs to be flushed before reading their size,
since the latter relies on the database's binary size function.

#### [FIX] core: fix no-attachment binary for web_save
When bin_size=True is in the context, the computed no-attachment binary
was incorrectly saved to the database. The row is updated with the size
of the binary instead of the value itself (check compute_value() +
cache.set).

Fix this problem by avoiding setting the cache of the bin_size value
as dirty.

Moreover, the binary size is computed with `pg_size_pretty` for the
no-attachment binary fields. Also, in compute_value() we called
b64decode on the value that was previously encoded in base64 by
_compute_datas(). But in our case, we never use _compute_datas()
because it is not stored as an attachment. Then b64decode() doesn't
make sense in this case.

These 2 bugs are now covered by testing web_save(), where cache
consistency is required. It was first reported for this method.




First proposal: https://github.com/odoo/odoo/pull/156673

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