Factur x cannot have negative lines on <ram:ChargeAmount> which can happen when there is a discount on the invoice. - Create a sale order with a global discount, generate the invoice and generate the factur x xml. - The amount on <ram:ChargeAmount> is negative. We can instead invert both price unit and quantity to have the same result. Inspired by 6f0642d62b6a07141553b655ee3c2b4369bf8ffb which did the same fix for ubl. opw-4668558 Description of the issue/feature this PR addresse

Factur x cannot have negative lines on <ram:ChargeAmount> which can happen when there is a discount on the invoice.

- Create a sale order with a global discount, generate the invoice and generate the factur x xml.
- The amount on <ram:ChargeAmount> is negative.

We can instead invert both price unit and quantity to have the same result.

Inspired by 6f0642d62b6a07141553b655ee3c2b4369bf8ffb which did the same fix for ubl.

opw-4668558

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

This is a followup on [1]. Restricted users are not allowed to apply shapes on images because: - it involves the duplication of the image attachment, and - SVGs mimetype is kept only for users allowed to write views. This commit verifies that the user has restricted edition rights and makes it possible for them to apply shapes on images. Steps to reproduce: - Install eCommerce. - Create a user with sales administrator rights. - Connect as that user. - Go to a product page. - Edi

This is a followup on [1].

Restricted users are not allowed to apply shapes on images because:
- it involves the duplication of the image attachment, and
- SVGs mimetype is kept only for users allowed to write views.

This commit verifies that the user has restricted edition rights and
makes it possible for them to apply shapes on images.

Steps to reproduce:
- Install eCommerce.
- Create a user with sales administrator rights.
- Connect as that user.
- Go to a product page.
- Edit.
- Drop a "Text - Image" block.
- Set a shape on the image.
- Save.
=> Did trigger an error popup.

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

task-2830084

Forward-Port-Of: odoo/odoo#92540

…page reload **Issue:** When the shipping page of the eCommerce site, with the Peruvian module, is reloaded due to incorrect input (such as an invalid VAT number), the city and district fields reset to the first available option instead of retaining the user's selection. **Steps to Reproduce:** 1. Install the Ecommerce app 2. Install the l10n_pe_website_sale module 3. Switch to PE Company 4. Go to the website 5. Buy a product 6. Click checkout 7. Edit the shipping address 8. Selec

…page reload

**Issue:**
When the shipping page of the eCommerce site, with the Peruvian module, is reloaded due to incorrect input (such as an invalid VAT number), the city and district fields reset to the first available option instead of retaining the user's selection.

**Steps to Reproduce:**
1. Install the Ecommerce app
2. Install the l10n_pe_website_sale module
3. Switch to PE Company
4. Go to the website
5. Buy a product
6. Click checkout
7. Edit the shipping address
8. Select a province, city, and district
9. Choose VAT as the Identification Type
10. Enter an incorrect VAT number (e.g., XAXX010101000)
11. Click Save Address
12. Observe that the city and district selections have been reset

Expected Behavior: The city and district fields should retain the user’s selection after the page reloads

Actual Behavior: The city and district fields are reset to the first available option instead of keeping the user’s choices.

**Root Cause**

When the page reloads due to form validation errors, the state selection is preserved, but the city and district selections are lost because they are dynamically populated based on the selected state. The dropdowns for city and district are repopulated, but there is no mechanism to restore the previously selected values after reloading.

**Fix**
Store the selected city and district values before form submission. If these values still exist in the updated list, retain the previous selection, as it indicates that the choice has not changed.

Opw-4628466

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

Forward-Port-Of: odoo/odoo#201562

Versions -------- - 17.0+ Steps ----- 1. Have a product with a custom attribute; 2. create a sales order with the product; 3. enter a value for the customer product; 4. confirm order & go to delivery; 5. print delivery slip. Issue ----- The product's name is displayed twice. Cause ----- The product's name is used as default description. There is currently logic in place to prevent duplicate printing if there's an exact match. If the product has certain attributes, they will

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

Steps
-----
1. Have a product with a custom attribute;
2. create a sales order with the product;
3. enter a value for the customer product;
4. confirm order & go to delivery;
5. print delivery slip.

