### Problem When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconcili

### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.

This PR covers versions 18 & 18.1, as reconciliation logic differs in later versions.

### How to reproduce
    * Open a PoS session.
    * Create an order and pay using customer account.
    * Settle this customer's account (inside PoS).
    * Create a Sale Order and invoice it (or just an invoice).
    * The amount settled can be used as outstanding amount and can be used to pay the created invoice. 
    
enterprise PR: https://github.com/odoo/enterprise/pull/86174
18.2 PR: https://github.com/odoo/odoo/pull/210619
opw-4794793

Forward-Port-Of: odoo/odoo#211166

Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211550 Forward-Port-Of: odoo/odoo#204495

Previously the `state name` of partner is validating,
but as per government API json schema `state tin number` is required.

After this commit:
- The validation now checks the state tin number instead of the state name,
  ensuring it is a valid and min 1 and max-2 digit number.  


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

Forward-Port-Of: odoo/odoo#211550
Forward-Port-Of: odoo/odoo#204495

Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun

Upgrading from 16 to 17 causes issues with demo data.
It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines).

To reproduce:
- initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`)
- install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`)
- upgrade to Odoo 17.0

By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company.

Enterprise PR: odoo/enterprise#80812

opw-4781045

Forward-Port-Of: odoo/odoo#211526
Forward-Port-Of: odoo/odoo#200420

Steps to reproduce the issue: - Enter website edit mode. - Drag and drop a "Social Media" snippet into the footer. - Click on it. - In the options, click the "Add New Social Network" button. - Save the page. - Re-enter edit mode. - Click the pencil icon of the newly added item. - In the options, click the "Replace" button. - Bug: the media dialog does not open. The bug was introduced by commit [1], where the double-click on the icon, which was triggered when clicking the "Replace"

Steps to reproduce the issue:

- Enter website edit mode.
- Drag and drop a "Social Media" snippet into the footer.
- Click on it.
- In the options, click the "Add New Social Network" button.
- Save the page.
- Re-enter edit mode.
- Click the pencil icon of the newly added item.
- In the options, click the "Replace" button.
- Bug: the media dialog does not open.

The bug was introduced by commit [1], where the double-click on the icon, which was triggered when clicking the "Replace" button, was replaced with a direct call to the `openMediaDialog` function.

After this change, in the steps described above, the function is called when there is no selection on the page. As a result, `openMediaDialog` does not execute completely.

This commit fixes the issue by selecting the icon if no selection is already present.

[1]: https://github.com/odoo/odoo/commit/3c89439a16c41d553322893761a35592b73a5338

opw-4734855

Forward-Port-Of: odoo/odoo#211246
Forward-Port-Of: odoo/odoo#210813

Steps are triggered too quick on the runbot. 1- It was trying to render the reward button while computation was still ocurring, thus `coupon_id` wasn't set. > Use of the ? to avoid the traceback 2- It was trying to check for the price while the reward hadn't loaded yet. > Instead we check that the reward is there, we'll check the price at the end. runbot: 163072 Forward-Port-Of: odoo/odoo#211538 Forward-Port-Of: odoo/odoo#211236

Steps are triggered too quick on the runbot.
1- It was trying to render the reward button while computation was still ocurring, thus `coupon_id` wasn't set.
> Use of the ? to avoid the traceback

2- It was trying to check for the price while the reward hadn't loaded yet.
> Instead we check that the reward is there, we'll check the price
at the end.

runbot: 163072

Forward-Port-Of: odoo/odoo#211538
Forward-Port-Of: odoo/odoo#211236

Step to reproduce the issue: - Enter Website edit mode. - Click on the header. - Open the colorpicker of the header in the options. - Click the trash bin icon. - Bug: the CSS of the website is broken. The issue was introduced by this commit [1], where the SCSS `shade-color` function was added to generate the color of the submenu accordion button in the mobile navbar. When no color is selected for the header (which happens after following the steps above), a CSS error occurs because the

Step to reproduce the issue:

- Enter Website edit mode.
- Click on the header.
- Open the colorpicker of the header in the options.
- Click the trash bin icon.
- Bug: the CSS of the website is broken.

