Steps to reproduce: - Force _verify_updated_quantity returns warning - Add product to cart - exception shown Explanation: - When _verify_updated_quantity returns warning, it will use WarningNotification in CartNotification only. However CartNotification required currency_id for AddToCartNotification, therefore exception throw. Forward-Port-Of: odoo/odoo#204585

Steps to reproduce:

- Force _verify_updated_quantity returns warning
- Add product to cart
- exception shown

Explanation:

- When _verify_updated_quantity returns warning, it will use WarningNotification in CartNotification only. However CartNotification required currency_id for AddToCartNotification, therefore exception throw.

Forward-Port-Of: odoo/odoo#204585

When viewing sale report for POS orders, the gross weight number will be off by a factor of how much larger/smaller the UOM ratio is compared to the base. For example, if we sell 1 qty of product with a weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or 25kg. This fix removes the UOM factor from being taken into account when calculating gross weight for POS orders. This is a valid solution because if we

When viewing sale report for POS orders, the gross weight number will
be off by a factor of how much larger/smaller the UOM ratio is
compared to the base. For example, if we sell 1 qty of product with a
weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field
will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or
25kg. This fix removes the UOM factor from being taken into account
when calculating gross weight for POS orders. This is a valid solution
because if we treat 'SUM(p.weight * l.product_uom_qty / u.factor *
u2.factor)' as the ground truth from sale report for sale orders, the
'/ u.factor * u2.factor' portion of the calculation will cancel out
to 1 for POS orders. This is because the only time 'u2.factor/u.factor'
is not 1 for sale orders is when the product template's UOM factor is
different from the sale order line's UOM factor. Since we can not
change the UOM of pos order lines, the pos order line's factor will
always be the same as the product template's therefore
'u2.factor / u.factor' for pos orders will always be 1 and can be
ignored.

To reproduce error on blank DB:
1) For a product, change its UOM to a UOM with a ratio not equal to 1
2) For the same product, change its weight in the inventory tab to
a number not equal to 0
3) In POS make a sale with this product and confirm the order
4) Check the gross weight of the product just sold through POS by
going to sales->reporting->list view and adding gross weight to the
view through studio

opw-4452892

Forward-Port-Of: odoo/odoo#204386
Forward-Port-Of: odoo/odoo#203144

Steps to reproduce ================== - Go to the project app - Open any project - zoom / dezoom a few times => At some point, the top border on the first kanban card will disappear. Cause of the issue ================== This is due to a negative margin on the bottom of kanban cards. This is made in order to have no duplicated border between cards. Solution ======== We can set a top margin for the first card. opw-4668595 Forward-Port-Of: odoo/odoo#204654 Forward-Port-

Steps to reproduce
==================

- Go to the project app
- Open any project
- zoom / dezoom a few times => At some point, the top border on the first kanban card will
   disappear.

Cause of the issue
==================

This is due to a negative margin on the bottom of kanban cards. This is made in order to have no duplicated border between cards.

Solution
========

We can set a top margin for the first card.

opw-4668595

Forward-Port-Of: odoo/odoo#204654
Forward-Port-Of: odoo/odoo#204567