Issue
-----
The product's name is displayed twice.

Cause
-----
The product's name is used as default description. There is currently logic in place to prevent duplicate printing if there's an exact match. If the product has certain attributes, they will get added to the description, making the strings no longer equal.

Solution
--------
Instead of checking for exact matches, use `startswith` and `removeprefix` to remove the duplicate product name from the description.

opw-4637449

Forward-Port-Of: odoo/odoo#201010

Steps to reproduce: - Force _verify_updated_quantity returns warning - Add product to cart - exception shown Explanation: - When _verify_updated_quantity returns warning, it will use WarningNotification in CartNotification only. However CartNotification required currency_id for AddToCartNotification, therefore exception throw. Forward-Port-Of: odoo/odoo#204585

Steps to reproduce:

- Force _verify_updated_quantity returns warning
- Add product to cart
- exception shown

Explanation:

- When _verify_updated_quantity returns warning, it will use WarningNotification in CartNotification only. However CartNotification required currency_id for AddToCartNotification, therefore exception throw.

Forward-Port-Of: odoo/odoo#204585

Versions -------- - 17.0+ Steps ----- 1. pay for a cart in eCommerce using Xendit; 2. leave the confirmation page before the payment confirms; 3. open cart & empty it. Issue ----- The payment gets confirmed for an empty cart. Cause ----- If a sale order has a transaction linked with a state of `pending`, `authorized` or `done`, the next call to `website.sale_get_order` will no longer return the order that was paid. The transaction's state only changes away from `draft` afte

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

Steps
-----
1. pay for a cart in eCommerce using Xendit;
2. leave the confirmation page before the payment confirms;
3. open cart & empty it.

Issue
-----
The payment gets confirmed for an empty cart.

Cause
-----
If a sale order has a transaction linked with a state of `pending`, `authorized` or `done`, the next call to `website.sale_get_order` will no longer return the order that was paid.

The transaction's state only changes away from `draft` after receiving notification data from the provider. For Xendit, this can take up to half an hour[^1], leaving customers with a lot of time to (unintentionally) modify the cart they paid for.

Solution
--------
Use Xendit's `success_redirect_url` to mark transactions as pending while waiting for full notification data.

This way, any attempt to change the cart will force open a new one.

opw-4438779

[^1]: for this ticket's case:
    8:26 AM: payment was sent to Xendit for Rp 18,000,000.00
    8:39 AM: customer emptied their cart, setting total to Rp 0.00
    8:56 AM: received confirmation that the transaction for Rp 18,000,000.00 was confirmed

Forward-Port-Of: odoo/odoo#201611

### Steps to reproduce: - Install "l10n_it_edi" and switch to Italian company - Accounting > Customers > Invoices - Create a new invoice - Add a partner and go to this partner form - Change the field "Codice Fiscale" with a lowercase value, like "Mrtmtt91d08f205j" - Confirm the invoice and send it to the Tax Agency - The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to

### Steps to reproduce:
- Install "l10n_it_edi" and switch to Italian company
- Accounting > Customers > Invoices
- Create a new invoice
- Add a partner and go to this partner form
- Change the field "Codice Fiscale"  with a lowercase value, like "Mrtmtt91d08f205j"
- Confirm the invoice and send it to the Tax Agency
- The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government

### Solution:
Change `_l10n_it_edi_normalized_codice_fiscale` to return the uppercase value. (Already the case for "Destination Code (SDI)")

To increase the user experience, also add `text-uppercase` on the input in `l10n_it_edi_website_sale` so the text entered there is always capital. Same for "Destination Code (SDI)".

opw-4655364

Forward-Port-Of: odoo/odoo#203217

Steps to reproduce: - Install accounting - Go to Reporting, Invoice Analysis in pivot view - Select Untaxed amount and Average price - Or (Select Product Quantity and Average Price) Issue: If the `average_price` is selected, the `untaxed_amount` becomes empty and not read, and it is the same case for the `product_quantity`. In pivot view, the frontend sends the fields to the backend in this format field_name:agg https://github.com/odoo/odoo/blob/36e6d6ea6792d5e549a7794f111a65fc32decd1c/a