The issue was introduced by this commit [1], where the SCSS `shade-color` function was added to generate the color of the submenu accordion button in the mobile navbar. When no color is selected for the header (which happens after following the steps above), a CSS error occurs because the `shade-color` function requires a valid color to work properly.

[1]: https://github.com/odoo/odoo/commit/b975377fe688f10497b75598c0c50bd7b0758367

opw-4793368

Forward-Port-Of: odoo/odoo#210129

- in the management form view, the leave type display name is diffrent than dash borad one which is not the best for UX. So, remove the restriction on the display name as multiple request is handeled on its own wizard now. Task: 4774751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208827

- in the management form view, the leave type display name is diffrent than dash borad one which is not the best for UX. So, remove the restriction on the display name as multiple request is handeled on its own wizard now.

Task: 4774751

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

Forward-Port-Of: odoo/odoo#208827

When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.

When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs).

This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.

According to the Fetch specification, the user agent may terminate an ongoing fetch if that termination cannot be observed through script. In our case, however, the fetch cannot be terminated because the termination can be observed through the promise and a TypeError is thrown[1].

Here a sample to reproduce the errors with firefox on github:

```js
window.onbeforeunload = () => console.log("beforeunload");
fetch("https://github.com/").then(() => console.log("fetch"));
window.location = "https://github.com/";
```

Should log inside the Firefox console:

```log
beforeunload
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
```

Another errors can occur when we unload a page, if we manipulate the DOM when it's unload a DOMException can be trowed[2], we also handle these case inside this commit.

This commit prevents displaying these errors on dialog inside Odoo.

task-4457865

[1]: https://fetch.spec.whatwg.org/#http-network-fetch
[2]: https://webidl.spec.whatwg.org/#dom-domexception-abort_err


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

Forward-Port-Of: odoo/odoo#210854
Forward-Port-Of: odoo/odoo#210786

Scenario: add a popup on a website page with enough text above the button so the button is not visible on the page without scrolling. Display the popup. Result: the popup is opened scrolled at the bottom (depends on if we are logged in or not), this usually works in incognito. Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the first tabbable element in the modal, but if that element is not in the view, the browser automatically scrolls to it. So there is this side effect tha

Scenario: add a popup on a website page with enough text above the
button so the button is not visible on the page without scrolling.

Display the popup.

Result: the popup is opened scrolled at the bottom (depends on if we are
logged in or not), this usually works in incognito.

Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the
first tabbable element in the modal, but if that element is not in the
view, the browser automatically scrolls to it. So there is this side
effect that happen if the first tabbable element is hidden by the
scroll.

Fix: after we focus to the element, we reset the scrollTop to 0 to
ensure we stay at the top of the popup.

opw-4647172

Forward-Port-Of: odoo/odoo#209910
Forward-Port-Of: odoo/odoo#206318

Steps to reproduce on runbot: 1. Select company "My Belgian Company" (`l10n_be` and `account_peppol`) should be installed 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Activate Electronic Invoicing 3. Ensure `+32470123456` is given as the phone number 4. Remove the country prefix from the phone number 5. A validation error is raised complaining about the phone number format The validation should only be performed when we click on the "Activate Peppol" button.. When editing

Steps to reproduce on runbot:
1. Select company "My Belgian Company" (`l10n_be` and `account_peppol`) should be installed
2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Activate Electronic Invoicing
3. Ensure `+32470123456` is given as the phone number
4. Remove the country prefix from the phone number
5. A validation error is raised complaining about the phone number format

The validation should only be performed when we click on the "Activate Peppol" button.. When editing the phone number the wizard should try to auto-format the given phone number before validating.
In case there is no country prefix it should assume the phone number is from the country of the company.

Since commit 7cd8c87e3fcacfefa6c789449eec32a3c5577089 the validation is performed before the auto-formating. There a call to the validation logic (`_sanitize_peppol_phone_number`) was added before the auto-formatting logic. (It was mainly just done to ensure that an external dependency is installed.) But there we do not (and should not) assume the country prefix of the phone number. The phone number is used during the registration process. A missing country prefix could lead to a failed registration.

After this commit
- the validation is only performed when we click on the "Activate Peppol" button.
- the auto-formatting is performed after editing the phone number
- the changes are not stored on the company when clicking on "Discard"
- fix a `self` in a `for ... in self`

part of
task-4791098

