### Steps to reproduce issue:

1. Create a Product with Lots/Serials tracking
2. Create a BoM with an operation and add Product as By-Product
3. Create a Manufacturing Order using the BoM, click on Confirm then Plan
4. Go to Shop Floor, click on "Register [the By-Product]"
    - Not the button with the units
6. Click on either "Import Lots" or "Generate Serials"
7. Enter a Lot/Serial number and click on "Generate"
8. Traceback error:

>         loc_dest = self.env['stock.location'].browse(default_vals['location_dest_id'])
>     KeyError: 'location_dest_id'

### Explanation:

When going through the Shop Floor, the context is missing a lot of elements that are normally passed in the manufacturing order form. https://github.com/odoo/odoo/blob/338173e231355d265ddc88bcef5e9b0a608e248e/addons/mrp/views/mrp_production_views.xml#L432-L437

### Suggested fix:

`default_dest_location_id` is the missing element causing the traceback but fixing it reveals that `default_location_id` is also missing, we then add it to the context as well.
Test is done in Enterprise while fix is in Community.

opw-3719439

<strike>
## [FIX] l10n_mx_edi: Set "CFDI to public" to true for foreign invoices

The field "CFDI to public" is currently only set to true in
the domestic to public case (special VAT / Rfc value XAXX010101000).

After this commit "CFDI to public" will also be set to true in the
XEXX010101000 case.

related: task-3731058
</strike>
A part of the original PR was reverted before this PR was merged.
That part was left out in this FW port.
Reverting PR: https://github.com/odoo/enterprise/pull/58697
    
## [FIX] l10n_mx_edi: import: fix partner creation and detection logic

There are currently the following problems when importing an invoice
with an unknown partner. A new partner is created in this case.
For invoices with an unknown domestic partner (no special VAT values):
- (1) There may be a VAT validation error.
- (2) The "CFDI to public" field (l10n_mx_edi_cfdi_to_public) on the
      invoice will be set to True. It should be False.
For invoices with an unknown foreign partner (no special VAT values):
- (3) The partner is created w/o country or VAT value (since only
      the special VAT / Rfc value XEXX010101000 is used).
      Thus the detection logic applied to the partner to decide
      whether we are in the domestic non-public, domestic public or
      foreign case does not work correctly.

The issues are solved after this commit by the following changes
- (A) The country is set to Mexico for all created partners that are not
      from a foreign invoice (XEXX010101000).
- (B) The detection logic to decide the case is updated.
      Also see (C).
- (C) The "Foreign Customers" fiscal position is set for partners
      created during the import of foreign invoices.

Note on (B) / (C):
We still want to assume that partners without a country are Mexican
partners. This is done since (many) Mexican users will not set an
explicit country for Mexican customers.
(One would e.g. not put the country for domestic letters either.)
This is why we use the "Foreign Customers" fiscal position (C).

### Details

(1)
Due to the missing country the wrong VAT validation is used.
The same error can be reproduced on a runbot when creating a new
customer without country and VAT DEA040805DZ4
(works after setting the country to Mexico).

(2) / (3)
Due to the missing country on the partner the invoice is wrongly
interpreted as a domestic invoice to public (XAXX010101000).
This leads to the wrong "CFDI to public" value.

### task

task-3731058

Forward-Port-Of: odoo/enterprise#57516

On an IDE (VSCode) with a TypeScript Server.
For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit [1].

Our main hypothesis is that, due to commit [1] who points to odoo/addons, import lines in those files are resolved first in the scope of the odoo directory.

Consider a file in enteprise:
```js
import { registry } from "@web/core";
import { Component } from "@odoo/owl"

```

From the TSServer point of view it needs to resolve `@web` first, which itself has to resolve `@odoo/owl` in its directory scope, that is, in the scope of odoo community. It then keeps it in cache for later and importantly shadows the one present in enterprise/node_modules. Only then the explicit `@odoo/owl` is resolved with the odoo community's owl module from the cache.

Since that owl module from the cache is not explicitly available in enterprise, there are no imports suggestions.

