Description of the issue/feature this PR addresses:
In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively.
In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners.

With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers.

Current behavior before PR:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers

Desired behavior after PR is merged:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected.


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

Forward-Port-Of: odoo/odoo#228635

Currently, when a user uses the 'Set Account' button to reconcile a
statement line, the system may also create a reconciliation model
for fees for the given journal/account combination, based on the
previous statement line reference pattern.

To extract a patter from the references, the system computes the
normalised longest common substring. This will be used as regex
matching pattern of the newly created reconciliation rule.

However, the common substring may end up with '\\', which is not a valid
termination of a regex, leading to the error:
`Invalid operation. The regex is invalid.`

Steps to reproduce:

- Have an account '646000 Test Account'
- Create a Bank statement with label 'TEST REFERENCE BNK 2024'
- Set Account 646000
- Create a Bank statement with label 'TEST REFERENCE BNK.OTHER'
- Set Account 646000

Issue:

Error `Invalid operation. The regex is invalid.` will raise
blocking the action

[opw-5086638](https://www.odoo.com/odoo/project.task/5086638)
[opw-5062965](https://www.odoo.com/odoo/project.task/5062965)
[opw-5123963](https://www.odoo.com/odoo/project.task/5123963)
[opw-5166160](https://www.odoo.com/odoo/project.task//5166160)
[opw-5159871](https://www.odoo.com/odoo/project.task/5159871)
[opw-5160108](https://www.odoo.com/odoo/project.task/5160108)
[opw-5109454](https://www.odoo.com/odoo/project.task/5109454)
[opw-5086638](https://www.odoo.com/odoo/project.task/5086638)
...

Forward-Port-Of: odoo/enterprise#97865

FIX] hr_work_entry_holidays: singleton error in overlaping leaves  

**Issue:**
ValueError "Expected singleton: hr.work.entry.type(7, 8)" occurs during work entry
generation when overlapping leaves (sick leave + public holiday) create intervals
containing multiple work entry types.

**Steps to Reproduce:**
1. Go to the **Employees** app and create a new employee.
   * Set the working hours to **empty (fully flexible)**.
2. Create contract fields on the employee:
   * Set **Work Entry Source** to *Attendance*.
   * Set date_version and contract_date_start.
3. Go to **Time Off** → **New**, and create a sick time off for the employee.
   * Example: from **25th to 29th**.
   * Approve the time off.
4. Go to **Configuration** → **Public Holidays**, and create a new public holiday.
   * Example: **27th**, which overlaps with the sick time off.
   * Work Entry Type = **Paid Time Off**.
5. Go to **Payroll** → **Work Entries**.
   * A **traceback** occurs.

**Root Cause:**
In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code`
causes singleton violation when overlapping leaves create intervals containing multiple work entry types.

**Fix:**
Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing
`interval[2].work_entry_type_id[:1].code` to prevent singleton violation.

**Note (18.4+):**
Steps updated for versioned contract architecture where contract fields are set directly on employee.

This resolves payroll blocking issues for deployments with overlapping leave scenarios.

Test : [PR](https://github.com/odoo/enterprise/pull/93902)

opw-4979974

Forward-Port-Of: odoo/odoo#223448

#### Issue:
- Traceback when calculating the cost of a workorder

#### Step to reproduce:
- with apps: mrp, accountant
- create a MO for a product
- add a WO
- confirm
- start the WO
- Action > "Post WIP Accounting entry"

#### Current Behavior:
- get a traceback

#### Expected behaviour
- open the WIP wizard

#### Cause of the issue:
- to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'.

#### Solution:
- check if the end date of the WO is defined


In module mrp_workorder an override of [button_start](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L284-L295) change how work order are launched. Therefore, the test should be launched on an Enterprise run.

opw-4961873

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

Forward-Port-Of: odoo/odoo#221938

This fixes a very rare race condition in the `test_01_donation` tour...
but it is actually surprising it is not more frequent than it is.

Steps to reproduce:
- Simulate a slow network (e.g. using Chrome DevTools)
- Load a page with a donation snippet
- Quickly fill in the donation form and click the submit button
=> You'll sometimes get a crash.

Or a more precise one:
- Add a 1 minute delay to the `/website/get_current_currency` route
- Load a page with a donation snippet
- Fill in the donation form and click the submit button once the page is
  fully loaded.
=> You'll definitely get a crash.

This commit makes that button's handler async-protected, meaning it will
now properly wait for what is needed (the currency) before proceeding,
but it will also display a loading effect for the duration and prevent
double clicking. Once the form is submitted, the loading effect is
removed for stability safety. In master it can probably be improved.

runbot-220885

Forward-Port-Of: odoo/odoo#232585
Forward-Port-Of: odoo/odoo#232408

Scenario to reproduce from 18.0:

- install right-to-left (eg. arabic) language on website
- open a portal record with chatter (eg. /my/invoices/1)
- switch to right-to-left language
- scroll horizontally to the left

Result: there is a huge amount of whitespace scrollable to the left.

Cause:

In 18.0, the chatter has an hidden textarea .o-mail-Composer-fake with
position "left: -10000px; top: -10000px;".

But the chatter assets (portal.assets_chatter_style) are called
dynamically with getBundle which is using the session lang instead of
the website lang.

So the bundle is gotten with the wrong lang and the CSS is not rtlcss'ed
and this create big whitespace to the left of the page.

Fix: set the website request language when getting bundle for the
frontend.

Note: this PR also create a TestLangUrlCommon to prevent TestLangUrl
tests of being run a second time in TestControllerRedirect.

opw-5013485

Forward-Port-Of: odoo/odoo#232671
Forward-Port-Of: odoo/odoo#223575

Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.

Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.

This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.

This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.

Forward-Port-Of: odoo/enterprise#93205

The system crashes when a user tries to edit a website form field and that field has already been deleted from the model.

**Steps to produce:-**
- Install the `website` module.
- Create a `new custom field` on a model(for example, a field on the `mail.mail` model).
- Website > edit > `add Form` widget to a page, and configure it to use the `mail.mail` model.
- Add the newly created custom field to the form and save the page.
- Now, `delete` the custom field which is created previously.
- Return to the website page > edit > mark the deleted field as required, and attempt to save the changes.

**Error:-**
`ValueError: Unable to whitelist field(s) [''] for model 'mail.mail'.`

**Root cause:-**
- At [1], we can see that in the current version, it `only logs an error` using the logger, but in later versions, it `raises a ValueError` instead.

**Solution:-**
- This fix prevents a field from being deleted if it is actively used in any website form.
- It adds a validation check that blocks the deletion and raises an error, forcing the user to remove the field from the form first.

[1]: https://github.com/odoo/odoo/blob/d4f424d731fa93ccd232d0def0a7612997345ef7/addons/website/models/website_form.py#L123-L126

**sentry-5689731444**

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

Forward-Port-Of: odoo/odoo#232415
Forward-Port-Of: odoo/odoo#219590

On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this commit, different crashes could occur.

The first category of crashes concern the sortable hook. It called the onDrop callback even if the dragged element was no longer in the DOM (which occurs if there's a re-rendering while the user is dragging). This has been fixed in the hook, and tested.

Another crash could arise in kanban (in the model). If the user dropped the card while there was a scheduled/ongoing re-rendering, i.e. at a specific moment where the model isn't synchronized with the DOM, the dropped card was still in the DOM, but it's associated datapoint was no longer referenced in hte model. In that case, we can do nothing but cancel the d&d. Note that this couldn't be tested, as reproducing the exact behavior (typically having a slow rendering due to the number of cards to render) isn't possible in a unit test, where user interactions are done programmatically.

Task~5167650

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#231886

**Steps to reproduce:**
- Make a sub category, such as Soda for Drinks in PoS product categories
- Make a product and assign this sub category to it
- Allow the category in the PoS configuration for a Mobile order Session
- Open the Session, the product will not be displayed

**Problem:**
When a product has a subcategory, it is not displayed in the mobile interface, even if said category is allowed in the settings.
This problem does not occur in the Kiosk, only on the mobile sessions.

**Why the fix:**
The products should be displayed if their category has been added to the available categories in the settings. It now works as it does in the PoS and the Kiosk, meaning it is displayed as long as the sub category is mentioned in the Restrict Categories section of the configuration.

Also, in case you have categories A -> A/B -> A/B/C and you don't have products associated to A but you have some in C,
they won't show up in the self.

Currently, products from child categories can be shown in the self when all their parent categories had products associated to them.

When computing the available categories, we would only return categories which had products directly related to them, regardless if their nth child had some. Thus in the setting mentioned previously, only the category C was returned.

However this logic is not correct with the fact that the self, not in kiosk mode, only shows the top categories, meaning only the categories without parents. 
https://github.com/odoo/odoo/blob/434e8cf53a039cc2efc3cb531608028182928ad9/addons/pos_self_order/static/src/app/pages/product_list_page/product_list_page.js#L146-L151

The self was not showing the products from C as C had a parent category. In order for the product from C to be shown, the category A had to be included in the list of available categories.

opw-4934728

Forward-Port-Of: odoo/odoo#221740