Forward-Port-Of: odoo/odoo#211331
Forward-Port-Of: odoo/odoo#210046

Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earl

Step to reproduce:

- install accounting
- in the dashboard searchbar, add a `Group By` with value `type`
- go to vendor bills view from the dashboard
- upload any file

Error:

Wrong value for `ir.attachment.type`: 'purchase'

Expected:

The upload process should go on without any error

Explanation:

in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earlier are thus also added as `default_type` in the context.

But when creating a record, the ORM checks for all `default_*` key in the context and try to use it as additional values for the created record. Since the key-value combination `type` and `purchase` is not valid in an `ir.attachment` record, it throws this error.

Solution:

Before passing the context, we have to make sure to clean all the `default_*` contexts to avoid these kind of behaviors. In python, usually we use `clean_context` method before calling `create`. But since this is in JS, we manually filter all key-value item that starts with "default_" in the context object.

opw-4512697

Forward-Port-Of: odoo/odoo#210423
Forward-Port-Of: odoo/odoo#201628

Before this commit, before loading the calendar view's data, we first checked whether the user had create and edit access rights (and we did that sequentially...). However, this is completely useless. If the user doesn't have those rights, the view's postprocessing, in python, adds `edit` and/or `create` attributes on the arch root node, to indicate operations that aren't allowed. This commit removes those 2 calls, thus speeding up a bit the loading of the calendar view. task-4603194

Before this commit, before loading the calendar view's data, we first checked whether the user had create and edit access rights (and we did that sequentially...).

However, this is completely useless. If the user doesn't have those rights, the view's postprocessing, in python, adds `edit` and/or `create` attributes on the arch root node, to indicate operations that aren't allowed.

This commit removes those 2 calls, thus speeding up a bit the loading of the calendar view.

task-4603194

Part-of: odoo/odoo#199276

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

All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741

All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree").

This commit restores the proper spelling.

Forward-Port-Of: odoo/odoo#211741

Currently ssl certificates are only generated on odoo.com based on db_uuid and enterprise_code. Since we won't be needing enterprise_code anymore we adapt our code to still recover the ssl certificate and be able to recover and log the new 'error' values sent by odoo.com task-4585446 Related PR: https://github.com/odoo/internal/pull/3425 Forward-Port-Of: odoo/odoo#205053 Forward-Port-Of: odoo/odoo#203328

Currently ssl certificates are only generated on odoo.com based on db_uuid and enterprise_code. Since we won't be needing enterprise_code anymore we adapt our code to still recover the ssl certificate and be able to recover and log the new 'error' values sent by odoo.com

task-4585446

Related PR: https://github.com/odoo/internal/pull/3425

Forward-Port-Of: odoo/odoo#205053
Forward-Port-Of: odoo/odoo#203328

Description of the issue/feature this PR addresses: Steps to reproduce: - Create a POS - Enable discount, promo & loyalty - Create a customer, set the PoS barcode information - Create an eWallet for a customer - Scan the barcode in POS - Partner is set but then no eWallet could be applied Current behavior before PR: Cannot use eWallet payment after scanning partner barcode Desired behavior after PR is merged: Will be able to use eWallet payment after scanning partner barcode ta

Description of the issue/feature this PR addresses:
Steps to reproduce:
- Create a POS
- Enable discount, promo & loyalty
- Create a customer, set the PoS barcode information
- Create an eWallet for a customer
- Scan the barcode in POS
- Partner is set but then no eWallet could be applied

Current behavior before PR:
Cannot use eWallet payment after scanning partner barcode

Desired behavior after PR is merged:
Will be able to use eWallet payment after scanning partner barcode

task: opw-4572313

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

Forward-Port-Of: odoo/odoo#198920

This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes

This commit is a followup of [1]. It does two things:

1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust.

2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes no issue in standard odoo. However, as reported in [2], there is a world where `options` is undefined. I couldn't really find how, as it works fine even with the suggested culprit [3]. So this commit simply adds a fallback, which makes sense in stable in case there would be custom code calling those `listViewWidths` functions without options. In master though, we expect from people to adapt their code with respect to this change.

[1] https://github.com/odoo/odoo/pull/210584
[2] https://github.com/odoo/odoo/issues/211243
[3] https://github.com/OCA/web/tree/18.0/web_remember_tree_column_width