Currently there are two bugs: 1) Selling a kit product to another internal company (inter_company) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine` * Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit product via inter_company whic

Currently there are two bugs:
1) Selling a kit product to another internal company
(inter_company) and validating the delivery will not update the
`qty_delivered` field on the corresponding `SaleOrderLine`
* Currently the filters to capture moves which informs the
delivered quantity of the line do not account for moves with
`location_dest_id` pointing to the inter-company transit
location (which should count towards the delivered value)

2) Receiving a kit product via inter_company which has a
`comp:final` ratio >1 will result in an inaccurate update on the
`qty_received` field on the corresponding `PurchaseOrderLine`
* The BoM of the sold kit-product belongs to the selling
company, and in the purchase_mrp override of
`_compute_qty_received` they fail to get marked as kit lines
because the `bom_line_id` is hidden due to a company-precise
domain constraint

**Steps to reproduce:**
*Having `sale_purchase_stock_inter_company_rules` and enabled
synchronization of sale & purchase orders for both companies*
1. Create a kit product

2. Deliver it to another internal company

3. After validating the delivery, check the the sale order line
and observe that the delivered qty is 0

**Cause of the issue:**
When computing `qty_delivered`, we have the following filters to
capture in/out move qty:
https://github.com/odoo/odoo/blob/ef1be75601e7ce346d8e6b9367505cbf39b05101/addons/sale_mrp/models/sale_order_line.py#L69-L70
which don't account for moves to inter-company transit.

When computing `qty_received`, we aggregate purchase lines:
https://github.com/odoo/odoo/blob/b13e46f06c1d3166fd64fc72cacd8af1f3673ae6/addons/purchase_mrp/models/purchase.py#L56
however using the line's `company_id` means the BoM belonging to
the delivering company isn't revealed. Then the `qty_received`
is computed as though the line was an ordinary product, leading
to the mismatch between product and qty.

**Fix:**
Modify the existing incoming/outgoing move filters in the qty
received and delivered compute methods to account for
inter-company moves.

opw-4267210

Forward-Port-Of: odoo/odoo#204136
Forward-Port-Of: odoo/odoo#195726

Steps to reproduce the bug: - Create a storable product, that is tracked by serial number - Add to in Hand the product and set the serial number to it - Create a quotation of this product and confirm to be a sale order - Open a pos session, and select quotations and orders from pos - Select the sales order created and settle the order - The order line will be imported without asking if serial number can be linked Issue: The function settleOrder in pos_sale/pos_store.js reads the sales

Steps to reproduce the bug:
- Create a storable product, that is tracked by serial number
- Add to in Hand the product and set the serial number to it
- Create a quotation of this product and confirm to be a sale order
- Open a pos session, and select quotations and orders from pos
- Select the sales order created and settle the order
- The order line will be imported without asking if serial number can be linked

Issue:
The function settleOrder in pos_sale/pos_store.js reads the sales order using this.data.read, this will read the sales order with the sale order line but without the information of the lot numbers and more info. These informations are returned in a read_converted function on sale.order.line inherited model on pos_sale, and this function is not used to read the sale order lines, hence no information related to the lots and the pop up that asks if the lot number may be linked will not appear anymore.

opw-4591887

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#204870
Forward-Port-Of: odoo/odoo#201400

Transferring an order to a table on a different floor was not working, so a fix has been made for it in 18.0 by the commit 29d06d76889c8231190e563688fa698a551c3672. However, later refactors overrode the fix of the previous commit for versions 18.1 and up. This commit restores the previous fix in 29d06d76889c8231190e563688fa698a551c3672 and adds an appropriate test. opw-4645820 Forward-Port-Of: odoo/odoo#203866

Transferring an order to a table on a different floor was not working, so a fix has been made for it in 18.0 by the commit 29d06d76889c8231190e563688fa698a551c3672. However, later refactors overrode the fix of the previous commit for versions 18.1 and up.

This commit restores the previous fix in
29d06d76889c8231190e563688fa698a551c3672 and adds an appropriate test.

opw-4645820

Forward-Port-Of: odoo/odoo#203866

Hello, I am submitting my signed Individual Contributor License Agreement (CLA) to contribute to the Odoo project. This PR adds my CLA file under `doc/cla/individual/`. Thank you! 😊 Forward-Port-Of: odoo/odoo#204868

Hello,

I am submitting my signed Individual Contributor License Agreement (CLA) to contribute to the Odoo project.  

This PR adds my CLA file under `doc/cla/individual/`.  

Thank you! 😊

Forward-Port-Of: odoo/odoo#204868

Before this commit: ==================== Product price edits from the POS frontend were not immediately reflected on the product screen. After this commit: ==================== Product edits now instantly update and reflect on the product screen. Task-4431596 Forward-Port-Of: odoo/odoo#203470

Before this commit:
====================
Product price edits from the POS frontend were not immediately reflected on the product screen.

After this commit:
====================
Product edits now instantly update and reflect on the product screen.

Task-4431596

Forward-Port-Of: odoo/odoo#203470

The self-ordering kiosk does not correctly display translations for product names and other UI elements when switching languages. Some elements remain in English or the database language, even when translations are available. ### Steps to Reproduce 1. Open **Point of Sale** and navigate to **Configuration > Settings**. 2. Select a POS configuration that has **Kiosk/Self-ordering** enabled. 3. Add additional languages to the Kiosk and save the changes. 4. Open a product availab

The self-ordering kiosk does not correctly display translations for product names and other UI elements when switching languages. Some elements remain in English or the database language, even when translations are available.  

### Steps to Reproduce  

1. Open **Point of Sale** and navigate to **Configuration > Settings**.  
2. Select a POS configuration that has **Kiosk/Self-ordering** enabled.  
3. Add additional languages to the Kiosk and save the changes.  
4. Open a product available in the Kiosk POS and add translations for its name.  
5. Start a new Kiosk session, switch to the Kiosk window, and change the language.  
6. Notice that product names and other UI elements remain in English instead of switching to the selected language.  

### Cause  

- The `/pos-self/data/<config_id>` route was missing `website=True`, preventing it from receiving the correct frontend language setting.  
- Adding `website=True` fixes this issue, allowing the POS frontend to receive the correct language.  

### Secondary Issue

- After adding `website=True`, another problem emerged when the **website module** is installed.  
- In this case, the available languages were taken from the **website settings** instead of the **POS settings**.  
- This means that if the website only supports English but the POS Kiosk supports both English and French, switching the Kiosk language to French would fail. The system would always revert to English because language validation was still based on website settings rather than POS settings.  

### Solution  

1. **Fix the original issue** by adding `website=True` to ensure the POS self-ordering system receives the correct language.  
2. **Work around the secondary issue** by checking the **Referer** header to determine if the request comes from a POS self-ordering session.  
3. **Ensure language validation is based on POS settings**, not website settings, by retrieving available languages from the POS configuration when necessary.  

This solution follows a similar approach to the fix in **cd69a32503f4dcd11851908e2c983e1d49a1c2a8**, but in this case, the problematic route (`/website/translations`) is not strictly POS-related. Therefore, we must check the referer to extract the correct POS information.


opw-4557569
opw-4471819
opw-4436306

Forward-Port-Of: odoo/odoo#204919
Forward-Port-Of: odoo/odoo#201594

Since paypal does not allow empty fields to be sent, its better to add email only if it exists. Some customers find it confusing that paypal integration fails without proper feedback that the issue comes from the empty email in their company form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204636

Since paypal does not allow empty fields to be sent, its better to add email only if it exists.

Some customers find it confusing that paypal integration fails without proper feedback that the issue comes from the empty email in their company form.


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

Forward-Port-Of: odoo/odoo#204636

Purpose ======= The Indian government updated its UOM code https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes) So In this commit, I have updated `l10n_in_code` in UOM Mili Meter and Square Foot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204867 Forward-Port-Of: odoo/odoo#204598

Purpose
=======
The Indian government updated its UOM code
https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes)

So In this commit, I have updated `l10n_in_code` in UOM  Mili Meter and Square Foot.

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

Forward-Port-Of: odoo/odoo#204867
Forward-Port-Of: odoo/odoo#204598

Since `purchase_price` depends on their `move_ids.picking_id.state`, we risk overwriting manual edits to the field at various points in an ordinary processing of a sale, here specifically during order confirmation. Prior to commit: e24d922 standard cost method product lines would not have their `purchase_price` recomputed, while non-standard product would (meaning manual edits will only be saved for standard cost lines). This is a partial revert of that commit to bring back the beha

Since `purchase_price` depends on their
`move_ids.picking_id.state`, we risk overwriting manual edits to
the field at various points in an ordinary processing of a sale,
here specifically during order confirmation.

Prior to commit: e24d922 standard cost method product lines
would not have their `purchase_price` recomputed, while
non-standard product would (meaning manual edits will only be
saved for standard cost lines).

This is a partial revert of that commit to bring back the
behavior of non recomputed standard cost lines' `purchase_price`

Additionally, we re-fix the use-case from the aforementioned
commit by allowing `purchase_price` recomputation (and
overwrites) when a line has no product qty but does have
delivered qty (indicating it was added from the delivery rather
than directly on the sale order itself.

Forward-Port-Of: odoo/odoo#204323
Forward-Port-Of: odoo/odoo#202854

Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Enterprise PR: https://github.com/odoo/enterprise/pull/77741 Forward-Port-Of: odoo/

Before this fix, it was possible to add more combo products than available
to the cart. Indeed, the available quantity was only checked in the combo
configurator, but not in other places where the quantity could be updated
(such as the product page or the cart).

This fix introduces a "max quantity" concept for combo products, which is based
on the available quantity of their combo items.

opw-4378554

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

Forward-Port-Of: odoo/odoo#203549
Forward-Port-Of: odoo/odoo#188860

In this commit, we fix multiple indeterministic tours: - website/static/tests/tours/media_dialog.js Add a step to ensure all images are loaded before exiting the tour to avoid message: "CORS is misconfigured on the API server, image will be treated as non-dynamic." - project/static/tests/tours/project_task_history.js Use stepUtils.saveForm to ensure form is well saved before continue. - website/static/tests/tours/snippets_all_drag_and_drop.js Remove a step that can cause undeterministic fai

In this commit, we fix multiple indeterministic tours:

- website/static/tests/tours/media_dialog.js Add a step to ensure all images are loaded before exiting the tour to avoid message: "CORS is misconfigured on the API server, image will be treated as non-dynamic."
- project/static/tests/tours/project_task_history.js Use stepUtils.saveForm to ensure form is well saved before continue.
- website/static/tests/tours/snippets_all_drag_and_drop.js Remove a step that can cause undeterministic failure during tours.
- pos_restaurant/static/tests/tours/pos_restaurant_tour.js Add a delay when transfering the order.
- website/static/tests/tours/page_manager.js Add a last step to ensure reloading is done before exiting the tour to avoid "Error received after termination: TypeError: Failed to fetch" error.
- website/static/tests/tours/html_editor.js Add steps to wait the iframe reload.

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#204546
Forward-Port-Of: odoo/odoo#204109

Before this commit, the refresh_token handling was done in the calendar module, even though it relates to token management and should therefore be handled by microsoft_account, which manages tokens and requests to Microsoft. task-4653852 Forward-Port-Of: odoo/odoo#204619 Forward-Port-Of: odoo/odoo#202309

Before this commit, the refresh_token handling was done in the calendar module, even though it relates to token management and should therefore be handled by microsoft_account, which manages tokens and requests to Microsoft.

task-4653852

Forward-Port-Of: odoo/odoo#204619
Forward-Port-Of: odoo/odoo#202309

Form and kanban view archs are compiled into owl templates. Those archs are translated server-side, before being sent to the client. They can contain `t-translation` directives (typically ="off" to disable translations). This tells the view processing in python not to translate the subtree. In the js compilers, that attribute is listed among the tolerated attributes for kanban archs, but not for forms. However, the cases are similar, so their should be not differences between the two. More

Form and kanban view archs are compiled into owl templates. Those archs are translated server-side, before being sent to the client. They can contain `t-translation` directives (typically ="off" to disable translations). This tells the view processing in python not to translate the subtree.

In the js compilers, that attribute is listed among the tolerated attributes for kanban archs, but not for forms. However, the cases are similar, so their should be not differences between the two.

Moreover, since [1], compiled templates are wrapped into a
```xml
<t t-translation="off"/>
```
node, s.t. terms aren't translated twice (once in python, and once in js, by owl).

Instead of tolerating the `t-translation` directive in form view, this commit ignores it in all view compilers. This directive indeed makes sense, so it is valid to use it in kanban and form archs (then used by the view processing in python). But the view compilers in js must ignore it, so we simply remove it.

[1] odoo/odoo#158759
Fixes runbot error-134670

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

Thanks to this fix: https://github.com/odoo/odoo/commit/8ad00b8ee6340dba1e027bb27a8f05489b4253a9 we can revert this one: https://github.com/odoo/odoo/pull/200777/commits/237feaee5fcf1e166bf39e78e8839b191f92c306 The pot file already deleted: https://github.com/odoo/odoo/commit/0361582de7c28bb4847a9c4dbaa712b67f4ca577#diff-4424c1629e21b466bb7af6ab0cb3a674d1bf3e75d93e7e76cf77870dc5bcc853R8693-L9114 opw-4628611 Forward-Port-Of: odoo/odoo#204606

Thanks to this fix:
https://github.com/odoo/odoo/commit/8ad00b8ee6340dba1e027bb27a8f05489b4253a9

we can revert this one:
https://github.com/odoo/odoo/pull/200777/commits/237feaee5fcf1e166bf39e78e8839b191f92c306

The pot file already deleted:
https://github.com/odoo/odoo/commit/0361582de7c28bb4847a9c4dbaa712b67f4ca577#diff-4424c1629e21b466bb7af6ab0cb3a674d1bf3e75d93e7e76cf77870dc5bcc853R8693-L9114

opw-4628611

Forward-Port-Of: odoo/odoo#204606

This reverts commit 54b8a41bb6f61555511714ce7ff476132b97f45d. The feature was never fully implemented Forward-Port-Of: odoo/odoo#204357

This reverts commit 54b8a41bb6f61555511714ce7ff476132b97f45d.

The feature was never fully implemented

Forward-Port-Of: odoo/odoo#204357

Before this commit, when a message is edited, the "(edited)" label was put under the text content. This happened because the "(edited)" label is added after the message text content. The text content is html, and usually this is a `<p>` in discuss conversations, automatically added by the html_sanitize on the `mail.message@body` field. This commit fixes the issue by making the `.o-mail-Message-edited` node display the edited label at this place. This node with this classname is appended to

Before this commit, when a message is edited, the "(edited)" label was put under the text content.

This happened because the "(edited)" label is added after the message text content. The text content is html, and usually this is a `<p>` in discuss conversations, automatically added by the html_sanitize on the `mail.message@body` field.

This commit fixes the issue by making the `.o-mail-Message-edited` node display the edited label at this place. This node with this classname is appended to content when a message has been edited. Since message edited in Discuss are making the last paragraph of message text content inline, so that the "(edited)" label is put inline with the message content.

Before / After
<img width="255" alt="Screenshot 2025-03-31 at 14 36 25" src="https://github.com/user-attachments/assets/15478ee5-5703-4747-b5ae-8cbc5582a5a8" /> <img width="249" alt="Screenshot 2025-03-31 at 14 36 05" src="https://github.com/user-attachments/assets/c1d2cc24-f4bb-443b-bb03-e0f53682170b" />

Forward-Port-Of: odoo/odoo#204922
Forward-Port-Of: odoo/odoo#204148

Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `

