**Steps to reproduce:** - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts - Create an EU contact with "/" or "NA" as VAT (e.g. a German contact with a full address) - Create an invoice: * Customer: [the created contact] * Product: [any] - Confirm the invoice - Process the electronic invoice - Check the generated electronic invoice **Issue:** When a customer has not VAT number, a special value is used in the XML (i.e

**Steps to reproduce:**
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts
- Create an EU contact with "/" or "NA" as VAT (e.g. a German contact with a full address)
- Create an invoice:
  * Customer: [the created contact]
  * Product: [any]
- Confirm the invoice
- Process the electronic invoice
- Check the generated electronic invoice

**Issue:**
When a customer has not VAT number, a special value is used in the XML (i.e. 0000000).
However, "/" and "NA" that are equivalent to an empty VAT, do not have the special value.
Instead, the "IdFiscaleIVA" section is empty in the XML.

**Cause:**
"/" and "NA" are handled as a normal VAT and are truncated because the 2 first characters are not digits.

opw-3889051



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

Forward-Port-Of: odoo/odoo#166404
Forward-Port-Of: odoo/odoo#166316

Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice. - go back to SO create another downpayment with 30% Solution: ========= Typically, when calculating the value of down-payment lines, we only consider sales order lines for products, not down-payment lines. This is because, accor

Issue:
    ======
   	Extra down-payment line is creating

    Steps to reproduce the issue:
    =============================
    - create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
    - go back to SO create another downpayment with 30%

    Solution:
    =========
	Typically, when calculating the value of down-payment lines,
	we only consider sales order lines for products, not down-payment lines.
	This is because, according to the Odoo workflow,
	down-payment lines are created based on product lines in the sales order,
	not on down-payment lines themselves. Therefore, I am filtering out those lines here.

    closes odoo/odoo#163699

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

**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD to have the mobile menu. - Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it. - Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken. This is due to the fact that the code handles

**[FIX] website: fix close offcanvas on page click**

Steps to reproduce the bug:

- In "Website" edtit mode.
- Drop some snippets.
- Select a Hamburger menu header template or resize the screen at MD to have the mobile menu.
- Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it.
- Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken.

This is due to the fact that the code handles the hint preview for the "Powerbox" considers that it must insert the hint in a "<div>" if it's empty. See the "_makeHint()" function in this commit [1].

In this commit, we fix this by preventing selection on the backdrop. There's probably a better way to fix it. But until the problem is solved more generally, we simply fix it in CSS for the "Backdrop".

[1]: https://github.com/odoo/odoo/commit/4600086e7a2831664cc104a143e1014870874427

task-3853573

-----------------------------

**[FIX] website: fix overlay header when mobile menu is open**

Steps to reproduce the bug:

- Open a page in Website edit mode.
- Click on the header.
- Select a red color for the background option of the header.
- Choose "Over The Content" for the "Header Position" option.
- Resize the screen to MD to have the mobile menu.
- Click on the "hamburger button".
=> Bug: The header is red instead of transparent.

The bug arises because since this commit [2], the transparent background
of the "Over The Content" header is removed when the mobile menu is
open.

[2]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510

task-3853573

Forward-Port-Of: odoo/odoo#162870

Before this commit, if a website had at least two languages and the copyright area was disabled, a redundant "Language Selector" button would appear. This is not necessary anymore since the "Language Selector" option is already included within the copyright options. Steps to reproduce: - Navigate to the website editor - In the "Theme" tab, click "Add a Language" to add another language - Type "French" or another language and install it - A language selector will appear in the copyrig

Before this commit, if a website had at least two languages and the
copyright area was disabled, a redundant "Language Selector" button
would appear. This is not necessary anymore since the "Language
Selector" option is already included within the copyright options.

Steps to reproduce:

- Navigate to the website editor
- In the "Theme" tab, click "Add a Language" to add another language
- Type "French" or another language and install it
- A language selector will appear in the copyright area
- Click on "or edit master"
- Click on the "copyright" area at the bottom of the page
- Disable the copyright switch button in the right panel
- A "Language Selector" will appear below the "Copyright" switch button
  -> redundant

For the same reason, the "None" option for the language selector in the
navbar has been removed. The new "Header" options include a "Show/Hide"
element specifically for the language selector.

This commit addresses these behaviours.

task-3576937

Forward-Port-Of: odoo/odoo#140441

opw-3904133 Forward-Port-Of: odoo/odoo#165801

opw-3904133

Forward-Port-Of: odoo/odoo#165801

Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject, mailing list, and choose any template that have some blocks - Go to design tab in editor and change any color or size of something - Click save and test sending the email - The email doesn't have the changes applied Origin of the issue: ==================== When first rendering , Css

Issue:
======
Email doesn't have applied design changes (format , color ..)

Steps to reproduce the issue:
=============================
- Go to Email marketing
- Create a new one
- Add a subject, mailing list, and choose any template that have some
  blocks
- Go to design tab in editor and change any color or size of something
- Click save and test sending the email
- The email doesn't have the changes applied

Origin of the issue:
====================
When first rendering , CssRules are calculated using the first version
of the template and styles. When we update the design so the css rules,
they are not applied in the inlineHtml since it uses the old cssRules.

Solution:
==========
We only use `_rulesCache` defined in `wysiwyg` and we already handle
everything in `toInline` from calculating the `cssRules` to saving them
in the cache, so we just pass `undefined` as cssRules and let it take
care of everything.

task-3289131

Forward-Port-Of: odoo/odoo#166340
Forward-Port-Of: odoo/odoo#153180

Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur 3815006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166339 Forward-Port-Of: odoo/odoo#163707

Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur

3815006

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

Forward-Port-Of: odoo/odoo#166339
Forward-Port-Of: odoo/odoo#163707

If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l

If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation.

This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes.

We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options:
- manually setting the NAV tax code on their Hungarian taxes
- reloading the CoA after installing l10n_hu_edi
- uninstalling l10n_hu_edi (if they don't want to use it)

opw-3912298

Forward-Port-Of: odoo/odoo#166043

Since [1], Werkzeug discards any remaining data in the read socket after sending the response. In the case of WebSocket connections, the socket is not closed, and data keeps coming. As a result, WebSocket connections to the threaded server hang indefinitely in this discarding phase and never reach the processing phase. Thus, frames sent to the server are never processed. To solve this issue, rfile and wfile are replaced by dummy byte streams to ensure that our socket remains intact.

Since [1], Werkzeug discards any remaining data in the read socket
after sending the response.

In the case of WebSocket connections, the socket is not closed, and
data keeps coming. As a result, WebSocket connections to the threaded
server hang indefinitely in this discarding phase and never reach the
processing phase. Thus, frames sent to the server are never processed.

To solve this issue, rfile and wfile are replaced by dummy byte
streams to ensure that our socket remains intact.

[1]: https://github.com/pallets/werkzeug/commit/4f7048e7a31752142f18eefeccd49acc42a89e31

Forward-Port-Of: odoo/odoo#166231

**Current behaviour before PR:** Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked. **Desired behaviour after PR:** There should be no traceback. This can be handled by returning the method if we don't find the closest table. task-3922517 --- I confirm I have signed the

**Current behaviour before PR:**

Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked.

**Desired behaviour after PR:**

There should be no traceback. This can be handled by returning the method if we don't find the closest table.

task-3922517




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

Forward-Port-Of: odoo/odoo#165234

Few improvements for commit [1]: \- Before [1], `_find_global_route`, was not supposed to create any route. Let's keep it like that \- `_find_global_route` is sometimes calls with an empty `self` \- The name of the copied route should not contain "(Copy)" \- When looking for a route, we should skip the `active` criteria [1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41 OPW-3889889 OPW-3888885 Forward-Port-Of: odoo/odoo#166372 Forward-Port-Of: odoo/odoo

Few improvements for commit [1]:
\- Before [1], `_find_global_route`, was not supposed to create any
route. Let's keep it like that
\- `_find_global_route` is sometimes calls with an empty `self`
\- The name of the copied route should not contain "(Copy)"
\- When looking for a route, we should skip the `active` criteria

[1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41

OPW-3889889
OPW-3888885

Forward-Port-Of: odoo/odoo#166372
Forward-Port-Of: odoo/odoo#165728

Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121 Forward-Port-Of: odoo/odoo#166240 Forward-Port-Of: odoo/odoo#166147

Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121

Forward-Port-Of: odoo/odoo#166240
Forward-Port-Of: odoo/odoo#166147

## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available. - Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping. ## Steps To Reproduce: - Install UPS US on your db and publish it. - unpublish the other shipping methods. - Go to /shop and purchase any product a

## Issue:

- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.

## Steps To Reproduce:

- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.

In an other scenario:

- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.

## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:

    `if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`

- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.

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

Forward-Port-Of: odoo/odoo#165832
Forward-Port-Of: odoo/odoo#161704

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

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

STEP TO REPRODUCE: -Add gif api key -Go to a channel and choose any gif to be favorite -Then go to favorites category and we will the gif has been duplicate although we only choose one REASON: because we use 'this.pushGif(gif);' 2 time first when loading favorites gif and second is open it 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 ww

STEP TO REPRODUCE:
-Add gif api key
-Go to a channel and choose any gif to be favorite -Then go to favorites category and we will the gif has been duplicate although we only choose one

REASON: because we use 'this.pushGif(gif);' 2 time first when loading favorites gif and second is open it

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

Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/enterprise/pull/60550 Forward-Port-Of: odoo/odoo#161881 Forward-Port-Of: odoo/odoo#161476

Check if the user selected the carrier for storable/consumable products before proceeding to payment.

opw-3810367

See also:

- https://github.com/odoo/enterprise/pull/60550

Forward-Port-Of: odoo/odoo#161881
Forward-Port-Of: odoo/odoo#161476

Steps to reproduce: - Create two warehouses A & B - Open the warehouse B form - Set warehouse A as resupply and save - Remove warehouse A as resupply and save - Set warehouse A as a resupply again and save Issue: Instead of unarchiving the existing resupply route, it created a new route instead, meaning we have now two resupply routes from the same warehouse to the same warehouse. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

Steps to reproduce:
- Create two warehouses A & B
- Open the warehouse B form
- Set warehouse A as resupply and save
- Remove warehouse A as resupply and save
- Set warehouse A as a resupply again and save

Issue:
Instead of unarchiving the existing resupply route, it created a new route instead, meaning we have now two resupply routes from the same warehouse to the same warehouse.

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

Forward-Port-Of: odoo/odoo#165859
Forward-Port-Of: odoo/odoo#165129

### Steps to reproduce: - Enable subcontracting in the settings - Create a finished product FP tracked by lot using the buy route - Create a component product CP tracked by unique serial numbers and using the routes: - Buy - Resupply Subcontractor on Order - Create a BOM for FP of type subcontracting and consuming 1 x CP - Create and confirm a purchase order for 2 x CP, assign serial numbers on the receipt, receive products and validate - Create and confirm a purchase order for your

### Steps to reproduce:

- Enable subcontracting in the settings
- Create a finished product FP tracked by lot using the buy route
- Create a component product CP tracked by unique serial numbers and using the routes:
	- Buy
	- Resupply Subcontractor on Order
- Create a BOM for FP of type subcontracting and consuming 1 x CP
- Create and confirm a purchase order for 2 x CP, assign serial numbers on the receipt, receive products and validate
- Create and confirm a purchase order for your subcontractor for 2 x FP
- Go to the resupply picking, assign the stock moves related to your components and validate
- Go to receipt

#### Two issues reported by the PO (mgm):

1) The subcontracting button is visible on the move even though no qty was delivered yet.
2) The `fa-list` button on the move redirects to stock move lines of the move rather than to the "action_show_details".

### Cause issue 1:

The `show_subcontracting_details_visible` computed field determine if the button should be visible. Prior to the `quantitypocalypse` this field relied on the `quantity_done` to determine if the button should appear:
https://github.com/odoo/odoo/blob/c68b17e944079f0718a1bef74b941dcb18b841e3/addons/mrp_subcontracting/models/stock_move.py#L30-L37
As this field does not exist in 17.0 anymore, the new condition relies on the `quantity` field:
https://github.com/odoo/odoo/blob/3dc2e25f30a411f49f895568b4689265152f153d/addons/mrp_subcontracting/models/stock_move.py#L30-L36
However, this field only represents the same thing as the quantity_done when the move is `picked`.

### Cause of issue 2:

The `fa-list` button referring to the `action_show_details` in 16.0:
https://github.com/odoo/odoo/blob/d1bdcde5160d1a320396f0703103a50e8636e96f/addons/stock/views/stock_picking_views.xml#L302-L303
(that is overriden in `mrp_subcontracting`) has been replaced in 17.0 on the `stock.picking` form view by the one2Many record stock.move widget:
https://github.com/odoo/odoo/blob/b4ae1ed7382dcb9c91c06ba0055974994dcdf54c/addons/stock/static/src/views/picking_form/stock_move_one2many.xml#L3-L8
see commit 4da8c6e for more details.

opw-3871634
---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#165757

When attempting to upload a vendor bill in the Vendor Bills journal, the onboarding popup is incorrectly displayed every time, regardless of existing bills. ### Steps to reproduce * Install `account_accountant`. * Ensure your company has some vendor bills. * On the accounting dashboard, click the 'Upload' button on the Vendor Bill journal. Expected result: the file selector should open directly. Actual result: the onboarding popup appears every time a bill upload is attempted. ###

When attempting to upload a vendor bill in the Vendor Bills journal, the onboarding popup is incorrectly displayed every time, regardless of existing bills.

### Steps to reproduce

* Install `account_accountant`.
* Ensure your company has some vendor bills.
* On the accounting dashboard, click the 'Upload' button on the Vendor Bill journal.

Expected result: the file selector should open directly. Actual result: the onboarding popup appears every time a bill upload is attempted.

### Cause

Previously, the method `_fill_dashboard_data_count` would count the entries in a journal and use this data to determine whether to display the onboarding popup. After commit
d29a622740f6c34d25c52add5367bfdf58bbaf49, this method was replaced by a direct SQL query, which fails to update the count in the dictionary that informs the popup display logic.

opw-3888114

Forward-Port-Of: odoo/odoo#164663

Steps to reproduce the bug: - Create a storable product “P1”: - Track by SN - Update the quantity with one unit and “SN1” - Create an internal transfer and while in draft state: - Add the product “P1” - Select “SN1” - Confirm the picking. Problem: The serial number is removed after the picking is confirmed. opw-3925784 Forward-Port-Of: odoo/odoo#165986

Steps to reproduce the bug:
- Create a storable product “P1”:
    - Track by SN
    - Update the quantity with one unit and “SN1”

- Create an internal transfer and while in draft state:
    - Add the product “P1”
    - Select “SN1”

- Confirm the picking.

Problem:
The serial number is removed after the picking is confirmed.

opw-3925784

Forward-Port-Of: odoo/odoo#165986

Steps to reproduce the issue: - Create a storable product "P1" with the following BoM: - Add any component. - Add a tracked byproduct by serial number. - Create a manufacturing order to produce one unit of P1. - Navigate to the byproduct and click to open move details. Problem: The lot_name is not displayed. Therefore, when the user clicks on "Import Serials/lots" to create a serial number (SN), the SN is not displayed because the field "show_lots_text" in the move is set to F

Steps to reproduce the issue:
- Create a storable product "P1" with the following BoM:
    - Add any component.
    - Add a tracked byproduct by serial number.

- Create a manufacturing order to produce one unit of P1.
- Navigate to the byproduct and click to open move details.

Problem:
The lot_name is not displayed. Therefore, when the user clicks on "Import Serials/lots" to create a serial number (SN), the SN is not displayed because the field "show_lots_text" in the move is set to False.

OPW-3925784

Forward-Port-Of: odoo/odoo#165758

In debug mode, the special locations and picking types are shown on the warehouse 'Technical Information' tab. All the values shown there are readonly, with the exception of the mrp-related fields. This was likely forgotten at the time, and can lead to misconfigurations, so we make it consistent with the other location and picking types introduced in stock and other modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1

In debug mode, the special locations and picking types are shown on the warehouse 'Technical Information' tab. All the values shown there are readonly, with the exception of the mrp-related fields. This was likely forgotten at the time, and can lead to misconfigurations, so we make it consistent with the other location and picking types introduced in stock and other modules.

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

Forward-Port-Of: odoo/odoo#164162

**Current behavior:** In some instances we will try to create a `stock.location` record from a `complete_name` field value (one such case is creating from import). When this happens, the creation will fail due to the not-null constraint on the `name` field in the table and display a SQL error in logs. **Expected behavior:** Use part of the complete_name as the name. **Steps to reproduce:** 1. Create an .xlsx document representing a Repair Order to be imported, such that the `

**Current behavior:**
In some instances we will try to create a `stock.location`
record from a `complete_name` field  value (one such case is
creating from import). When this happens, the creation will fail
due to the not-null constraint on the `name` field in the table
and display a SQL error in logs.

**Expected behavior:**
Use part of the complete_name as the name.

**Steps to reproduce:**
1. Create an .xlsx document representing a Repair Order to be
     imported, such that the `Location` cell value does not
     already exist in the database

2. Install the test-import-export module, go into the Repair app
     and from the favorites action button select import data

3. Upload the .xlsx file, press 'Test Import', select the
     'Create New' option for offending data points

4. Observe that the new Location can not be created, and in the
     console logs there is the output of the bad SQL query

**Cause of the issue:**
The `_rec_name` field for `stock.location` is `complete_name`,
however the `name` field as also a required field. When we
create the records in this flow, `_rec_name` is used to infer
which fields need to be included in the query. So `name` is
never added to the INSERT query and we end up violating the
not-null constraint on this column of the table (bad query).

**Fix:**
If there is no `name` in the create vals dict for the location
record, use the end segment of `complete_name`.

opw-3796010

Forward-Port-Of: odoo/odoo#166193
Forward-Port-Of: odoo/odoo#163298

Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The

Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference.

### Steps to Reproduce

1. Install `account_bank_statement_import_camt`.
2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests)

**Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`.

**Actual Result:** The imported statement's payment reference contains `/` instead.

### Cause

The system attempts to use `<AddtlNtryInf>` as a fallback for `payment_ref`. However, it looks in the wrong place. It searches inside `<TxDtls>`, whereas `<AddtlNtryInf>` is actually a child of `<Ntry>`.

opw-3878785

Forward-Port-Of: odoo/enterprise#62703

The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, whi

The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user.

As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots.

Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter.

This fix makes the parsing of the NumCta value more strict so it supports the above use cases.

In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case.

opw-3878763

Forward-Port-Of: odoo/enterprise#62920
Forward-Port-Of: odoo/enterprise#62113

Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348

Task-id: 3631712

Forward-Port-Of: odoo/enterprise#62751
Forward-Port-Of: odoo/enterprise#52348

Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore.

Steps to reproduce:
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349)
- Click on "Save"
- Select "BOE" for "Export To" option
- Export