closes #211243

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

### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Processing the backorder wizard will create and confirm moves for the backorder picking: https://github.com/odoo/odoo/blob/a7

### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Processing the backorder wizard will create and confirm moves for the backorder picking:
https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1916-L1919 However, as these moves are `make_to_order` they are planned to create and run procurements in their respective `_action_confirm`'s: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1379-L1388

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

Forward-Port-Of: odoo/odoo#210364
Forward-Port-Of: odoo/odoo#209442

DGI only wants units without any decimals. That was already done. But they want these amounts to be the base for the other computations. For instance tax amount is simply ratio * total base for this tax. So we need all the lines to take the rounding into account, which is done with the subformula. We also add the possibility for the client to fix some values by adding an editable second column. The idea is that the sum of the bases for the rates must be equal to the sum of the bases

DGI only wants units without any decimals. 
That was already done. 
But they want these amounts to be the base for the other computations. 
For instance tax amount is simply ratio * total base for this tax. 
So we need all the lines to take the rounding into account, which is done with the subformula.

We also add the possibility for the client to fix some values by adding an editable second column.
The idea is that the sum of the bases for the rates must be equal to the sum of the bases for the types.
We can't guarantee it due to the rounding and we can't fix it automatically. 
The client then needs to modify the lines himself.

opw-4590719




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

Forward-Port-Of: odoo/odoo#209705
Forward-Port-Of: odoo/odoo#203227

Do not use t-out/t-esc to build human-readable content. This is basically the same as string concatenation. This commit wraps the entire string in a gettext call to prevent it from being split into several non-reorderable translations. As a lucky side effect, it also creates a separate translation for the word "table" (as in restaurant tables) which won't overlap with the translation for spreadsheet tables. opw-4754410 Forward-Port-Of: odoo/odoo#210948 Forward-Port-Of: odoo/odoo#210841

Do not use t-out/t-esc to build human-readable content. This is basically the same as string concatenation.

This commit wraps the entire string in a gettext call to prevent it from being split into several non-reorderable translations. As a lucky side effect, it also creates a separate translation for the word "table" (as in restaurant tables) which won't overlap with the translation for spreadsheet tables.

opw-4754410

Forward-Port-Of: odoo/odoo#210948
Forward-Port-Of: odoo/odoo#210841

When sending a combo to a preparation printer, the combo items where not indented correctly. This was leading to a preparation ticket that made it look like all items were normal items, instead of being part of a combo. Steps to reproduce: ------------------- * Create a combo product A * Setup a kitchen printer in the PoS * Open PoS and add the combo product A * Send the order to the kitchen printer > Observation: The preparation ticket does not show the combo items > indented correctl

When sending a combo to a preparation printer, the combo items where not indented correctly. This was leading to a preparation ticket that made it look like all items were normal items, instead of being part of a combo.

Steps to reproduce:
-------------------
* Create a combo product A
* Setup a kitchen printer in the PoS
* Open PoS and add the combo product A
* Send the order to the kitchen printer
> Observation: The preparation ticket does not show the combo items
> indented correctly

Why the fix:
------------
We add a new fields in the `changes` that state if the line is part of a combo. If it is part of a combo, we add a css class that will indent the line accordingly.

opw-4459211

Forward-Port-Of: odoo/odoo#210697
Forward-Port-Of: odoo/odoo#196397

Currently the show quantity setting visible on /product page does not apply on the product and combo configurator. We want to uniformize the behavior and if the setting is enabled then view the quantity selector everywhere depending on whether its visible on /product opw-4716312 opw-4781159 Backport of https://github.com/odoo/odoo/pull/209116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209934

Currently the show quantity setting visible on /product page does not apply on the product and combo configurator.

We want to uniformize the behavior and if the setting is enabled then view the quantity selector everywhere depending on whether its visible on /product

opw-4716312
opw-4781159

Backport of https://github.com/odoo/odoo/pull/209116




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

Forward-Port-Of: odoo/odoo#209934

Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_mov

Steps to reproduce:
- Have a single currency active (no base.group_multi_currency)
- Create a journal entry with lines:
  1. Debit 10 | Credit  0
  2. Debit  0 | Credit 10
