Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/enterprise#68015

Steps to reproduce:
- Install Sign
- Open Sign, add a document and put a signature box
- Make the sign box have a weird aspect ratio (very short and super wide for example)

Issues:
When you sign with the frame, the frame will be partially hidden making the hash invisible.

Solution:
Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously.

opw-4042289

Forward-Port-Of: odoo/enterprise#68015

**Current behavior:** When a kit bom product move line is broken down into move lines for its component products, changes written to the move line (not on the move) will not carry over to the new move nor move lines. **Expected behavior:** The change should be observed beyond the decomposition. **Steps to reproduce:** 1. Create a new internal transfer in barcode 2. Add a product with some bom via form, also edit the destination location in the form to be something non-

**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.

**Expected behavior:**
The change should be observed beyond the decomposition.

**Steps to reproduce:**
1. Create a new internal transfer in barcode

2. Add a product with some bom via form, also edit the
     destination location in the form to be something
     non-default.

3. Save the form, validate the transfer

4. See that the broken down move lines don't keep the changed
     destination location

**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.

**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.

opw-4016702

Forward-Port-Of: odoo/enterprise#66746

Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial

Steps to reproduce:
[l10n_ec]
- Create a credit note from the Bill journal
- Set a foreign customer
- Set a customized document number

Issue:
An error will be raised saying that the format is not correct

But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format."

Solution:
When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify
certain conditions to bypass the document check/formatting for localisations.

We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test

opw-3993305

Forward-Port-Of: odoo/enterprise#67589

Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#54351 Forward-Port-Of: odoo/enterprise#52999

Manual Fowardport

latam task 1097

Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754
Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967

Forward-Port-Of: odoo/enterprise#54351
Forward-Port-Of: odoo/enterprise#52999

Steps to reproduce: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3) Create customer electronic invoice and confirm. If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice then it will be raised the error message and this text "Please report this error to your Odoo provider" (but this text is

Steps to reproduce:

1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing).

2) Take position on Argentinian company (AR) (Responsable Inscripto) .