Steps:
- install `contacts` and `sale_management`
- Open a contact in a form view and add a sub-contact
- Don't fill contact name field
- Save & Close
- Go to Quotations
- Select this new contact as Customer (it should have a name like Parent contact, Other Address)
- Add any product
- Save
- Click on `Preview`
- Click on `Sign & Pay`
- Traceback

When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `SignatureForm` initialization, `onMounted` raise a traceback, because it calls directly `this.signature.resetSignature`.

This commit adds default functions to `resetSignature` and `getSignatureImage` to prevent the crash.


In addition to the this fix, I added a fallback to the default name on signature form to `sale_order.partner_id.commercial_partner_id.name` if `sale_order.partner_id.name` is not set.

opw-4504223

Forward-Port-Of: odoo/odoo#202774
Forward-Port-Of: odoo/odoo#202318

- With a IT company, create a vendor bill with a line with the tax 22% G RC and set l10n_it_payment_method to MP01. - Export the bill with "Send Tax Integration". - Import the xml generated. The l10n_it_payment_method field is not set to MP01. In the l10n_it_edi_import_invoice, the l10n_it_payment_method field was not imported opw-4646816 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I

- With a IT company, create a vendor bill with a line with the tax 22% G RC and set l10n_it_payment_method to MP01.
- Export the bill with "Send Tax Integration".
- Import the xml generated.