- Save (note: line 2 `amount_currency` will be -10)
- Modify the journal entry lines
  2. (edit) Debit 10 | Credit  0
  3. (new)  Debit  0 | Credit 20
- Save

Issue: Validation error will block the action
psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_amount_currency_balance_sign"

It occurs because, as we don't have `amount_currency` in the view, for line 2 the write operation will only store the updated values of `debit`,`credit`,`balance`, leaving the old amount of `amount_currency`. This creates an inconsistency as:
- old `amount_currency` sign is negative
- new `balance` sign is positive

opw-4430334

Forward-Port-Of: odoo/odoo#211076
Forward-Port-Of: odoo/odoo#200566

Currently, an error occurs when sorting is applied again on a different related field after sorting another related field first. Steps to reproduce: - Install `accountant` module - Navigate `Accounting > Accounting > Assets (list view)` - Apply Sorting on column `Fixed Asset Account` - Try to sort the column `Depreciation Account` - Observe the error Error: `AssertionError` The issue occurs when attempting to add a JOIN on an SQL query without verifying whether it has already been

Currently, an error occurs when sorting is applied again on a different related field after sorting another related field first.

Steps to reproduce:
- Install `accountant` module
- Navigate `Accounting > Accounting > Assets (list view)`
- Apply Sorting on column `Fixed Asset Account`
- Try to sort the column `Depreciation Account`
- Observe the error

Error: `AssertionError`

The issue occurs when attempting to add a JOIN on an SQL query without verifying whether it has already been included.  - [1]

This commit resolves the issue by adding a conditional check before adding a join in the query, ensuring that duplicate joins are not added.

[1] - https://github.com/odoo/odoo/blob/b2e564f07f6883111da4581bccfb0f45c7588063/addons/account/models/account_account.py#L150-L152

Sentry-6039417751

Forward-Port-Of: odoo/odoo#211732
Forward-Port-Of: odoo/odoo#196754

Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inhe

Problem:
When the "Apply Now!" button text is deleted (e.g., on
`/jobs/experienced-developer-4`), it becomes uneditable after saving.

Cause:
When all text is deleted, a zero-width space (ZWS) is inserted with
the `data-oe-zws-empty-inline` attribute. This is removed
during the save process. Since the button has `data-oe-field="arch"`
and becomes empty, it is excluded from editable areas in
`_getContentEditableAreas`, making it uneditable after reload.

This worked in 17.0 due to inherited `display: block` from a floated
parent, which added a `<br>` in empty blocks.

Solution:
Preserve the ZWS for inline empty elements with
`data-oe-field="arch"`, ensuring the element remains editable after save.

Steps to reproduce:
1. Navigate to `/jobs/experienced-developer-4`.
2. Open the web editor.
3. Delete the text inside the "Apply Now!" button.
4. Save the page.
5. Reopen the web editor.
→ The button is no longer editable.

opw-4737255

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