Issue:
A traceback is raised:
"KeyError: 'res_id'"

Cause:
In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id".
It's not the case anymore.

Complement of https://github.com/odoo/enterprise/commit/e8d5582a773d7f31669fa8be576569681ed3f110

opw-3856749

Forward-Port-Of: odoo/enterprise#62841

In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164

In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field.

task-3901450

Forward-Port-Of: odoo/enterprise#62860
Forward-Port-Of: odoo/enterprise#62164

Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652

Before this commit:
Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`.

After this commit:
All the slashes are removed from reference_id.

opw-3853123

Forward-Port-Of: odoo/enterprise#60652

Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043

Before this commit:
request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data.

After this commit:
request timeout increased to 60 seconds.

opw-3890386

Forward-Port-Of: odoo/enterprise#62043

Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/odoo/pull/161476 Forward-Port-Of: odoo/enterprise#60744 Forward-Port-Of: odoo/enterprise#60550

Check if the user selected the carrier for storable/consumable products before proceeding to payment.

opw-3810367

See also:

- https://github.com/odoo/odoo/pull/161476

Forward-Port-Of: odoo/enterprise#60744
Forward-Port-Of: odoo/enterprise#60550

When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage

When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback.

Step to reproduce:
- Open helpdesk
- open the 'all tickets' menu
- open any ticket form
- set the team_id to false
- save changes or click anywhere else to leave the edit field => a traceback occurs

Source of the issue:
When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that.

Solution:
Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team.

version 16.0 - master
task - 3895303

Forward-Port-Of: odoo/enterprise#61563

The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded.

The tour is failing rarely and undeterministically. 
It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). 
We add a step to enforce that the request is made before the next step of the tour.
We also enforce that we don't do the last action before closing the tour.

In ulterior versions, the tour can be stuck when adding a product. 
Our guess is that the button is clicked before the page is fully loaded. 
The tour would then consider it did click the button, while the action didn't happen.

We add a check to wait for the page to be fully loaded before clicking.

Linked to runbot error 61458, 63532, 59031 (and happened before already).

Forward-Port-Of: odoo/enterprise#62873
Forward-Port-Of: odoo/enterprise#61964