Steps: - Install Ecommerce - Add some products to the cart - Remove them using the 'remove' option - Go to my/orders - select any order, then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog Issue: - By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty Cause: - Cart quantity does not update when the last product is removed Fix: - While removing the last product, set cart quantity in

Steps:
- Install Ecommerce
- Add some products to the cart
- Remove them using the 'remove' option
- Go to my/orders
- select any order, then click on Order again
- Click on the Add To Cart button
- You'll see one confirmation dialog

Issue:
- By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty

Cause:
- Cart quantity does not update when the last product is removed

Fix:
- While removing the last product, set cart quantity in sessionstorage to ensure that the last removal is recorded

affected version-17.0
opw-4566505

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

Forward-Port-Of: odoo/odoo#202363
Forward-Port-Of: odoo/odoo#199921

When self ordering is setup with pay after meal, and two users scans the same table. The order is now shared between the two users. taskId: 4489980 Forward-Port-Of: odoo/odoo#197569

When self ordering is setup with pay after meal, and two users scans the same table. The order is now shared between the two users.

taskId: 4489980

Forward-Port-Of: odoo/odoo#197569

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`). Channels should only be added explictly when a channe

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing.

Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`).

Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior.

This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue.

fixes runbot-106895

[1]: https://github.com/odoo/odoo/pull/174473

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#202278
Forward-Port-Of: odoo/odoo#202009

In this commit- We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614) ```py Please indicate why the always invisible fields are present in the view, or remove the field tag. Addon: 'l10n_in_withholding' View: tds_entry_view_form Fields: <field name="currency_id" column_invisible="True"/> ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202015

In this commit-
We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614)
```py
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_in_withholding'
   View: tds_entry_view_form
      Fields:
         <field name="currency_id" column_invisible="True"/>
```



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

Forward-Port-Of: odoo/odoo#202015

Description of the issue/feature this PR addresses: This adds 13% tax logic to Estonia Localization. 13% is valid from 01.01.2025 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#198347

Description of the issue/feature this PR addresses:
This adds 13% tax logic to Estonia Localization. 13% is valid from 01.01.2025
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#198347

Scenario: - create a redirect 308 from route with a sitemap method (eg. /website/version) - go to /sitemap.xml (you might need to delete sitemap in attachment before) Result: you get a 500 error, with this traceback in server logs: ``` … File "/Users/odoo/src/odoo/17.0/addons/website/models/website.py", line 1333, in _enumerate_pages if rule.endpoint.func.__func__ in sitemap_endpoint_done: AttributeError: 'functools.partial' object has no attribute '__func__'. Did you mean: '__d

Scenario:

- create a redirect 308 from route with a sitemap method
(eg.  /website/version)
- go to /sitemap.xml (you might need to delete sitemap in attachment
before)

Result: you get a 500 error, with this traceback in server logs:

```
…
File "/Users/odoo/src/odoo/17.0/addons/website/models/website.py", line 1333, in _enumerate_pages
if rule.endpoint.func.__func__ in sitemap_endpoint_done:
AttributeError: 'functools.partial' object has no attribute '__func__'. Did you mean: '__doc__'?
```

Fix: take a second level of partial (from the redirection and not the
route) when handling duplicates routes.

opw-4594629
opw-4614216
opw-4628703

Forward-Port-Of: odoo/odoo#202280
Forward-Port-Of: odoo/odoo#200979

Currently when invoicing a SO which has a downpayment made in Pos this downpayment is not reflected in the wizard. Steps to reproduce: ------------------- * Create an SO * Open pos session and make a downpayment for the SO * Close register * Go back to the SO * Deliver the items * Select the invoice > Observation: Amount already invoiced is at 0 Why the fix: ------------ There was a previous fix at the same place previously: https://github.com/odoo/odoo/commit/f613b87c38d208730ba

Currently when invoicing a SO which has a downpayment made in Pos this downpayment is not reflected in the wizard.