This commit defines a main.d.ts file that only exposes the community's `@odoo/owl` explicitly. This hypothesis is confirmed by some hints that we discover during debugging:
- delete odoo/nodule_modules in enterprise: @odoo/owl becomes a suggestion again.
- comment the path line of @web/* in enterprise/jsconfig.json, owl is suggested.
- replace the copy of node_modules in enterprise by a symlink to odoo/node_modules, owl is suggested. This last one should also be considered as a valid fix for the current issue, as node_modules in odoo and enterprise *are the same*.

After this commit, owl is proposed for imports in VSCode.

[1]: 62cbb20

Forward-Port-Of: odoo/enterprise#58601

# Issue:

- When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it.

# Explanation:

- When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign.

# Steps To Reproduce:

- Go to the helpdesk > Configuration > Teams.
- For a team (E.g. Customer Care ) tick Random for Assignment Method. Then, add two users to the team.
- Create a ticket and Note the Assigned to user.
- Create a another one with empty 'Assigned to' field.
- Create another ticket and notice how the automation did not apply and the ticket was assigned to the same user.

# Solution:
- add a filter in the search domain of the last_assigned_user to make sure it returns the actual last assigned user.

opw-3746215

Forward-Port-Of: odoo/enterprise#58415
Forward-Port-Of: odoo/enterprise#58084

Currently when a manager goes to validate an allocation, the name/description of the allocation is not displayed. This introduces the need for manager to name each allocation manually to be able to validate them.

Steps to reproduce:
-------------------
* Open **Time off** app
* On the dashboard, select **New allocation Request**
* Save the allocation as it is
* Select **Management** > **Allocations**
  > Observation : The description field of the new allocation is not filled.
* Select the new allocation
* Validate
  > Observation: Unable to validate, description field required.

Why the fix:
------------
The description of an allocation corresponds to the field `name` in the model `hr_leave_allocation`.

https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L40-L45

In the compute method of this field, the name gets actualy computed in the context of `is_employee_allocation`.

https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L169-L177

We are in the context `is_employee_allocation` either by asking a new allocation from the dashboard, either by being on the `hr_leave_allocation_action_my` view.

https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/static/src/views/hooks.js#L62-L65

https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/views/hr_leave_allocation_views.xml#L456

On those two views, the description is computed AND readonly. Since the name is readonly, it means that the inverse of the compute method will not get called, thus never setting `private_name`.

https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L182-L186

When a manages goes to approve an allocation, he goes through **Management** > **Allocations**. The views used are either `hr_leave_allocation_view_tree` or `hr_leave_allocation_view_form_manager`. On those views, we are not in the context `is_employee_id`, the allocation name is no more readonly AND the name is required in order to validate the allocation.

For a manager to be able to see anything in the description, the field `private_name` must be set.

https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L164-L178

This fix aims to create consistency in the creation of allocations. We can observe that the name is not in `vals` in the `web_save` function when creating an allocation through the dashboard or the tab **My Time** > **My allocations**. However, when creating an allocation through **Management** > **Allocations**, name can be found in `vals`.

https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/models/models.py#L69-L69

`vals` corresponds to `changes` in this function:

https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L1045-L1051

To have the name added to `changes`, we ultimately need the following condition to be false.

https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L592-L599

In the manager flow, this is the case as `name` is not readonly. As a regular employee, the only possible way to have this false while keeping the `name` readonly, is to make it an active field.

`name` in now in `vals` and thus in `vals_list` in the create method. This now allows to set `private_name` through the inverse function of name.

opw-3722093

### Steps to reproduce issue:

1. Create a Product with Lots/Serials tracking
2. Create a BoM with an operation and add Product as By-Product
3. Create a Manufacturing Order using the BoM, click on Confirm then Plan
4. Go to Shop Floor, click on "Register [the By-Product]"
   - Not the button with the units
6. Click on either "Import Lots" or "Generate Serials"
7. Enter a Lot/Serial number and click on "Generate"
8. Traceback error:

>         loc_dest = self.env['stock.location'].browse(default_vals['location_dest_id'])
>     KeyError: 'location_dest_id'

### Explanation:

When going through the Shop Floor, the context is missing a lot of elements that are normally passed in the manufacturing order form. https://github.com/odoo/odoo/blob/338173e231355d265ddc88bcef5e9b0a608e248e/addons/mrp/views/mrp_production_views.xml#L432-L437

### Suggested fix:

`default_dest_location_id` is the missing element causing the traceback but fixing it reveals that `default_location_id` is also missing, we then add it to the context as well.
Test is done in Enterprise while fix is in Community.

opw-3719439

Steps to reproduce:
- Enable 2 step reciept in warehaouse settings

Bug1:
- Create and confirm a PO qty = 1
- Open reciept update qty to 4 and validate
- The internal transfer qty is updated to 3 (the difference)

Bug2:
- In inventory overview create a new reciept and mark it as todo
- Update quantity and validate
- Internal transfer is not updated

Root cause:
Initially in version 17 product_uom_qty was changed to indicate the demand before the move is done and it indicates the acutual done qty when the move is done.
After https://github.com/odoo/odoo/pull/130342
product_uom_qty will always indicate the demand qty, and qty_done will always indicate actually done quantity.

Fix:
updating the quantity will create a new move for the difference that is used to trigger new push rule and then merged back in the original when merging product_uom_qty is not updated to keep track of the intial demand but pending linked moves should be updated to reflect the new quantity

opw-3708740

Steps to reproduce [17.0+]:

- Create a website form of any type in which you have:
    - One "Name" or other text field.
    - One field with the "Date" type.
    - One field "Email" with the visibility condition: "Only visible if"
    a field of type "Date" "Is set".

- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.

Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.

After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component 
(including the form date[time]picker fields).

One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.

The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.

[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628

opw-3778129

Current behavior:
---
When the cookie bar is activated, the cookies are deactivated 
by default, unless you click on I agree. 
This prevents UTMs from being set in the cookies

Steps to reproduce:
---
1. Install website_sale and sale_management
2. Go to Settings/Website
3. Activate Cookies Bar
4. Go to Link Tracker
5. Create a new link
6. Set the url as .../shop and Medium as LinkedIn
7. Open a private tab
8. Go to the tracked URL
9. Click on I agree on the cookie bar
10. Buy a product
11. Go back to Sales
12. Find the last public user quotation
13. Go to other info
14. Medium is empty

Cause of the issue:
---
UTMs are read from the cookies.
When you activate the cookie bar, the cookies are deactivated by default. 
So when you go to the tracked url, and it redirects you to the page, it doesn't 
put the info from the url in the cookies. Clicking on I agree doesn't resolve 
the issue because it doesn't reload the page.

Fix:
---
When closing the cookie bar, forcing the info in the URL to be 
stored in the cookies if the key is a UTM.

opw-3681927

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

Forward-Port-Of: odoo/odoo#157630
Forward-Port-Of: odoo/odoo#154924

Steps to reproduce:
- Create an empty database (without demo data)
- Install stock_account
- Go to Invoicing settings
- Select Austria as Fiscal Localization
- Go to Apps
- Try to upgrade stock_account module

Issue:
A traceback is raised.
The module tries to create the default stock accounts properties on the main company, but they already exist, which triggers a violation of the SQL unique constraint (ir_property_unique_index) of "ir.property" on the combination of (fields_id, company_id, res_id) fields.

Cause:
When "stock_account" module is installed/upgraded, the default stock accounts properties are created for the main company with forcecreate="True" option, which means they will be created if their "xml_id" doesn't exist, even if they are declared inside `<data noupdate="1">`.
In this case, they are created with their "xml_id" at the module installation with the following values:
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: False 

When the Austrian localization (or other localizations defining their own stock accounts properties) is selected in the settings, these default properties are deleted and replaced by those coming from the localization package with some similar values but without "xml_id":
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: [depends on the localization package]
 
Then, when upgrading "stock_account" module, as the "xml_id" of the default stock accounts properties cannot be found anymore, the upgrade process will try to re-create them and will trigger the SQL unique constraint.

Solution:
Move the creation of the default stock accounts properties in a python function to check if the default properties already exist based on the combination of "company_id", "fields_id" and "res_id" fields and not based on the "xml_id".

opw-3682320



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

Forward-Port-Of: odoo/odoo#156728

Steps to reproduce:

- Go to website > Switch the navbar to "Hover" mode (see: `Submenus` >
`On Hover`).
- Create a submenu and drag it under a navbar menu item > The submenu
will always disappear before being reached after the hover.

Since Bootstrap does not provide a built-in way to use the "hover" as a
dropdown trigger, a custom implementation was used to handle the "show
on hover" scenario (see: `hoverableDropdown`). This code also relies on
the submenus being correctly positioned on hover.

Starting from [1], the public `menuDirection` widget was completely
removed (used to align website navbar submenus in an optimal way) and
was replaced by a patch that allows Bootstrap to position dropdowns
dynamically inside a navbar (using Popper).

A side effect of this patch is the use of BS default offset config to
set the positions, leading to a small gap that automatically hides the
submenus when hovered.

The goal of this commit is to prevent this issue by simply forcing
the offset to 0 when the dropdowns are inside a navbar.

[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914

opw-3766516

Forward-Port-Of: odoo/odoo#157281

[This other commit] introduced a method to serve Google fonts from the local server. Then it has been back-ported to previous versions with [this commit].
Unfortunately, the font was not identical when the user chose to load the font from Google servers versus from the local server. This discrepancy was due to a missing parameter when downloading the font file to serve it from the local server. This commit fixes the issue by adding the missing parameter.

Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins

=> The text style changes depending on whether you checked the "Serve font from Google servers" option or not.

[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3

opw-3775683

Forward-Port-Of: odoo/odoo#157734

In a single database, you could have two partners who are called John Doe.

Before this commit, any statement line where the partner_name was set with 'John Doe' would return the last one being created, due to the _order attribute on res.partner model, even if the statement line was generated from a payment of the other 'John Doe' (ie first one created).

With this commit, we ensure that the wrong partner is not selected, in case we cannot differentiate one from the other.


Description of the issue/feature this PR addresses:

In case you have two partners with the same name in your DB, and you import a bank statement having a payment from the first created partner, the reconciliation widget will display a filter matching invoices of the last created partn.

Current behavior before PR:

Last partner created is selected for the filter.

Desired behavior after PR is merged:

No partner is selected for the filter if we have multiple ones sharing the same name.

Enterprise test PR: odoo/enterprise#57846

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

Forward-Port-Of: odoo/odoo#157470
Forward-Port-Of: odoo/odoo#155986

When a user tries to access the URL directly, at that time the value of dictionary `kw` is not available. So the error will be generated.

Traceback in sentry:
```
KeyError: 'state'
  File "odoo/http.py", line 2123, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1699, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1726, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1840, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 716, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/microsoft_account/controllers/main.py", line 15, in oauth2callback
    state = json.loads(kw['state'])
```
see-
https://github.com/odoo/odoo/blob/9460c82c4724f347a665cae27db60c4c9a6a950b/addons/microsoft_account/controllers/main.py#L15

This commit will solve the above issue by raising the `BadRequest` if the value of dictionary `kw` does not available.

sentry-4377121133

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

Forward-Port-Of: odoo/odoo#131340

When you create or register a payment, the domain of the payment method lines is based on a computed field dependent of the selected journal. The issue is that the interface isn't blocked when waiting for the onchange return.  So if the user changes the journal, then select the payment method quickly enough while the onchange is still pending, he will be able to select outdated values.

It is a limitation of the js framework, so to avoid the user encoding wrong datas, the fix here is to raise a `ValidationError` telling to re-select the payment method.

To reproduce:
- create second bank journal, with outbound payment method lines having different names than the ones of the first bank journal (in order to distinct them).
- slow down the `_compute_payment_method_line_fields` method
- create a vendor payment, switch the journal to the one created and select the second payment method (before the onchange ends).
- save the payment.

-> The payment has a payment method line from a different journal

opw-3587241

Enterprise PR: https://github.com/odoo/enterprise/pull/56602

Forward-Port-Of: odoo/odoo#157784
Forward-Port-Of: odoo/odoo#147583