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

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

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

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

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

**Steps to reproduce:**
- Go to PoS, make an order and pay for it
- Before clicking next order close your connection with the server
- Make a purchase like this
- Go back online and check the orders in the backend

The order made online only has the receipt number, but the order made offline has *Order* in front of it.

**Why the fix:**
The receipt number on a PoS order should be consistand and should not be changed depending on if the purchase was made online or offline.
With this commit, every order will have only it's receipt number without the *Order* in front of it even if it was made offline.

It is still possible to see if an order was made online or offline with the **F** variable, which is the first number of the last part of the receipt number. If it is 1, the order was made offline, if it is 0, it was made online.

The *refPrefix* parameter from the *getNextOrderRefsLocal* function is not used anymore, so it has been replaced by an empty string in the function call in stable and could be deleted when in master.

opw-4965095

Forward-Port-Of: odoo/odoo#224416

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