Steps to reproduce:
-------------------
* Create an SO
* Open pos session and make a downpayment for the SO
* Close register
* Go back to the SO
* Deliver the items
* Select the invoice
> Observation: Amount already invoiced is at 0

Why the fix:
------------
There was a previous fix at the same place previously: https://github.com/odoo/odoo/commit/f613b87c38d208730ba2470e0a26a110c2089b66

However the wizard had changed and instead of showing `amount_to_invoice` we now show `amount_invoiced`

opw-4585413

Forward-Port-Of: odoo/odoo#198740

Before this commit, the interface was always shown in the default language. This fix ensures that the UI is displayed according to the user’s selected language. task-4609518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201799

Before this commit, the interface was always shown in the default language. This fix ensures that the UI is displayed according to the user’s selected language.

task-4609518





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

Forward-Port-Of: odoo/odoo#201799

Steps to reproduce the bug: - Create a storage “P1”: - UoM: Kg - Create a storable “Kit 1”: - UoM: unit - BoM: - 1 Kg of P1 - Create a delivery order for 1 unit of Kit 1 - Mark it as to do - Set the quantity of P1 to 1kg - try to print Problem: A traceback is triggered because we try to convert 1kg to unit: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: L'unité de mesure kg définie sur la ligne de commande

Steps to reproduce the bug:
- Create a storage “P1”:
    - UoM: Kg

- Create a storable “Kit 1”:
    - UoM: unit
    - BoM:
        - 1 Kg of P1

- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print

Problem:
A traceback is triggered because we try to convert 1kg to unit:

```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the
template
UserError: L'unité de mesure kg définie sur la ligne de commande
n'appartient pas à la même catégorie que l'unité de mesure unités
définie sur le produit. Veuillez corriger l'unité de mesure définie
sur la ligne de commande ou sur le produit, elles doivent appartenir à
la même catégorie.
Template: stock.stock_report_delivery_has_serial_move_line
```

opw-4619140

Forward-Port-Of: odoo/odoo#201580

Steps to reproduce: - Create a Product with an attribute that 'Never' create variants, with two attributes - Create a Bom for that product that has: - 2 components, one restricted to the first variant - 2 operations, one restricted to the first variant - 2 byproducts, one restricted to the first variant - Set that product to MTO/Manufacture - Create a sale order for that product, and pick the first variant - Confirm the sale order and check the linked MO. Issue: Both the operat

Steps to reproduce:
- Create a Product with an attribute that 'Never' create variants, with two attributes
- Create a Bom for that product that has:
  - 2 components, one restricted to the first variant
  - 2 operations, one restricted to the first variant
  - 2 byproducts, one restricted to the first variant
- Set that product to MTO/Manufacture
- Create a sale order for that product, and pick the first variant
- Confirm the sale order and check the linked MO.

Issue:
Both the operation and byproduct set for that specific variant won't be in the Manufacturing Order, despite the variant-specific component being properly added.

Since the requirements to skip the bom/operation/byproduct line is the same, regardless of the model, extract it and use it in the three `_skip` methods so we handle it in each case.

opw-4636956

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

Forward-Port-Of: odoo/odoo#201549

Add `_mailing_enabled` flag on `pos.order` model to enable sending it. taskId: 4564577 Forward-Port-Of: odoo/odoo#197498

Add `_mailing_enabled` flag on `pos.order` model to enable sending it.

taskId: 4564577

Forward-Port-Of: odoo/odoo#197498

In this commit: https://github.com/odoo/odoo/pull/192733/commits/ca9c9b319a7b653f7e17a7de1789081694bbd9d7 We introduced the issues data in the additional document reference. That broke that rule https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-112/ no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202359

In this commit: https://github.com/odoo/odoo/pull/192733/commits/ca9c9b319a7b653f7e17a7de1789081694bbd9d7 We introduced the issues data in the additional document reference. That broke that rule https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-112/