The l10n_it_payment_method field is not set to MP01. In the l10n_it_edi_import_invoice, the l10n_it_payment_method field was not imported

opw-4646816

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

### Steps to reproduce: ISSUE 1: - Insert multiple icons (e.g., /image, icon) into a paragraph. - Place the cursor before the first icon. - Press the right arrow key, and notice that the selection jumps to the second paragraph, skipping over the icons. ISSUE 2: - Create three paragraphs. - Insert icons into the second paragraph. - Place the cursor in the first or third paragraph and press the up/down arrow key it skips the second paragraph. - Set up following HTML: ```html <p>

### Steps to reproduce:

ISSUE 1:

- Insert multiple icons (e.g., /image, icon) into a paragraph.
- Place the cursor before the first icon.
- Press the right arrow key, and notice that the selection jumps to the second paragraph, skipping over the icons.

ISSUE 2:

- Create three paragraphs.
- Insert icons into the second paragraph.
- Place the cursor in the first or third paragraph and press the up/down arrow key it skips the second paragraph.
- Set up following HTML:
```html
<p><br></p>
<p><br><span class="fa fa-glass"></span>[]</p>
```
- Press arrow up key.
- Cursor will move to the first paragraph.

### Description of the issue/feature this PR addresses:

- Pressing arrow key (left or right) caused the cursor to consecutively skip over all icons until a text node was reached.
- Pressing up/down arrow keys would skip sibling block containing only icons.
- Pressing the up/down arrow keys would skip over icons in the same block if the cursor is on a `<br>`.

