Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`. Steps to reproduce: - make a livechat with visitor with `crh-Latn` locale - as livechat operator, attempt to translate the message This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Langu

Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`.

Steps to reproduce:
- make a livechat with visitor with `crh-Latn` locale
- as livechat operator, attempt to translate the message

This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Language on April 4th [1], very recently from the date of this commit.

Because of the recency of the new locale, babel lack its parsing. Failure lead to error `UnknownLocaleError`, which is a problem because data of translated message also passes the Language name, which requires the good parsing of the locale by babel.

This commit fixes the issue by displaying the language name as the locale code in case babel was unable to parse it. In practice this happens rarely, and there's incentive to update babel as quickly as possible, but that's not a reason to display the translated message even if it cannot deduce the lang name.

[1]: https://babel.ua/en/news/116901-ukraine-approves-new-crimean-tatar-orthography-based-on-latin-script

Forward-Port-Of: odoo/odoo#205943

Before this commit, when a website visitor is live chating with an operator on a mobile device, it's not possible to navigate on website. This happens because the livechat conversation takes the whole screen, and the only way to see the website on the same page is to close the livechat conversation. This commit fixes the issue by allowing to fold a chat window for livechat visitor in mobile specifically. When this is folded, it is shown as a small chat bubble, which displays the avatar of

Before this commit, when a website visitor is live chating with an operator on a mobile device, it's not possible to navigate on website.

This happens because the livechat conversation takes the whole screen, and the only way to see the website on the same page is to close the livechat conversation.

This commit fixes the issue by allowing to fold a chat window for livechat visitor in mobile specifically. When this is folded, it is shown as a small chat bubble, which displays the avatar of operator and the unread counter. Clicking on the bubble expands the conversation to full-screen again.

Website footer can have some helpful information, so there's a special behaviour to move the chat bubble up when reaching the bottom of the website.

Task-4599435

![Feb-24-2025 17-10-05](https://github.com/user-attachments/assets/b585b41b-6b0b-4925-85ba-26152183d0a0)

Forward-Port-Of: odoo/odoo#199088

Related enterprise PR : https://github.com/odoo/enterprise/pull/81754 Forward-Port-Of: odoo/odoo#205379

Related enterprise PR : https://github.com/odoo/enterprise/pull/81754

Forward-Port-Of: odoo/odoo#205379

Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before ru

Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company.

Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe.

Ensure a supported country is set before running the test.

https://runbot.odoo.com/odoo/error/163118

Forward-Port-Of: odoo/odoo#206066

Steps to reproduce: - Drag and drop image gallery snippet. - Delete the snippet. - Click on Undo. - The snippet appears but images will not be there. The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted. task-4690318 Forward-Port-Of: odoo/odoo#206019

Steps to reproduce:

- Drag and drop image gallery snippet.
- Delete the snippet.
- Click on Undo.
- The snippet appears but images will not be there.

The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted.

task-4690318

Forward-Port-Of: odoo/odoo#206019

Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295

Versions
--------
- 16.0+

Steps
-----
1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`.

Issue
-----
`AttributeError`

Cause
-----
The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`.

Solution
--------
The test works just as well without the method call, so we can simply remove it.

runbot-163194

Forward-Port-Of: odoo/odoo#206295

A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206070 Forward-Port-Of: odoo/odoo#206040

A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com.

Forward-Port-Of: odoo/odoo#206070
Forward-Port-Of: odoo/odoo#206040

Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed. Steps to reproduce ----- 1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu" 2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu" Cause ----- The styling `word-break: break-all;` was added to this element in #140095 to avoid

Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed.

Steps to reproduce
-----
1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu"
2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu"

Cause
-----
The styling `word-break: break-all;` was added to this element in #140095 to avoid overlapping category names. However `break-all` always breaks in the exact place needed, often resulting in breaks in the middle of words.

Solution
-----
Use `overflow-wrap: break-word;` instead which will break between words if possible and only break in the middle of a word if needed.

opw-4642999

Forward-Port-Of: odoo/odoo#205080

Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508

Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it.

Forward-Port-Of: odoo/odoo#204508

* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#189342 Forward-Port-Of: odoo/odoo#188760

* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much

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#189342
Forward-Port-Of: odoo/odoo#188760

### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ

### Issue:

It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point.

### Step to reproduce:

- Set up Sendcloud, for a belgian company
- Select bpost and dpd for delivery and returns while loading products
- On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method.
- With an employee confirm the delivery order that was created
#### > A problem occured in the generation of the return label

### Cause of the issue:

The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here:
https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point.

#### Note:

Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels.

opw-4562040

Forward-Port-Of: odoo/enterprise#83357

* quality_mrp, stock_barcode ### Steps to reproduce: - Create a product FP with a bom: - 1 x comp - Create a control check point per product for FP for the manufacturing operation type - Go to the barcode app - Scan the manufacturing operation type - Scan FP and set the qty_producing - Click quality check #### > Traceback ### Cause of the issue: By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As

* quality_mrp, stock_barcode

### Steps to reproduce:

- Create a product FP with a bom:
    - 1 x comp
- Create a control check point per product for FP for the manufacturing operation type
- Go to the barcode app
- Scan the manufacturing operation type
- Scan FP and set the qty_producing
- Click quality check
#### > Traceback

### Cause of the issue:

By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As such, the `resId` the barcode `MainComponent` is `false`. However, this "id" is used in the orm call of the `checkQuality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L15-L19 As such, we launch a call of the `check_quality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/quality_mrp/models/mrp_production.py#L70-L72 that ends up raising an traceback since the `product_uom` is `False` on the "unexpected" record `mrp.production(False,)`.

### Fix:

Since we just saved the record and hence created the record prior to this call:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L12-L15 we should rather rely on the new created id.

opw-4644128

Forward-Port-Of: odoo/enterprise#82688

In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#81754

In this PR we :
-Allow manual input of source tax adjustments
-Improve transmission error messages
-Add missing translations
-Reintroduce work information and skills tab

Forward-Port-Of: odoo/enterprise#81754

Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#81018

Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454

Forward-Port-Of: odoo/enterprise#81018