This update corrects a formatting problem in the VoIP contact information display. It helps prevent incorrect or confusing text from appearing when users view call contact details.

This change fixes an unreliable automated test in Web Studio navigation. It helps reduce false failures in the release process, making validation more dependable without changing the user experience.

runbot-error-224154

The VoIP softphone now shows a pause icon when an active call is placed on hold. This gives users clearer visual feedback in both the softphone top bar and systray, reducing confusion during calls.

This commit modifies the icons displayed in the softphone interface to provide clearer feedback on call status. Now, when the ongoing call is on hold, the user will see a pause icon in the top bar and the systray item.

This update corrects how Mexican e-commerce checkout handles tax ID validation after a related platform change. It helps prevent validation errors during website sales for customers entering VAT or tax details.

In PR https://github.com/odoo/enterprise/pull/75974, it was forgotten that the return value for _run_vat_checks had changed.

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

**Steps to reproduce the issue:** - Install stock, purchase - Activate multi step routes setting - Create a product with track inventory and putaway rule from loc1 to loc2 - Create a PO on that product and confirm it - Print the picking operations report of the receipt picking **Issue** In 3816156, "To" column in the report shows the move's destination location instead of the actual destination location determined by the putaway rule. https://github.com/odoo/odoo/blob/09efa08050c4e32d0

**Steps to reproduce the issue:**
- Install stock, purchase
- Activate multi step routes setting
- Create a product with track inventory and putaway rule from loc1 to loc2
- Create a PO on that product and confirm it
- Print the picking operations report of the receipt picking

**Issue**
In 3816156, "To" column in the report shows the move's destination location instead of the actual destination location determined by the putaway rule.
https://github.com/odoo/odoo/blob/09efa08050c4e32d03b242be4098da999de9cdc3/addons/stock/report/report_stockpicking_operations.xml#L144

opw-4745361
opw-4715416

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

Before this commit, if the order of attributes added to a product differed from the order based on their IDs, adding a product with multiple attributes would result in the attributes appearing in the wrong order in the orderline. opw-4736195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209086

Before this commit, if the order of attributes added to a product differed from the order based on their IDs, adding a product with multiple attributes would result in the attributes appearing in the wrong order in the orderline.

opw-4736195

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

Forward-Port-Of: odoo/odoo#209086

Before this commit, if the start or end minute was set to a non-integer value (e.g., 59), no slots would be available for selection, which prevented sales. This was due to floating-point precision issues when generating time slots. opw-4793086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210367

Before this commit, if the start or end minute was set to a non-integer value (e.g., 59), no slots would be available for selection, which prevented sales. This was due to floating-point precision issues when generating time slots.

opw-4793086

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

Forward-Port-Of: odoo/odoo#210367

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

- non-important notification item border around them to give a better visual spacing between items now that there's shadow on them - important notification bg in dark theme has now lighter color, making them a bit more catchy than non-muted items. Forward-Port-Of: odoo/odoo#211754

- non-important notification item border around them to give a better visual spacing between items now that there's shadow on them
- important notification bg in dark theme has now lighter color, making them a bit more catchy than non-muted items.

Forward-Port-Of: odoo/odoo#211754

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

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

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

Steps to reproduce: - Have a pricelist with rules. - Add this pricelist as the default one for a POS (kiosk). - Open the kiosk and add the products to trigger the price rule Issue: The price rule is not taken into account. This occurs because the kiosk currently does not set the order pricelist in kiosk mode. Also, pricelist rules are not loaded as it occurs in normal POS session [1] [1] https://github.com/odoo/odoo/blob/c8d7452063a4712b03b6d23e944ff283bdcea857/addons/point_of_sale

Steps to reproduce:
- Have a pricelist with rules.
- Add this pricelist as the default one for a POS (kiosk).
- Open the kiosk and add the products to trigger the price rule

Issue: The price rule is not taken into account.

This occurs because the kiosk currently does not set the order pricelist
in kiosk mode.
Also, pricelist rules are not loaded as it occurs in normal POS session [1]

[1] https://github.com/odoo/odoo/blob/c8d7452063a4712b03b6d23e944ff283bdcea857/addons/point_of_sale/static/src/app/store/pos_store.js#L417

This commit aim to restore the pricelist functionality by loading the
pricelist rules at startup like `computeProductPricelistCache` does

opw-4553345

Forward-Port-Of: odoo/odoo#206039
Forward-Port-Of: odoo/odoo#199942

After [this commit][1], some translations in the Facturae module for Spain were lost. We're adding them again here in the CSV file directly. [1]: https://github.com/odoo/odoo/commit/87fc0d6b9202b9b01d2db0821a5a515d28be210a Forward-Port-Of: odoo/odoo#211630

After [this commit][1], some translations in the Facturae module for Spain were lost. We're adding them again here in the CSV file directly.

[1]: https://github.com/odoo/odoo/commit/87fc0d6b9202b9b01d2db0821a5a515d28be210a

Forward-Port-Of: odoo/odoo#211630

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

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

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

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#211676 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#211676
Forward-Port-Of: odoo/odoo#204495

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

Add localization for Oman: - Accounts - Taxes - Fiscal positions - States - Tax reports task ID: 3927925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211301 Forward-Port-Of: odoo/odoo#201016

Add localization for Oman:
- Accounts
- Taxes
- Fiscal positions
- States
- Tax reports

task ID: 3927925


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

Forward-Port-Of: odoo/odoo#211301
Forward-Port-Of: odoo/odoo#201016

- 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

In odoo/odoo#208571, a fix was made to prevent 1 unit of weight from added when cancelling weighing. However, this also changed the behaviour when a scale error (such as IoT box being disconnected) occurs, preventing the product from being manually entered. In this commit, we amend the condition to only stop adding the order line if the user closes the scale popup, but still add it on error. opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/subm