### Desired behavior after PR is merged:

- Add extra `\uFEFF` before and after icons to prevent them from being skipped.

task-3045033

Forward-Port-Of: odoo/odoo#179848

_compute_current_session tried to filter `session_ids` to retrieve session states, but in databases with a large number of sessions, this caused excessive memory usage and a potential `MemoryError`. ``` select count(*) from pos_session +---------+ | count | |---------| | 3582911 | +---------+x` ``` opw-4544050 upg-2459515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202244

_compute_current_session tried to filter `session_ids` to retrieve session
 states,  but in databases with a large number of sessions, this caused
 excessive memory usage and a potential `MemoryError`.

```
select count(*) from pos_session
+---------+
| count   |
|---------|
| 3582911 |
+---------+x`
```

opw-4544050
upg-2459515


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

Forward-Port-Of: odoo/odoo#202244

When importing a CSV referencing a related record, an error occurs if the system attempts to create a missing record, and the exception message is incorrectly translated. **Steps to reproduce:** - Install the `l10n_ro` module. - Switch the user's language to **Romania**. - Import [this](https://drive.google.com/file/d/1D5OZGeCICaySijNVxhSeopru--1iwU96/view?usp=sharing) CSV file into the Journal model (`account.journal`). - Click `Test` button, select `"Creează valori noi"` for `Default Ac