Forward-Port-Of: odoo/odoo#209301

Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Problem:
`shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null.

Solution:
Include `th` in the selector alongside `td` to ensure proper detection and navigation.

Steps to reproduce:
- Copy and paste in the editor any table that has `th`.
- Put selection inside a `th` element.
- Press "TAB". → Traceback occurs.

opw-4808751

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

Forward-Port-Of: odoo/odoo#211448

Versions -------- - 18.0+ Steps ----- 1. Create a loyalty card program applying on future orders; 2. add 2 rewards: free shipping (100 points) & discount (200 points); 3. create a loyalty card for current user with 500 points; 4. apply both rewards on an eCommerce order & pay to confirm. Issue ----- In the back end, the sale order displays the loyalty points cost as 200 instead of 300. The same applies to the points history on the loyalty card view. Cause ----- The loyalty hi

Versions
--------
- 18.0+

Steps
-----
1. Create a loyalty card program applying on future orders;
2. add 2 rewards: free shipping (100 points) & discount (200 points);
3. create a loyalty card for current user with 500 points;
4. apply both rewards on an eCommerce order & pay to confirm.

Issue
-----
In the back end, the sale order displays the loyalty points cost as 200 instead of 300. The same applies to the points history on the loyalty card view.

Cause
-----
The loyalty history model introduced by 17ef5c57a5c1 does not sum up the total cost of the points used on an order, instead it only saves the points used of the last reward line per coupon.

Solution
--------
Sum up the points per coupon.

opw-4783518

Forward-Port-Of: odoo/odoo#211275
Forward-Port-Of: odoo/odoo#211188

*: account, partner_autocomplete, web --- This PR is a backport of [this PR](https://github.com/odoo/odoo/pull/203522) Some changes have been made to it for retro compatibility while allowing the change in stable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207449

*: account, partner_autocomplete, web

---

This PR is a backport of [this PR](https://github.com/odoo/odoo/pull/203522)

Some changes have been made to it for retro compatibility while allowing the change in stable.

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

Forward-Port-Of: odoo/odoo#207449

Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I hav

Backport of 18affd81cbdd321e428b729602f91dc06988929f

Steps:
------
* Add properties (displayed on card) to a task of a project
* Open the card view of the task in the calendar view of the project

Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields.

opw-4767059

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

Forward-Port-Of: odoo/odoo#210545

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211520 Forward-Port-Of: odoo/odoo#211426

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

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

Forward-Port-Of: odoo/odoo#211520
Forward-Port-Of: odoo/odoo#211426

The adaptations from [1] and [2] added some code to the snippet preview dialog, mainly to adapt text highlights in the snippets content (starting from `18.0`) and enable the snippets preview interactions (starting from `18.3`) [A]. In a runbot test context, the snippet selection happens too fast that the code from [A] (linked to the async behaviour of `insertSnippets`) can still process the snippets dialog `iframeDocument` (lost after the dialog being closed on snippet selection). Th

The adaptations from [1] and [2] added some code to the snippet preview
dialog, mainly to adapt text highlights in the snippets content
(starting from `18.0`) and enable the snippets preview interactions
(starting from `18.3`) [A].

In a runbot test context, the snippet selection happens too fast that
the code from [A] (linked to the async behaviour of `insertSnippets`)
can still process the snippets dialog `iframeDocument` (lost after the
dialog being closed on snippet selection).

The goal of this commit is to fix this behaviour by simply taking into
consideration the fact that the preview content can be lost (since in
a real use case, a user will select a snippet in a reasonable time).

[1]: https://github.com/odoo/odoo/commit/1aaf483c5d3b8e8816cfbea7da96ac007a42d492

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

Remark: This commit will be adapted on `18.3` to fix the code from [2].

runbot-190596

Forward-Port-Of: odoo/odoo#210295

In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#86107 Forward-Port-Of: odoo/enterprise#82292

In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47
we removed an explicit flush performed right after move creation.
Because of this change, when fetching data for the sie import we might not see
all the relevant lines. We need to ensure to flush any data left in
cache before making a SQL query

no opw

Forward-Port-Of: odoo/enterprise#86107
Forward-Port-Of: odoo/enterprise#82292

missing group attribute for ytd_balance_ids (private field) build_error-162969 Forward-Port-Of: odoo/enterprise#83688

missing group attribute for ytd_balance_ids (private field)

build_error-162969

Forward-Port-Of: odoo/enterprise#83688

…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299

…de for payslip display

We increase the size of the external CH code to not impact payslip display

Forward-Port-Of: odoo/enterprise#86299

Prior to this commit, the creator box used the old version of the app icon (with gradients). This commit updates this icon to use the last version. task-4709035 | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/enterprise#861

Prior to this commit, the creator box used the old version of the app icon (with gradients).
This commit updates this icon to use the last version.

task-4709035

| Before | After |
|--------|--------|
| ![Capture d’écran 2025-04-10 à 16 11 00](https://github.com/user-attachments/assets/ede90a72-97a9-45da-8128-21ba3199b487) | ![Capture d’écran 2025-05-05 à 14 50 56](https://github.com/user-attachments/assets/4f42a051-a6a0-4c7e-ac24-36cc3e86386a) |

Forward-Port-Of: odoo/enterprise#86191
Forward-Port-Of: odoo/enterprise#83242

For languages with longer terms than the English ones, the labels in the date filter would overflow because they had a fixed width. We now change it to use a minimal width and expand with the content. Also, the quarter label was not translatable in other languages that do not use the notation "Q1 2025". It's made translatable now. Lastly, some padding caused custom date inputs to be too narrow, meaning a horizontal scroll was necessary to see the whole value. This was fixed as well. [ta

For languages with longer terms than the English ones, the labels in the date filter would overflow because they had a fixed width. We now change it to use a minimal width and expand with the content.

Also, the quarter label was not translatable in other languages that do not use the notation "Q1 2025". It's made translatable now.

Lastly, some padding caused custom date inputs to be too narrow, meaning a horizontal scroll was necessary to see the whole value. This was fixed as well.

[task-4770592](https://www.odoo.com/odoo/project.task/4770592)

Forward-Port-Of: odoo/enterprise#85523
Forward-Port-Of: odoo/enterprise#84662

**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#832

**Issue:**
In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs.

**Steps to reproduce:**

- make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company
- Payroll > Transmission > Salary Certificate Rectification
- create a new declaration and fill the form with a newly created previous declaration
- click on "Prepare Data"

A traceback is raised

opw-4687938

Forward-Port-Of: odoo/enterprise#83261

Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows w

Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line.

Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field.

To ensure those flows work fine with SEPA, we should also match transactions and statement lines whose partners names match when there is no partner_id set on the bank statement line.

opw-4536189

Forward-Port-Of: odoo/enterprise#85965

Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution

Versions
--------
- 17.0+

Steps
-----
1. Go to Automation Rules;
2. create a new automation;
3. set model to `product.pricing`;
4. in one of the filters, check the record(s) that fit in the domain.

Issue
-----
> EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2))
> Error: Name 'parent' is not defined

Cause
-----
`parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate.