Steps to reproduce:
- Install accounting
- Go to Reporting, Invoice Analysis in pivot view
- Select Untaxed amount and Average price
- Or (Select Product Quantity and Average Price)

Issue:
If the `average_price` is selected, the `untaxed_amount` becomes empty and not read, and it is the same case for the `product_quantity`. In pivot view, the frontend sends the fields to the backend in this format field_name:agg https://github.com/odoo/odoo/blob/36e6d6ea6792d5e549a7794f111a65fc32decd1c/addons/web/static/src/views/pivot/pivot_model.js#L1142-L1143

In [d741788](https://github.com/odoo/odoo/commit/d7417883062e14c4a0a58978463f181b3811d19d), read_group is overridden to correctly handle the `average_price`, and uses both the `untaxed_amount` and the `product_quantity` to compute it. If the `untaxed_amount` and `product_quantity` weren’t in the original fields sent from the frontend by the user, they are removed from the result data. But the problem they are named incorrectly in the if conditions, and because of the format sent from the frontend, the if condition will always succeed (because the name in the fields array is not the same as the one checked in the if condition) leading to the removal of both `untaxed_amount` and `product_quantity` from the result whenever selecting the `average_price`.

opw-4644004

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

Description of the issue/feature this PR addresses: **Description:** > - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line **Steps:** > - Install the "website_customer" module. > - Create a "Website Tag" from the Contacts app-> Configurations. > - Add the tag to any partner's "Website Tags" field (inside the "Sales & Purchase" page). > - Go to the website and open the "Customers" menu(from url). Current behavior before PR: Before F

Description of the issue/feature this PR addresses:

**Description:**
> - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line

**Steps:**

> - Install the "website_customer" module.
> - Create a "Website Tag" from the Contacts app-> Configurations.
> - Add the tag to any partner's "Website Tags" field (inside the "Sales & Purchase" page).
> - Go to the website and open the "Customers" menu(from url).

Current behavior before PR:

    Before Fix:
![Our-References-My-Website](https://github.com/user-attachments/assets/9d5bc1ac-d407-4225-abd0-5f5edf5d6fa8)

    After Fix:
![Our-References-My-Website(1)](https://github.com/user-attachments/assets/d9876e8a-ef52-44d0-8204-34b3325c1f36)

Desired behavior after PR is merged:

    - All Tags are appropriately shown after my fix
    - The issue comes in version 17.0, 18.0, saas~18.1, and saas~18.2

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

Forward-Port-Of: odoo/odoo#203772

- have a follower with a portal partner linked to a specific company "portal" user is important here because internal users don't have multi-company rule. - view the chatter with a user which has no access to that company - the chatter is currently locked by an ACL error The follower should be displayed instead. task-4648765 Forward-Port-Of: odoo/odoo#203558 Forward-Port-Of: odoo/odoo#201864

- have a follower with a portal partner linked to a specific company
  "portal" user is important here because internal users don't have multi-company rule.
- view the chatter with a user which has no access to that company
- the chatter is currently locked by an ACL error

The follower should be displayed instead.

task-4648765

Forward-Port-Of: odoo/odoo#203558
Forward-Port-Of: odoo/odoo#201864

Turnstile was missing on website_mass_mailing. This lack of implementation caused the newsletter forms to not submit anymore. Task-4592066 Forward-Port-Of: odoo/odoo#200158

Turnstile was missing on website_mass_mailing. This lack of implementation caused the newsletter forms to not submit anymore.

Task-4592066

Forward-Port-Of: odoo/odoo#200158

This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715

This fix aims to increase the operation timeout
to reduce the risk of timeouts when sending documents.

If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service.

opw-4608647

Forward-Port-Of: odoo/enterprise#82715

After commit 6d9013f6a106d3c69eb0103504b4cae0befe05e6 it is possible to add a depreciation move on a running asset However, the attempt terminate with a traceback error opw-4655999 Forward-Port-Of: odoo/enterprise#82899

After commit 6d9013f6a106d3c69eb0103504b4cae0befe05e6 it is possible to add a depreciation move on a running asset
However, the attempt terminate with a traceback error

opw-4655999

Forward-Port-Of: odoo/enterprise#82899