When importing a CSV referencing a related record, an error occurs if the system attempts to create a missing record, and the exception message is incorrectly translated.

**Steps to reproduce:**
- Install the `l10n_ro` module.
- Switch the user's language to **Romania**.
- Import [this](https://drive.google.com/file/d/1D5OZGeCICaySijNVxhSeopru--1iwU96/view?usp=sharing) CSV file into the Journal model (`account.journal`).
- Click `Test` button, select `"Creează valori noi"` for `Default Account`, and click again.
- Observe the error.

**Error:**
`ValueError: unsupported format character ''' (0x27) at index 74`

The Romanian translation contains an incorrect use of `'%%' (câmp)` leads to formatting issues - [1]; 
the correct placeholder `'%%(field)s'` should be used to match the original message format.

This commit corrects the Romanian translation to properly format the field name.

[1] - https://github.com/odoo/odoo/blob/4bdbe64928259ddffc93f9c0e60113fc1673e203/odoo/addons/base/i18n/ro.po#L21877

Sentry - 6494943085

Forward-Port-Of: odoo/odoo#204580

- adding a field to set the coretax UoM code from UoM form view - raise error when country is not set on the customer - use the main customer's address in invoice as address in e-Faktur instead of the main customer's - fix calculation for tax incde in price configuration - adding CustomDocMonthYear to the XML by parsing month and year from invoice_date ticket-4622364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#20

- adding a field to set the coretax UoM code from UoM form view
- raise error when country is not set on the customer
- use the main customer's address in invoice as address in e-Faktur instead of the main customer's
- fix calculation for tax incde in price configuration
- adding CustomDocMonthYear to the XML by parsing month and year from invoice_date

ticket-4622364

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

Forward-Port-Of: odoo/odoo#204561
Forward-Port-Of: odoo/odoo#203203

This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715

This fix aims to increase the operation timeout
to reduce the risk of timeouts when sending documents.

If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service.

opw-4608647

Forward-Port-Of: odoo/enterprise#82715

Before this commit, the `Europe/Brussels` timezone was applied 2 times on the calculation of the end_datetime when the slot is linked to a template and so the end date time of the slot could suddenly be before the start date time, which should not be possible. The timezone is applied 2 times, because the start date time computed already got the right timezone, so it is not needed to apply again the timezone since the timezone is already defined thanks to the start date time used in the co

Before this commit, the `Europe/Brussels` timezone was applied 2 times
on the calculation of the end_datetime when the slot is linked to a
template and so the end date time of the slot could suddenly be before
the start date time, which should not be possible. The timezone is
applied 2 times, because the start date time computed already got the
right timezone, so it is not needed to apply again the timezone since
the timezone is already defined thanks to the start date time used in
the computation.

This commit makes sure the timezone is applied once during the calculation of the end datetime, to be sure the difference between UTC and the timezone to apply is not applied 2 times on the end date time.

runbot-error-162055

Forward-Port-Of: odoo/enterprise#82529

Currently inter-company kit transactions aren't working: 1) Selling a kit product to another internal company (intercompany) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine`: Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit pro

Currently inter-company kit transactions aren't working:
1) Selling a kit product to another internal company
(intercompany) and validating the delivery will not update the
`qty_delivered` field on the corresponding `SaleOrderLine`:

Currently the filters to capture moves which informs the
delivered quantity of the line do not account for moves with
`location_dest_id` pointing to the inter-company transit
location (which should count towards the delivered value)

2) Receiving a kit product via intercompany will result in an
inaccurate update on the `qty_received` field on the
corresponding `PurchaseOrderLine`:

Tests added here due to inter-company rule modules being
enterprise only.

opw-4267210

Forward-Port-Of: odoo/enterprise#82542
Forward-Port-Of: odoo/enterprise#78170

Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Community PR: https://github.com/odoo/odoo/pull/188860 Forward-Port-Of: odoo/enterprise

Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart).

This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items.

opw-4378554

Community PR: https://github.com/odoo/odoo/pull/188860

Forward-Port-Of: odoo/enterprise#77741

This commit is the counterpart of odoo/odoo#204833 which ignores the `t-translation` attributes in view compilers. As a consequence, this directive should no longer be in the list of accepted directives. Forward-Port-Of: odoo/enterprise#82898

This commit is the counterpart of odoo/odoo#204833 which ignores the `t-translation` attributes in view compilers. As a consequence, this directive should no longer be in the list of accepted directives.

Forward-Port-Of: odoo/enterprise#82898

According to the DATEV Format documentation, the VAT needs to be split into two columns instead of one. The first column being the country code (ISO 3166), and the second one being the remaining numbers. task-4600047 runbot : https://runbot.odoo.com/runbot/bundle/16-0-datev-export-roto-352476 Forward-Port-Of: odoo/enterprise#82104 Forward-Port-Of: odoo/enterprise#80843

According to the DATEV Format documentation, the VAT needs to be split into two columns instead of one. The first column being the country code (ISO 3166), and the second one being the remaining numbers.

task-4600047

runbot : https://runbot.odoo.com/runbot/bundle/16-0-datev-export-roto-352476

Forward-Port-Of: odoo/enterprise#82104
Forward-Port-Of: odoo/enterprise#80843

Steps to Produce: - Generate offer contract from recruitment. - Sign the contract and submit it. - Open an existing offer and click on the stat button. issue: - stat button opens new contract from view as employee contract is False. Fix: - return applicant's newly created contract to the stat button. task-4610751 Forward-Port-Of: odoo/enterprise#80943

Steps to Produce:
- Generate offer contract from recruitment.
- Sign the contract and submit it.
- Open an existing offer and click on the stat button.

issue:
- stat button opens new contract from view as employee contract is False.

Fix:
- return applicant's newly created contract to the stat button.

task-4610751

Forward-Port-Of: odoo/enterprise#80943