In odoo/odoo#208571, a fix was made to prevent 1 unit of weight from added when cancelling weighing. However, this also changed the behaviour when a scale error (such as IoT box being disconnected) occurs, preventing the product from being manually entered.

In this commit, we amend the condition to only stop adding the order line if the user closes the scale popup, but still add it on error.

opw-4643243

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

Forward-Port-Of: odoo/odoo#211455
Forward-Port-Of: odoo/odoo#209815

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

Scenario: - create an object_write (Update the Record) action - update a field with equation evaluation (Python expression) with an expression like "record.id" - click on "Create contextual action" - go to a list view of the model, execute the action for several records Result: the value of the field of all records are computed based on the first selected record. Issue: we don't change the "record" in the evaluation context and just keep the first record. Fix: changing the reco

Scenario:
- create an object_write (Update the Record) action
- update a field with equation evaluation (Python expression) with an
  expression like "record.id"
- click on "Create contextual action"
- go to a list view of the model, execute the action for several records

Result: the value of the field of all records are computed based on the
first selected record.

Issue: we don't change the "record" in the evaluation context and just
keep the first record.

Fix: changing the record.

Note: without the fix, the added test fails because the city of the
second record is set to the value of the ID of the first record.

opw-4491099

__PR code note__:

I did the change in "run" but this could be done in `_run_action_object_write`, I chose run because we are already changing the action_id in it.

The "`if eval_context.get('record') is not None`" is to not change an hypothetical case where `self.model_id` doesn't match the `context.action_model`.

__PR note__:

If it was too risky, we could probably merge in an higher version, the ticket is in 17.0 and this is still happening in master.

I've not heard of this issue before so this must not be very frequent or urgent, but I guess this is because people either use a python constant or they just use a python action with a for loop in general.

Forward-Port-Of: odoo/odoo#211122
Forward-Port-Of: odoo/odoo#210855

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

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

Steps to reproduce: 1) Create a free shipping reward 2) Enable standard delivery and set price to 100 3) Configure stripe provider with express checkout 4) Go to /shop 5) Add a product to the cart with the price less than 100 6) Go to the checkout and apply reward 7) Go back to the cart and observe a traceback Reason: delivery_amount was calculated without a discount and in express checkout form `_getOrderDetails` this amount was subtracted from the order total which resulted in negati

Steps to reproduce:
1) Create a free shipping reward
2) Enable standard delivery and set price to 100
3) Configure stripe provider with express checkout
4) Go to /shop
5) Add a product to the cart with the price less than 100
6) Go to the checkout and apply reward
7) Go back to the cart and observe a traceback

Reason: delivery_amount was calculated without a discount and in express checkout form `_getOrderDetails` this amount was subtracted from the order total which resulted in negative value

Solution:
Add discount if any

opw-4648641

Forward-Port-Of: odoo/odoo#211456
Forward-Port-Of: odoo/odoo#209103

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

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

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

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

Doing asynchronous things in the onWillStart can be tricky. Methods that come from services are usually protected against those, and hang up if the component was destroyed during the call, but other calls aren't protected. This commit fixes a race condition where a protected call is done after a component is destroyed and crashes. runbot-error-135245 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I

Doing asynchronous things in the onWillStart can be tricky. Methods that come from services are usually protected against those, and hang up if the component was destroyed during the call, but other calls aren't protected.

This commit fixes a race condition where a protected call is done after a component is destroyed and crashes.

runbot-error-135245

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#211140
Forward-Port-Of: odoo/odoo#210773

Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This causes unwanted dark mode styles (e.g., `background-color`, `border-color`, and `color`) to persist even after switching back to light mode, especially in email signatures. Solution: Skip stylesheets that only affect `color`, `background-color`, or `border-color` on `table` elements. This av

Problem:
When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering.

This causes unwanted dark mode styles (e.g., `background-color`, `border-color`, and `color`) to persist even after switching back to light mode, especially in email signatures.

Solution:
Skip stylesheets that only affect `color`, `background-color`, or `border-color` on `table` elements. This avoids incorrect rendering in light mode without removing essential formatting styles.

Note:
Skipping all styles caused layout issues, so the fix targets only problematic styles.

Fixed in `web_editor`:
https://github.com/odoo/odoo/commit/d076dbcc273be5c8f337de9263effa82c9d9c0c8

Steps to reproduce:
1. Switch to dark mode.
2. Add an email signature in user preferences.
3. Switch back to light mode.
4. Open the mail composer. → The signature table shows a dark background.
5. Send the email. → The table in the mail thread still has a dark background.

opw-4713718

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

Forward-Port-Of: odoo/odoo#210834

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

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

…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

**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

Backport of https://github.com/odoo/odoo/pull/204723 Task-4448873 Forward-Port-Of: odoo/enterprise#86443

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

Task-4448873

Forward-Port-Of: odoo/enterprise#86443

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

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

This commit simply amends the expected scale checksum after the fix that was carried out in the community PR (odoo/odoo#209815) opw-4643243 Forward-Port-Of: odoo/enterprise#86292 Forward-Port-Of: odoo/enterprise#85442

This commit simply amends the expected scale checksum after the fix that was carried out in the community PR (odoo/odoo#209815)

opw-4643243

Forward-Port-Of: odoo/enterprise#86292
Forward-Port-Of: odoo/enterprise#85442

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

Bug === If a user creates a shortcut to a document he can read, (but he has no edit access on the target), he should have edit access on the shortcut. Task-4582290 Forward-Port-Of: odoo/enterprise#80018

Bug
===
If a user creates a shortcut to a document he can read, (but he has no edit access on
the target), he should have edit access on the shortcut.

Task-4582290

Forward-Port-Of: odoo/enterprise#80018

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