3) Create customer electronic invoice and confirm. If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice then it will be raised the error message and this text "Please report this error to your Odoo provider" (but this text is not suitable because the odoo provider can`t solve the error. The webservice is not available).

Current behavior:

If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text "Please report this error to your Odoo provider".

Expected behavior:

If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text 'The AFIP electronic billing webservice is not available. Wait a few minutes for it to reset and try to validate the action again.'.

Task Adhoc: 37771

Forward-Port-Of: odoo/enterprise#67566
Forward-Port-Of: odoo/enterprise#59983

Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries. ### Steps to reproduce: - Enable Multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable delivery in 2 steps - Create a storable product and put 1 unit in stock - Create and confirm an SO for 1 unit - Click on the chart icon next to the delivered qty #### > the reserved qty is 0 + "No future availability" even though 1

Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries.

### Steps to reproduce:

- Enable Multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Enable delivery in 2 steps
- Create a storable product and put 1 unit in stock
- Create and confirm an SO for 1 unit
- Click on the chart icon next to the delivered qty

#### > the reserved qty is 0 + "No future availability" even though 1 unit is reserved from stock

### Cause of the issue:

The reserved qty displayed on the next to the delivered qty on the SOL is the `qty_available_today` computed field of the SOL model. This field is computed by summing the qties of the stock moves linked to the SOL: https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L69 https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L80-L81

However, when you are not delivering in 1 step, the only delivery move linked to the SOL will be the move which destination is the customer location. To be more precise, confirming the SO in a delivery in two steps a stock move from the Output to the customer will be created and linked to the SOL. During the action confirm of this move a procurement will be run to generate a move from stock to the Output but the SOL will not be referenced anymore so that the SOL will not be linked to it.

### Note:

The behavior is different in saas-17.2 where each of the delivering move is linked to the SOL so that the probably need to be adapted.

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

Forward-Port-Of: odoo/odoo#176891
Forward-Port-Of: odoo/odoo#176756

Currently the amount due of a move was always sent in an email for any type of move. The condition only checked if there was an `invoice_date_due` set. This field is set for any kind of move and default to the creation date of that move. However it only makes sense to show amounts due for invoices, bills, receipts and credit notes. Showing these for miscellaneous moves like the tax closing entry causes users to be confused. The amount displayed is the total amount of the move and not the amou

Currently the amount due of a move was always sent in an email for any type of move. The condition only checked if there was an `invoice_date_due` set. This field is set for any kind of move and default to the creation date of that move.

However it only makes sense to show amounts due for invoices, bills, receipts and credit notes. Showing these for miscellaneous moves like the tax closing entry causes users to be confused. The amount displayed is the total amount of the move and not the amount to be paid to the authorities.

This fix makes sure we only show the amount due in emails for the right move types in order not to confuse users.

Task link: https://www.odoo.com/odoo/project/967/tasks/4042715
opw-4042715

Forward-Port-Of: odoo/odoo#176172
Forward-Port-Of: odoo/odoo#174819

…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t

…number

Steps to reproduce:
[l10n_ec]
- Create a credit note from the Bill journal
- Set a foreign customer
- Set a customized document number

Issue:
An error will be raised saying that the format is not correct

But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format."

Solution:
When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations.

opw-3993305

Forward-Port-Of: odoo/odoo#177597
Forward-Port-Of: odoo/odoo#174950

Before this commit when being in a branches environment, creating an account group on the main company was not propagated to the account of the child companies opw: 4055582 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173634

Before this commit when being in a branches environment, creating an account group on the main company was not propagated to the account of the child companies

opw: 4055582




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

Forward-Port-Of: odoo/odoo#173634

This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account. - [FIX] website: always set the first carousel slide as the active one - [FIX] website: make the `Carousel` options atomic - [FIX] website: prevent recording sliding of some carousels in history - [FIX] website: add a tour to test the `Carousel` options task-3744613 related to opw-3675019 Forward-Po

This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account.
 
- [FIX] website: always set the first carousel slide as the active one
- [FIX] website: make the `Carousel` options atomic
- [FIX] website: prevent recording sliding of some carousels in history
- [FIX] website: add a tour to test the `Carousel` options

task-3744613
related to opw-3675019

Forward-Port-Of: odoo/odoo#173684
Forward-Port-Of: odoo/odoo#153892

Before this commit the tax grid of the tax was wrong. The value of this tax should be put in the total sales of goods and services in Field C in the tax report. link to documentation: https://skat.dk/erhverv/moms/moms-ved-handel-med-udlandet/moms-ved-handel-med-virksomheder/moms-ved-handel-med-lande-uden-for-eu/moms-ved-salg-af-varer-og-ydelser-i-lande-uden-for-eu task: 4132444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Before this commit the tax grid of the tax was wrong. The value of this tax
should be put in the total sales of goods and services in Field C in the tax
report.

link to documentation:
https://skat.dk/erhverv/moms/moms-ved-handel-med-udlandet/moms-ved-handel-med-virksomheder/moms-ved-handel-med-lande-uden-for-eu/moms-ved-salg-af-varer-og-ydelser-i-lande-uden-for-eu

task: 4132444




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

Forward-Port-Of: odoo/odoo#177566

When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string. When a node has no text, it is serialized as follows: `<node/>` But if it has an empty string, it has the following representation: `<node></node>` In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly i

When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string.

When a node has no text, it is serialized as follows:

`<node/>`

But if it has an empty string, it has the following representation:

`<node></node>`

In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly instead of parsing the result, the `remove_blank_text` option of the parser has no effect.

This causes existing tests to show some difference.

opw-3819667

Forward-Port-Of: odoo/odoo#178037
Forward-Port-Of: odoo/odoo#175867

**Current behavior:** When a kit bom product move line is broken down into move lines for its component products, changes written to the move line (not on the move) will not carry over to the new move nor move lines. **Expected behavior:** The change should be observed beyond the decomposition. **Steps to reproduce:** 1. Create a new internal transfer in barcode 2. Add a product with some bom via form, also edit the destination location in the form to be something non-

**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.

**Expected behavior:**
The change should be observed beyond the decomposition.

**Steps to reproduce:**
1. Create a new internal transfer in barcode

2. Add a product with some bom via form, also edit the
     destination location in the form to be something
     non-default.

3. Save the form, validate the transfer

4. See that the broken down move lines don't keep the changed
     destination location

**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.

**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.

opw-4016702

Forward-Port-Of: odoo/odoo#173347

When an editable content is dropped in the website form, the editable elements identification and adaptation happens on `start()` (async). In a normal user interaction context, the dropped content would be set as editable in time, but when doing automated testing, we need to make sure the dropped content has `[contenteditable=true]` before editing its content. Remark: This commit also removes the `_keydown()` test function from the tour (since it still uses the deprecated `execCommand

When an editable content is dropped in the website form, the editable
elements identification and adaptation happens on `start()` (async).

In a normal user interaction context, the dropped content would be set
as editable in time, but when doing automated testing, we need to make
sure the dropped content has `[contenteditable=true]` before editing
its content.

Remark: This commit also removes the `_keydown()` test function from
the tour (since it still uses the deprecated `execCommand()`) and
replaces it with a simple `run: "text ..."`.

runbot-64816

Forward-Port-Of: odoo/odoo#165361

### Description of the issue/feature this PR addresses: 1. Add validation to CI and NIE identification types. 2. Improve the RUT message to more clear message about the expected format. Before this change only RUT document type was validated. With this new change we are able to validate also NIE and CI Uruguayan document types ### Current behavior before PR: 1. Trying to set an invalid NIE to a contact, there is not warning for the user and we let the user to store the number. 2. R

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

1. Add validation to CI and NIE identification types.
2. Improve the RUT message to more clear message about the expected format.

Before this change only RUT document type was validated. With this new change we are able to validate also NIE and CI Uruguayan document types

### Current behavior before PR:

1. Trying to set an invalid NIE to a contact, there is not warning for the user and we let the user to store the number.
2. RUT: If we set an invalid number we receive the warning but the suggested format is not ok ![image](https://github.com/user-attachments/assets/a28ef04b-f5ff-42d7-b8ce-3d744175cf96)

### Desired behavior after PR is merged:

1. If invalid RUT: improve error message:  ![image](https://github.com/user-attachments/assets/3a3680ad-75b9-49b5-829c-b5df207890f7)

2. If we set an invalid NIE to a contact we receive message warning that is not a valid one ![image](https://github.com/user-attachments/assets/a03f46e1-519b-4679-9e06-e3b9de220065)


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

Forward-Port-Of: odoo/odoo#177118
Forward-Port-Of: odoo/odoo#173451

Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/odoo#175819

Steps to reproduce:
- Install Sign
- Open Sign, add a document and put a signature box
- Make the sign box have a weird aspect ratio (very short and super wide for example)

Issues:
When you sign with the frame, the frame will be partially hidden making the hash invisible.

Solution:
Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously.

opw-4042289

Forward-Port-Of: odoo/odoo#175819

__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to re

__Current behavior before commit:__
When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove.

__Description of the fix:__
Add the product name in the error message, so it's easy to identify which product to remove of the cart.
The warning method is linked to sale.order.line so we can access to the product directly.

__Steps to reproduce the issue:__
- add products to your cart
- remove one or many products of the stock
- try to validate your payment

opw-4016059 (upgrade issues)

Forward-Port-Of: odoo/odoo#177068
Forward-Port-Of: odoo/odoo#174615

Issue ---- The date fields in the activity view aren't displayed according to the language's date/time formats. Steps ----- - Go to Settings -> Translations -> Language. - Use a custom date & time format. - Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior). - Add an activity and set a due date. - The "Created" & "Due On" dates don't match your custom format. Cause ----- I

Issue
----

The date fields in the activity view aren't displayed according to the language's date/time formats.

Steps
-----

- Go to Settings -> Translations -> Language.
- Use a custom date & time format.
- Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior).
- Add an activity and set a due date.
- The "Created" & "Due On" dates don't match your custom format.

Cause
-----

In the activity component, the dates weren't formated according to the current language's date/time format but rather a hard-coded one.

opw-3929864

Forward-Port-Of: odoo/odoo#168074