This commit makes the same fix as [1] but it does t for kanban views instead of list views. We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0 [1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad [2]: opw-4370092 Task: opw-4370092 Forward-Port-Of: odoo/odoo#194859

This commit makes the same fix as [1] but it does t for kanban views instead of list views.

We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0

[1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad
[2]: opw-4370092

Task: opw-4370092

Forward-Port-Of: odoo/odoo#194859

Problem: When printing an invoice with l10n_cl installed, the tax total will display the lavel as 'VAT.' The user expects 'VAT' to be translated to maybe 'IVA.' It is hardcoded into the view, thus the .pot file needs to be updated. Note: Starting from v17, there are missing translations for strings "Net Amount", "Total", "Exempt Amount" in the .pot file for the view l10n_cl.tax_totals_widget. However, these are present for v16. Will probably need to modify the fw-ports to include these st

Problem: When printing an invoice with l10n_cl installed, the tax total will display the lavel as 'VAT.' The user expects 'VAT' to be translated to maybe 'IVA.' It is hardcoded into the view, thus the .pot file needs to be updated.

Note: Starting from v17, there are missing translations
for strings "Net Amount", "Total", "Exempt Amount" in the
.pot file for the view l10n_cl.tax_totals_widget. However,
these are present for v16. Will probably need to modify
the fw-ports to include these strings in the file.

Purpose: Updating the .pot file to include the hardcoded VAT string will ensure there are translations for that label.

Steps to Reproduce on Runbot:
1. Install l10n_cl and Accounting
2. Add Spanish as a language
3. Switch to the CL company
4. Create an invoice for a customer whose language is Spanish
5. Print the invoice and notice 'VAT' is not translated

opw-4383092




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

Forward-Port-Of: odoo/odoo#194800
Forward-Port-Of: odoo/odoo#190605

Fixes an issue with the xml file where the tax exchange rate node would be added before the payment terms node if both features are used, which render the xml wrong. Also add a sudo when getting the system param for the test url; as this shouldn't block a non administrator user from testing the feature. opw-4425472 opw-4505562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194971

Fixes an issue with the xml file where the tax
exchange rate node would be added before the
payment terms node if both features are used,
which render the xml wrong.

Also add a sudo when getting the system param
for the test url; as this shouldn't block a non
administrator user from testing the feature.

opw-4425472
opw-4505562

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

Forward-Port-Of: odoo/odoo#194971

Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now. 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#194943 Forward-Port-Of: odoo/odoo#194801

Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now.

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#194943
Forward-Port-Of: odoo/odoo#194801

Check commits for description. OPW: 4348541 Forward-Port-Of: odoo/odoo#194406 Forward-Port-Of: odoo/odoo#194203

Check commits for description.

OPW: 4348541

Forward-Port-Of: odoo/odoo#194406
Forward-Port-Of: odoo/odoo#194203

The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmet

The `amount_untaxed` field, which is tracked,
encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned,
the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise.

I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmetic and its limitations. So what I did is checking if the new value is different than the old one then update the field.

Steps to reproduce:
1. Create a PO
2. Add a product with price 261,462.02
3. Save
4. Change the expected arrival date
5. Save See the chatter.
take a loot at the chatter.
![image](https://github.com/user-attachments/assets/a19ce09a-f02a-45a7-a02a-d044a4c1cc40)

opw-4315116



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

Forward-Port-Of: odoo/odoo#193368

Before: The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term. For example The old value has the mapping: 'Draft': 'Brouillon' The new value contains the term: '<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>' Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'.

Before:
The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'. However, the translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the en_US value and is responsible for verifying translations afterward. However, it is problematic during upgrades because users cannot easily identify which records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below Translations can be inherited after `write` from old terms to new terms which share the very close text contents
1. when `write` in production mode, text contents for translation terms are more important than the HTML/XML structures of them, and the old term translations should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the text content
2. when `write` in upgrade time, the HTML/XML structure is more important than the text content, and the new term structure should be remained as much as possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may contain behavior relevant diff (e.g. `invisible`), even if text contents are not changed.
    * users have no idea which records' values are changed during upgrade and are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with the new source term, other attributes will be copied from the source term if available.

Forward-Port-Of: #194181

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

Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192246

Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error.

opw-4422730

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

Forward-Port-Of: odoo/odoo#192246

### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create an invoice for a Swiss partner - Send it - The QR code appears in the generated PDF ### Cause: The bank eligibility is not checked when printing the QR code. ### Solution: After a discussion with the PO (THB) the Qr codes should appear on all Swiss transaction. But if the fiscal country of the user's company is not Switzerland, it must still be printed if its bank account is eligible to receive payment

### Steps to reproduce:
- Install "l10n_ch" and switch to a Swiss company
- Create an invoice for a Swiss partner
- Send it
- The QR code appears in the generated PDF

### Cause:
The bank eligibility is not checked when printing the QR code.

### Solution:
After a discussion with the PO (THB) the Qr codes should appear on all Swiss transaction. But if the fiscal country of the user's company is not Switzerland, it must still be printed if its bank account is eligible to receive payments via QRcodes.

So the solution is to add a check if the fiscal_country is not Switzerland, then we check the account validity. A valid account is an IBAN account of this type CHXX 3000 0XXX XXXX with the number in the middle being between 30000 and 31999.

opw-4380520

Forward-Port-Of: odoo/odoo#194563
Forward-Port-Of: odoo/odoo#194421

Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it. runbot errors: 5759, 102534, 111418 Forward-Port-Of: odoo/odoo#194672 Forward-Port-Of: odoo/odoo#124584

Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it.

runbot errors: 5759, 102534, 111418

Forward-Port-Of: odoo/odoo#194672
Forward-Port-Of: odoo/odoo#124584

### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the is

### Steps to reproduce:

- Create a product tracked by LOT (not SN)
- Create a BOM for that product and a BOM line with a tracked product
- Put a an SN for your component in STOCK.
- Create an MO for 1 unit of your product and confirm.
> The SN should be set on your component line.
- Set an LOT on the finished product with the create option but without clicking on the [+]
#### > The quantity of the component line was updated to 0 and the SN of the comp was removed.

### Cause of the issue:

Changing the lot on the MO form will trigger the `_onchange_producing` which will in turn `_set_qty_producing`:
https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L797-L799 In case the product is tracked by SN this `_set_qty_producing` will set a qty_producing of 1 and the move raws will reserve a quantity accordingly but if the product is tracked by lot or not tracked at all the quantities of the move raw will just be adapted to match the `qty_producing` (that was at 0 from the start):
https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L1217-L1227

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

Forward-Port-Of: odoo/odoo#194847
Forward-Port-Of: odoo/odoo#192932

Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194432 For

Steps to reproduce:

1. Create two companies: Company A and Company B
2. Create a service product
3. Configure the product to be purchased on Company A and not on Company B
4. Create a sales order on Company B, while logged in Company A
5. Confirm the order

Expected result:

The service PO is created on Company B, even though it was configured not to.



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

Forward-Port-Of: odoo/odoo#194432
Forward-Port-Of: odoo/odoo#177659

Description of the issue this PR addresses: Pressing enter in the `s_popup` snippet after making it visible via the right panel would hide the popup. This occurred because the mutation observer detected changes which shows the modal and rolled them back during the `insertLineBreak` operation. This commit ensures that those mutations are not observed. task-4255083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194613

Description of the issue this PR addresses:

Pressing enter in the `s_popup` snippet after making it visible via the right panel would hide the popup. This occurred because the mutation observer detected changes which shows the modal and rolled them back during the `insertLineBreak` operation. This commit ensures that those mutations are not observed.

task-4255083

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

Forward-Port-Of: odoo/odoo#194613
Forward-Port-Of: odoo/odoo#191810

### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behav

### Description of the issue/feature this PR addresses:
When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes.

### Current behavior before PR:
The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior.

### Desired behavior after PR is merged:
The routes are now evaluated based on their sequence, ensuring that rules associated with routes of lower sequence are considered first.



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

Forward-Port-Of: odoo/odoo#194706
Forward-Port-Of: odoo/odoo#188846

**Problem**: When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - A

**Problem**:
When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root.

**Solution**:
Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`.

**Steps to Reproduce**:
1. Open an empty editor and add an image.
2. Delete the image using the toolbar delete button.
3. Inspect the DOM:
   - An empty `<p>` remains, and the selection is in the editor root.

opw-4472173

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

Forward-Port-Of: odoo/odoo#193396

In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility. 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#194789

In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility.

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

**Steps to reproduce:** - Install Accounting - Create a first tax: * Tax Name: Tax1 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax1 * Tax Group: Tax1 * Affect Base of Subsequent Taxes: [Checked] - Create a second tax: * Tax Name: Tax2 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax2 * Tax Group: Tax2 * Base Affected by Previous Taxes: [Not checked] - Crea

**Steps to reproduce:**
- Install Accounting
- Create a first tax:
  * Tax Name: Tax1
  * Tax Computation: Percentage of Price
  * Tax Type: Sales
  * Amount: 20%
  * Label on Invoices: Tax1
  * Tax Group: Tax1
  * Affect Base of Subsequent Taxes: [Checked]
- Create a second tax:
  * Tax Name: Tax2
  * Tax Computation: Percentage of Price
  * Tax Type: Sales
  * Amount: 20%
  * Label on Invoices: Tax2
  * Tax Group: Tax2
  * Base Affected by Previous Taxes: [Not checked]
- Create an invoice
- Add an invoice line
- Add Tax1
- Add Tax2

**Issue:**
Base amount of Tax2 is affected by Tax1 when it should not.

opw-4450494




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

Forward-Port-Of: odoo/odoo#193451

Partial revert of https://github.com/odoo/enterprise/pull/67111. Some users rely on the structure of the export format (column order). The order is most frequently code, then name. And code is a required field. Those reasons made us want to re-adapt the behavior. We also want the amounts to be formatted with thousands separator and to always have 2 decimals (even if .00) task-4399107 Forward-Port-Of: odoo/enterprise#77675 Forward-Port-Of: odoo/enterprise#75740

Partial revert of https://github.com/odoo/enterprise/pull/67111. Some users rely on the structure of the export format (column order). The order is most frequently code, then name. And code is a required field. Those reasons made us want to re-adapt the behavior.

We also want the amounts to be formatted with thousands separator and
to always have 2 decimals (even if .00)

task-4399107

Forward-Port-Of: odoo/enterprise#77675
Forward-Port-Of: odoo/enterprise#75740

The current auto-clean feature doesn't work properly and it deletes spreadsheet that shouldn't be deleted. 1) copy a spreadsheet and leave it (no update) 2) upload an XLSX file Given that it's been broken several times and the usefulness of the feature is debatable, let's just drop the feature. No feature, no bug 🙃 If users create empty spreadsheet, so be it. They'll clean their mess themselves. Task: 4506185 Forward-Port-Of: odoo/enterprise#77600 Forward-Port-Of: odoo/enterprise#

The current auto-clean feature doesn't work properly and it deletes spreadsheet that shouldn't be deleted.

1) copy a spreadsheet and leave it (no update)
2) upload an XLSX file

Given that it's been broken several times and the usefulness of the feature is debatable, let's just drop the feature. No feature, no bug 🙃

If users create empty spreadsheet, so be it. They'll clean their mess themselves.

Task: 4506185

Forward-Port-Of: odoo/enterprise#77600
Forward-Port-Of: odoo/enterprise#77573

Steps to reproduce: 1. Install l10n_mx on runbot and go to MX company 2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD) 3. Create an invoice with date Day 1 for 23,664 USD 4. Add a payment for 9 USD on Day 1 5. Create a bank transaction for a large MXN amount (let's say 600,000) on Day 2 6. Click "Match" for this transaction 7. In reconciliation widget, select invoice created before 8. Change amount in currency reconciled from invoice to 6,954.76 USD (amount in MXN shou

Steps to reproduce:
1. Install l10n_mx on runbot and go to MX company
2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD)
3. Create an invoice with date Day 1 for 23,664 USD
4. Add a payment for 9 USD on Day 1
5. Create a bank transaction for a large MXN amount (let's say 600,000) on Day 2
6. Click "Match" for this transaction
7. In reconciliation widget, select invoice created before
8. Change amount in currency reconciled from invoice to 6,954.76 USD (amount in MXN should update to 137,975.49)
9. Validate the reconciliation
10. Go to the journal items and show items from journal entry linked to invoice > check partial reconciliation. The reconciled item has a residual of -0.01 and not 0.

Analysis:
During reconciliation, the rate used is always that of the invoice, not the rate of the invoice residuals.

https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1874

However, in the bank reconciliation widget, the residuals' rate was being used to compute the company currency balance of the new AML to create.

This led to a different amount than the amount that can actually be reconciled.

See [this google sheet](https://docs.google.com/spreadsheets/d/1IoKfuOmSeBS9MrU_DkH_73PGtJd7tb73KuAKm5QsrqI/edit?usp=sharing) for analysis

Solution:
Use the invoice rate in the bank reconciliation widget.

opw-4222310

Forward-Port-Of: odoo/enterprise#76935

Steps to reproduce: 1) Configure SEPA provider 2) Input wrong IBAN 3) See UI blocked After this commit when a rpc error happens during payment processing UI is unblocked allowing user to see the error. opw-4411773 Forward-Port-Of: odoo/enterprise#77634

Steps to reproduce:
1) Configure SEPA provider
2) Input wrong IBAN
3) See UI blocked

After this commit when a rpc error happens during payment processing UI is unblocked allowing user to see the error.

opw-4411773

Forward-Port-Of: odoo/enterprise#77634