Solution
--------
Remove the `parent` checks.

opw-4788215

Forward-Port-Of: odoo/enterprise#86384

This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#76142 Forward-Port-Of: odoo/enterprise#57781

This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger.

Task link: https://www.odoo.com/web#model=project.task&id=3774149
task-3774149

Forward-Port-Of: odoo/enterprise#76142
Forward-Port-Of: odoo/enterprise#57781

Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun

Upgrading from 16 to 17 causes issues with demo data.
It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines).

To reproduce:
- initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`)
- install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`)
- upgrade to Odoo 17.0

By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company.

Community PR: odoo/odoo#200420

opw-4781045

Forward-Port-Of: odoo/enterprise#86341
Forward-Port-Of: odoo/enterprise#80812

## Version: 17.0+ ## Issue: No payment can be done for subscriptions with no starting day set ## Steps to reproduce: Ensure Stripe is correctly set up and runs in demo version - Create a quotation for a subscription and leave the field "Start Date” blank - Generate a payment link and try to pay it from incognito mode using Stripe ## Cause: Revealed by https://github.com/odoo/enterprise/commit/c7335a8064e584785aeb21383a87cac8e829af5d opw-4807108 Forward-Port-Of: odoo/enterprise

## Version:
17.0+

## Issue:
No payment can be done for subscriptions with no starting day set

## Steps to reproduce:
Ensure Stripe is correctly set up and runs in demo version
- Create a quotation for a subscription and leave the field "Start Date” blank
- Generate a payment link and try to pay it from incognito mode using Stripe

## Cause:
Revealed by https://github.com/odoo/enterprise/commit/c7335a8064e584785aeb21383a87cac8e829af5d

opw-4807108

Forward-Port-Of: odoo/enterprise#86340
Forward-Port-Of: odoo/enterprise#86205

- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where due amounts need to be accurately reflected in the financial records. - This commit also adds a test to ensure that account move lines (aml) are properly reconciled when settling due amounts in the POS. ### Problem When paying a PoS order using customer account, an account move line debiting Ac

- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where due amounts need to be accurately reflected in the financial records.
- This commit also adds a test to ensure that account move lines (aml) are properly reconciled when settling due amounts in the POS.

### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.

### How to reproduce
    * Open a PoS session.
    * Create an order and pay using customer account.
    * Settle this customer's account (inside PoS).
    * Create a Sale Order and invoice it (or just an invoice).
    * The amount settled can be used as outstanding amount and can be used to pay the created invoice. 

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

 opw-4794793
 
 Co-authored-by: Majed Alhanash (malh) <malh@odoo.com>

Forward-Port-Of: odoo/enterprise#86174