no task id




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

Forward-Port-Of: odoo/odoo#202359

Task: [4591489](https://www.odoo.com/odoo/49/tasks/4591489) Description of the issue/feature this PR addresses: The reference and company name in the header of Traceability Report are currently overlapping a bit. This PR increases the spacing of elements, to resolve the issue. Current behavior before PR: The formatting of the Traceability Report's header is incorrect, reference and company name are overlapping: ![Screenshot from 2025-03-13 13-28-16](https://github.com/user-attachments

Task: [4591489](https://www.odoo.com/odoo/49/tasks/4591489)

Description of the issue/feature this PR addresses:
The reference and company name in the header of Traceability Report are currently overlapping a bit. This PR increases the spacing of elements, to resolve the issue.

Current behavior before PR:
The formatting of the Traceability Report's header is incorrect, reference and company name are overlapping:

![Screenshot from 2025-03-13 13-28-16](https://github.com/user-attachments/assets/d9f3710c-1555-4fc1-9bc6-2c10a19b05e6)

Desired behavior after PR is merged:
The Traceability Report's header is displayed properly:

![Screenshot from 2025-03-13 13-28-53](https://github.com/user-attachments/assets/f1286512-af3b-418d-adc9-4c9b3136a044)


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

Forward-Port-Of: odoo/odoo#201564

…versalCommunication Our facturx XML are not correct, they are raising "/rsm:CrossIndustryInvoice[1]/rsm:SupplyChainTradeTransaction[1] /ram:ApplicableHeaderTradeAgreement[1]/ram:BuyerTradeParty[1]/ ram:DefinedTradeContact[1]/ram:EmailURIUniversalCommunication[1]/ram:URIID[1]" "Attribute @schemeID' marked as not used in the given context." errors (for both `BuyerTradeParty`and `SellerTradeParty`). Which in other words means the parameter `@shemeID` should not be there in the tag EmailURIU

…versalCommunication

Our facturx XML are not correct, they are raising
"/rsm:CrossIndustryInvoice[1]/rsm:SupplyChainTradeTransaction[1] /ram:ApplicableHeaderTradeAgreement[1]/ram:BuyerTradeParty[1]/ ram:DefinedTradeContact[1]/ram:EmailURIUniversalCommunication[1]/ram:URIID[1]" "Attribute @schemeID' marked as not used in the given context." errors (for both `BuyerTradeParty`and `SellerTradeParty`).

Which in other words means the parameter `@shemeID` should not be there in the tag EmailURIUniversalCommunication.

### Before
![image](https://github.com/user-attachments/assets/e8ac837f-ab54-4b45-95a0-ba5ae1f1a668)

### After
![image](https://github.com/user-attachments/assets/2f72c1a9-6e5f-4aa9-9ef8-90864826d37f)

Tested on Ecosio with ZUGFeRD 2.3.2 EXTENDED, that is the same as FacturX 1.07.2.

opw-4571664

Forward-Port-Of: odoo/odoo#202130
Forward-Port-Of: odoo/odoo#201623

The live chat module the chat hub inside its shadow root. Do avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: https://github.com/odoo/odoo/pull

The live chat module the chat hub inside its shadow root. Do avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed.

This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry.

[1]: https://github.com/odoo/odoo/pull/201771

Forward-Port-Of: odoo/odoo#202329

The field attribute `company_dependent` is not passed when instanciating manual fields so they do not get created as jsonb columns and lose the company dependent property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200509

The field attribute `company_dependent` is not passed when instanciating manual fields so they do not get created as jsonb columns and lose the company dependent property.




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

Forward-Port-Of: odoo/odoo#200509

Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202276 Forward-

Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column.

Fix this by creating `groupby_terms` with `groupby` instead of values from the dict.

Forward-Port-Of: odoo/odoo#202276
Forward-Port-Of: odoo/odoo#202115

Issue ----- When the user clicks on "Continue Shopping" without providing a value for the selected variant, they get a Traceback. Steps to reproduce ----- - Install the ECommerce app - Create an "Att" attribute - Set its' Display Type to "Select" - Add 2 values, 1 & 2 - Set value 1 to Free text - Create a new product "Trace" - Add "Att" as an attribute with values 1 & 2 - Go to the Website - Open the Shop page - Edit the page to add the cart button to pro

Issue
-----
When the user clicks on "Continue Shopping" without providing a value for the
selected variant, they get a Traceback.

Steps to reproduce
-----
- Install the ECommerce app
- Create an "Att" attribute
    - Set its' Display Type to "Select"
    - Add 2 values, 1 & 2
        - Set value 1 to Free text
- Create a new product "Trace"
    - Add "Att" as an attribute with values 1 & 2
- Go to the Website
- Open the Shop page
    - Edit the page to add the cart button to products & Save
- Click on the cart button of the "Trace" product
- Select the 1 variant
- Click the "Continue Shopping" button without entering a custom value

-> Traceback

Cause
-----
In website_sale_product_configurator, we append to the attribute array even when
there is no custom value provided by the user. When the Python code tries to
access the value, it creates an error because there is no 'custom_value' key.

Solution
-----
Only search for a product template attribute variant when a value is provided.

-----
Ticket:
opw-4535469

Forward-Port-Of: odoo/odoo#201944
Forward-Port-Of: odoo/odoo#197657

**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202157 Forward-Port-Of: odoo/odoo#179345

**Current behavior before PR:**

prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload.


**Desired behavior after PR is merged:**

this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload.

task-4161477

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

Forward-Port-Of: odoo/odoo#202157
Forward-Port-Of: odoo/odoo#179345

Having a record with set res_id but no res_model doesn't mean much, but we can consider, in web_read, that it means that there is no related record to avoid crashes. opw-4527152 Forward-Port-Of: odoo/odoo#201779

Having a record with set res_id but no res_model doesn't mean much, but we can consider, in web_read, that it means that there is no related record to avoid crashes.

opw-4527152

Forward-Port-Of: odoo/odoo#201779

Partial fix of changes applied in: https://github.com/odoo/enterprise/pull/78465 rb-145524 rb-145525 Forward-Port-Of: odoo/enterprise#81753

Partial fix of changes applied in:
https://github.com/odoo/enterprise/pull/78465

rb-145524
rb-145525

Forward-Port-Of: odoo/enterprise#81753

This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice. The calculated taxes will never change the order total. NFC-e mandates taxes to always be included in the price so we don't need any additional RPC call before payment. One way of achieving this was through l10n_br_edi, forcing every pos.order to be invoiced and then following the implemented flows on account.move

This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice.

The calculated taxes will never change the order total. NFC-e mandates taxes to always be included in the price so we don't need any additional RPC call before payment.

One way of achieving this was through l10n_br_edi, forcing every pos.order to be invoiced and then following the implemented flows on account.move. We decided against it because:

- It leads to a large amount of mostly unnecessary invoices,
- It's conceptually strange to the user, NFC-e "invoices" resemble POS receipts more than they do invoices,
- The flow in the POS is simpler, we handle tax calculation and EDI in one atomic step.

We therefore chose to re-implement EDI for pos.order. The downside of this approach is that we temporarily need to copy some code from l10n_br_edi. In master this code can be consolidated in a common mixin.

The integration tries to never block POS sales. You're allowed to retry EDI later. When EDI fails, the POS user is informed and we fall back to the standard receipt (marked as a "receipt without fiscal value").

For refunds we still go through account.move, as NFC-e doesn't support refunds (must be NF-e, which is what we already support for account.move).

task-3564171

Forward-Port-Of: odoo/enterprise#77206

Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with u

Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount.

To reproduce:

1. Configure Avatax
2. Configure the Discount product to have the "Non-taxable product" Avatax category
2. Create an invoice to Azure Interior
3. Select the Avatax fiscal position
3. Add 1 FURN_6667 with default unit price $295
4. Add 1 Discount with unit price -$295
5. Click "Compute Taxes"

The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items.

`_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line.

This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded.

opw-4493544

## PR note
Alternative to https://github.com/odoo/enterprise/pull/80095.

Forward-Port-Of: odoo/enterprise#80097

### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast. ### Steps to reproduce: - Create a storable product that can be rented put 100 units in stock. - Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week. - Create a rental order for 5 units of that product for a period ulterior to the deliv

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81532
Forward-Port-Of: odoo/enterprise#81127

Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name. Forward-Port-Of: odoo/enterprise#81335

Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name.

Forward-Port-Of: odoo/enterprise#81335

### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:

### Issue:

You can not print label for an mo is the qty_producing is at 0.

### Steps to reproduce:

- Create a storable product FP tracked by LOT.
- Create a bom for that product with 1 operation containing an instruction of type: "print label"
- Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0).
- Process the operation in the shopfloor and print label
#### > The printed label is empty.

### Cause of the issue:

The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced.
https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332

opw-4583573

Forward-Port-Of: odoo/enterprise#81285
Forward-Port-Of: odoo/enterprise#80802

Description of the issue this commit addresses: A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format. --- Steps to reproduce: 1. Install l10n_be_coda 2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket. 3. A traceback is raised --- Desired behavior after this commit is merged: The file import doesn't rai

Description of the issue this commit addresses:

A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format.

---

Steps to reproduce:

1. Install l10n_be_coda
2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket.
3. A traceback is raised

---

Desired behavior after this commit is merged:

The file import doesn't raise a traceback.

---

Note on the fix:

The issue happened because in `_get_coda_file_statement()`, the date is expected to be on the index range 115-120 but the the decoding of the file in `_parse_bank_statement_file()` transformed a "€" in "Ôé¼" which moved the date to indexes 117-122. This wrong translation of encoding happened because cp850 was used - which doesn't support currency symbols - instead of utf_8 because the latter was stopped by a non matching regex that was missing the currency symbols.

This commits includes currency symbols in the validating regex so that the most appropriate encoding is validated as often as possible.

---

opw-4546281

Forward-Port-Of: odoo/enterprise#81329

**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad

**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.

Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.

As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.

- How to reproduce:
    * Assign one pos config to preparation display
    * Archive the assigned config
    * Open another pos config.
    * Kitchen display is not loaded

**Solution**:
Change the domain to include displays with no configs, or with no active config.

opw-4504623

Forward-Port-Of: odoo/enterprise#81683
Forward-Port-Of: odoo/enterprise#80117

- Sign > Documents > Click on any of the Kanban record - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading. Now, { id, token, create_uid, state,

- Sign > Documents > Click on any of the Kanban record
- Reload the view (either reload the browser, or activate 
the debug, or change to dark mode on the user menu).

Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires  attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading.

Now, { id, token, create_uid, state, request_item_states} is put in the query string of the URL, in that way, when reloading, the client action 'sign.Document' will have the needed attributes. Note that, this is also the behavior of the base_import 'ImportAction' action [1].

task-4391729

[1] : https://github.com/odoo/odoo/pull/182744/commits/a6801ce4aa65cd023e2a762ab5c42755a4599c95

Forward-Port-Of: odoo/enterprise#77399

Previously, the file viewer was misaligned when scrolling horizontally, causing incorrect placement. This fix ensures that the file viewer remains properly positioned, even when scrolling, for a consistent viewing experience. Task-4531591 Forward-Port-Of: odoo/enterprise#79242

Previously, the file viewer was misaligned when scrolling horizontally,
causing incorrect placement.
This fix ensures that the file viewer remains properly positioned,
even when scrolling, for a consistent viewing experience.

Task-4531591

Forward-Port-Of: odoo/enterprise#79242