[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

Since this commit [1], the two searchbar snippets are broken.

The search bar input seems invisible because it shares the same color as the default snippet background and has no border. This style matches the search inputs used in apps (like the "/shop" search bar), which isn't affected by the "Input fields" settings in the "Theme" tab.

To resolve this issue, this commit introduces a new option to choose between the "light" style (similar to "/shop" search bars) and the "default input style" for the 2 "Search" snippets.

The "default input style" is automatically applied when the "Search" snippet (excluding saved snippets) is dropped to address the issue caused by the light-on-light color scheme.

Steps to Reproduce the Issue:

- While in Website edit mode, drag and drop a "Search" snippet onto the page.
- Bug: The input appears invisible due to the lack of a border and a background color identical to the snippet's section color.

[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20

task-3662985

Forward-Port-Of: odoo/odoo#154435

<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 and left out in 17.0+ (https://github.com/odoo/enterprise/pull/58522)
    
## [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#58522
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

Steps to reproduce:
-
- Go to Field Service app and create a new task.
- Use the smart button to access the catalog and add a product.
- Go back to the task and use the smart button to access the SO.
- Set the unit price of the added product to zero.
- Create the associated invoice.

**You are allowed to create the invoice and aline will be displayed for the SOL corresponding to the products with a unit price of zero.**

Notes: This is the expected behavior for invoices generated from regular SO. However, AJU the PO of the Field Service application decided to change this behavior for invoices generated from SO coming from field services see task 3266856 and commit 849241e (the SOL invoice status should be 'no').

Cause of the Issue:
-
When you create an invoice from a sale order, the `invoiceable_lines` are computed at this point:
https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1251-L1258 by the `_get_invoiceable_lines` method. As one can see in this method: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1220 if the `qty_to_invoice` of SOL is positive, the SOL will therefore appear in the `invoiceable_lines` and the associated invoice line will be created a few lines below to appear on the invoice: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1276-L1279

Fix:
-
In order for the SOL to not generate an`invoiceable_line` we set the `qty_to_invoice` to zero when the SOL comes from a field service task and display a product with a unit price of zero.

Notes: To keep the flow coherent between the `qty_to_invoice` and the `invoice_status` of SOL for field services SO and since `price_unit` is a float that should not be compared using an `==` we also changed the float comparaison of the `_compute_invoice_status` method introduced in the commit 849241e.

opw-3776475
---

Forward-Port-Of: odoo/enterprise#58057

# 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

**Current behavior:**
If a payslip report is printed for an employee with no set language, it will be printed in English.

**Expected behavior:**
The primary fallback language should be that of the database before going to the base level default of English.

**Steps to reproduce:**
1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish

2. Deactivate the default English language pack

3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Todos los recibos de nómina`, then select any report and click the Imprimir (Print) button

4. Observe some sections are in English

**Cause of the issue:**
When an employee's language is not set, English is used as a default.

**Fix:**
Look to use the environment's language if the Employee's is False.

Ammended to fix other situations in hr_payroll where an employee
language is accessed without using `env.lang` as a primary
fallback.

opw-3747839

Forward-Port-Of: odoo/enterprise#57780

## Steps to reproduce
- Install **Payroll**, **Planning** and **Time Off** apps
- Create a new working time of 56 hours per week:
	- Go to **Payroll** app
	- Go to **Configuration** > **Working Times**
	- Create a **NEW** working time -named 56 hours/week- that has 7 days (Monday to Sunday), each from **8:00** to **16:00**
	- Set a time zone of your choice, in my case it Africa/Cairo
- Go to **Employees** app and create a **NEW** Employee -named 56 hours/week employee- with the same time zone as the new working time
- Create a new Contract for the newly created employee:
	- Click on the Contract smart button
	- Click on **CREATE**
	- Set the **Contact Start Date** -ex. 1 Feb 2024-
	- Set the **Working Schedule** to the newly created working time (56 hours/week)
	- Set the **Work Entry Source** as **Planning**
	- Set the state of the contract to be **RUNNING**
- Create a 10 day planning:
	- Go to the newly created 56 hours/week employee
	- Click on the Planning smart button
	- Click on **NEW** to add a new Shift (example values):
		- from 20 Feb 2024
		- to 29 Feb 2024
		- from 8:00 to 16:00
	- Click on **PUBLISH**
- Go to the newly created 56 hours/week employee. Click on the Work Entries smart button. Set the view as _list_. We now have a planning of 10 days totaling 80 hours.
- Create a time off:
	- Go to the newly created 56 hours/week employee
	- Click on the Time Off smart button
	- Click on a day to request a time off -for our example set as 23 Feb 2024-
	- Go to the **Time Off** app > **Approvals** > **Time Off**
	- Remove **My Team** filter
	- Approve the newly created time off
- Go back to the Work Entries of our employee
- Click on **REGENERATE WORK ENTRIES**
- Set the Work Entries in _list_ view
- Notice how the duration of the last work entry is **_incorrectly_** calculated:
	- The 1st entry has 24 hours for 3 days of work (20 Feb, 21 Feb, 22 Feb) which is CORRECT
	- The 2nd entry is for the time off having 8 hours for 1 day (23 Feb) which is CORRECT
	- The 3rd entry has **24** hours! although it's for 8 days (24, 25, 26, 27, 28, 29 Feb) totaling **48** hours. There are **24** hours difference (3 days), which actually (3 holidays in my case)

## Investigation
#### First, let's see how we reach to recalculating the duration (allocated hours) of the planning slots:
- When the work entries are regenerated, the slots durations are recalculated via `_get_duration_batch()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L43 more precisely  `_get_planning_duration` which recompute the durations by creating new temporary planning slots -notice how we didn't pass the `resource_id` of the slot-https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L29-L36 passing the values from the original slot but the new start and end date.
- That triggers `_compute_allocated_hours()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L239 
#### Second we'll examine three cases:
1. What if the slot has no resource_id ? (This is actually the issue specific to the ticket, the `resource_id` is not passed)
	- the `planning_slots` will be empty, while the `slots_with_calendar` will have our respective slot which triggers the `if slots_with_calendar:` block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- As we have no resource, we fall back to the `company_id.resource_calendar_id`  which is the standard 40 hours/week https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L269-L271
	- We then go into `_get_working_hours_over_period()` which will use the `company_id.resource_calendar_id` as it has no `resource_id` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1677-L1679
2. What if the slot has a resource with `flexible_hours = False`? Same as 1
3. What if the slot has a resource with `flexible_hours = True`?
	- the `planning_slots` will will have our respective slot https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- which will trigger this block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L249-L252
	- going into the `_calculate_slot_duration()` function that has a drawback:
		- The period is a timedelta object https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1106 that has days (`period.days`) which is the number of full days in that period and seconds (`period.seconds`)
		- if the `period.seconds` is not ZERO that means we have a non-full day.
		- when `max_duration` is calculated we always round up the days by adding 1 https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1108 even though `period.seconds` can be 0. in that case we should only take `period.days` into consideration

## The Fix:
- By passing the `resource_id` when creating the new temporary slots, we make sure we are dealing with the correct `resource_calendar_id`
- The `_calculate_slot_duration()` modification addresses the issue when `resource_id` has `flexible_hours = True` basically if the employee work with flexible hours

opw-3662389

Forward-Port-Of: odoo/enterprise#58409
Forward-Port-Of: odoo/enterprise#57205

### Summary

Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741.

### Steps to reproduce

* make sure you're on an instance running on Windows [^1]
* install `account_accountant`
* go to any reconciliation model that has Auto-Validate enabled
* click on 'Run manually'

You should be met with a traceback: `TypeError: '<' not supported between instances of 'int' and 'NoneType'`

### Cause

The system expects `tools.config['limit_time_real_cron']` to be a number. However, on Windows systems, `limit_time_real_cron` and a few other configuration keys are disabled, and always set to `None`.
See https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L488-L497

opw-3752912
opw-3780549

[^1]: For testing on Linux, you can modify these two conditions to behave as if `os.name != 'posix'`:
https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L494-L497
https://github.com/odoo/odoo/blob/7fc9a0bd0a1871b14c508cce73e0f103de9c1283/odoo/modules/registry.py#L50-L57

Forward-Port-Of: odoo/enterprise#58550
Forward-Port-Of: odoo/enterprise#57728