Have two dialogs opened, call twice `close` on one of them. From that point, the `stack` in dialog_service is empty (because the second time, the dialog can't be found in `stack`, so its index is -1, and calling `splice` with -1 removes from the end of the array), even though one of the 2 dialogs is still displayed. From that point, calling closeAll does not close the remaining dialog.

In practice, this can be reproduced in Employees > Laurie Poiret (must be in BE company). In the cog menu, click on "Departure: Holiday Attest". In the dialog, click on the external button of the many2one. Close the second dialog by clicking on the X. At this point, `close` has been called twice for that dialog (once by the click on the cross, and once by an override of `dialogData.dismiss` in FormViewDialog), and `stack` is thus empty. Clicking on an action button in the first dialog (e.g. "Validate & Compute holiday attests") then no longer closes the remaining dialog as it should (as `closeAll` is called by the action service). Then, a crash can occur when manually trying to close that dialog, as the view in the background no longer exists, and closing the dialog calls its `onClose` callback, which tries to reload the view, thus leading to the "Component is destroyed" error.

Issue introduced by https://github.com/odoo/odoo/pull/203169

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

Commit [1] (which was patched by multiple other commits since then already) needs yet another patch: the `rounded-start`, `rounded-end`, `rounded-top`, `rounded-bottom` and all their size variants were not working anymore: the direction they were not supposed to control were forced to the default border-radius value. E.g. the class rounded-end-4 was forcing `border-radius: default big big default` instead of just forcing "big" on the top-right and bottom-right.

This could be fixed while keeping the improvement added by [1] (which is allowing the value to use CSS variable, allowing to auto-adapt children with the right border-radius when needed) but it is fact better/simpler to just revert the improvement just for those classes (while keeping it for the base `rounded` and `rounded-{SIZE}` classes). Indeed, this is not necessary at the moment. They can be used in layouts but we do not allow edition of their radius via the builder: when we do, we normally should always prefer to give the user full control over the 4 directions, by switching to the `rounded` or a `rounded-{SIZE}` class.

This bug could be visible in different standard ways:
- Notifications
- Cards Grid snippet
- ...

Note: this also actually revealed that [1] re-introduced the 4 and 5 sizes which were actually disabled by the /web/.../utilities_custom.scss file. This commit re-disable them for those partial classes... but they probably should be restored to respect Bootstrap's default. The 1-2-3 sizes are also not using CSS variable of Bootstrap. This commit adds a FIXME comment about this.

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

Related to task-3358501

**Current behavior before PR:**

**Issue 1:**

- Have a long text content in editable, making the container scrollable.
- Select first line of the text, in toolbar open color selector.
- Scroll down until the toolbar overflows and becomes hidden.
- Notice that the toolbar disappears when it overflows its container while color picker remains open, floating at the top of container.

**Issue 2:**

- Select a text having gradient text color.
- Open text color selector, switch to custom color picker.
- Notice that hex and rgba fields are empty and user is not able to apply color through it.

In colorpicker.js, the convertCSSColorToRgba method fails when attempting to convert a gradient color to RGBA. As a result,
colorComponents does not receive valid values and colorpicker doesn't work as expected.

**Issue 3:**

After merging commit [1], text color can be applied without removing or affecting the existing gradient color. In result, if gradient is fully selected then applying text color creates a new font tag inside gradient instead of replacing the gradient.

**Desired behavior after PR:**

**Issue 1:**

Now, when the toolbar overflows and gets hidden, the color selector becomes hidden along with toolbar.

**Issue 2:**

Now, if `convertCSSColorToRgba` fails to convert selected color to rgba color then default color `#FF0000`is assigned to color
components. This ensures that the colorpicker functions correctly.

**Issue 3:**

Now, if gradient is fully selected then,
- Applying text color removes existing text gradient.
- Applying background color removes existing background gradient.
- Applying text color doen't remove the existing background gradient.
- Applying background color doesn't remove the existing text gradient.

[1]: https://github.com/odoo/odoo/commit/938995744b15f345958a2d78a6c844dd5bf1ae6c

Enterprise PR: https://github.com/odoo/enterprise/pull/84579

task-4581884

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

Forward-Port-Of: odoo/odoo#221381
Forward-Port-Of: odoo/odoo#202889

When returning tracked-by-serial products from an incoming picking for
an exchange, the exchange move will have selected existing serial numbers
for the new incoming picking.

This happens because `move_orig_ids` is set on the exchange move(s),
then `_action_assign()` happens. If there's a `move_orig_ids`, it will
use the available move lines from the move_orig_ids and so assign the
corresponding serial number.

Additionally, the buttons to generate/import serials/lots are invisible
because `origin_returned_move_id` is set on the same exchange move(s).
Again, the exchange move(s) should be considered 'new' move thus having
no origin.

task 4893860:
Additionally (again), it fixes an issue where on-hand quantities and
forecasted quantities of the exchanged product were incorrect after
validating the exchange.

task 4778066:
Finally, this PR also hides the 'Return for Exchange' button for
pickings that are neither `incoming` nor `outgoing`.

tasks 4748294 (& 4778066 & 4893860)

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

Forward-Port-Of: odoo/odoo#224696
Forward-Port-Of: odoo/odoo#216111

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

Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.

Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.

Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.

Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.

In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.

As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668

Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
    - This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
    - `property_product_pricelist` shouldn't get synced by itself
    - `specific_property_product_pricelist` is already included by the base method

opw-4988736

Forward-Port-Of: odoo/odoo#224133
Forward-Port-Of: odoo/odoo#222223

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

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

Forward-Port-Of: odoo/odoo#224044
Forward-Port-Of: odoo/odoo#215615

Currently, an error occurs when a new user with the Member role and Administrator rights for the Point of Sale app attempts to open POS Category.

Steps to reproduce:
---
- Install the `point_of_sale` module (without demo data).
- Create a new User and give Administrator rights for POS & Accounting
- Now log in with a new user in a different browser
- Open the pos session(Clothes or bar)

Traceback:
---
```py
AccessError: You are not allowed to modify 'Product Category' (product.category) records.

This operation is allowed for the following groups:
	- Products/Admin en Products / Create

Contact your administrator to request access if necessary.

ParseError:while parsing /home/odoo/src/odoo/saas-18.3/addons/point_of_sale/data/scenarios/clothes_category_data.xml:5, somewhere inside <record id="product_category_clothes" model="product.category">
            <field name="name">Clothes</field>
        </record>
```

This commit prevents the error by displaying an "Access Denied" pop-up when a user with the "Member" role and Administrator rights attempts to open the POS Category.

sentry-6683335275, 6679363278, 6823710988

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

Forward-Port-Of: odoo/odoo#215429

Recent design changes from this PR: https://github.com/odoo/odoo/pull/201019 caused the `Add to Cart`, `Buy Now` buttons, and quantity selector to be moved outside the main `<form>` element on the product page — specifically when the product image is full width or has zero size.

Steps to reproduce:
- Install eCommerce
- Edit a product page and set the product image to full width or zero width
- Try to add the product to the cart or use Buy Now

Issue:
- Clicking `Add to Cart` or `Buy Now` throws a traceback
- The product cannot be ordered when using full-width images

Root cause:
- The buttons and quantity selector are no longer inside the expected `<form>`, so the selector used in the JS widget fails to find the right form data.

Fix:
- Update the selector to correctly target the intended `<form>` so the widget can fetch the correct product details when a button is clicked.

opw-4934557
Affected version: saas~18.4

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

## Steps to reproduce:
- Make sure the Mexican localization is installed and properly set up for signing invoices
- Make sure the payment providers are set up (it can be demo, the customer uses Stripe but it can be reproduced with any
- Make sure the online payment setting is active
- Go to subscription module
- Do a new order
- In other info, add the online payment checkmark
- Confirm the order
- Generate the payment link or go into the preview
- Make the payment

## Issue:
The invoice is generated, but is not signed by the government (no edi is generated), as it used to.

## Cause:
The flow works in 17.0 but for the wrong reason. Before this [commit](https://github.com/odoo/enterprise/pull/70562), two mails were sent. And during the chain of triggers of the second email, edi document was generated with `orders._send_success_mail(tx.invoice_ids, tx)`.
https://github.com/odoo/enterprise/pull/70562/files#diff-8778c8dce7ca1c24de19f26f11ac0c5410c6c2a4d121c3815682a2323cbb09c2L177

After the removal of the method, it should still work since we still have `payment.transaction._send_invoice` which calls `_generate_and_send_invoices` and should trigger the sub calls necessary for generating the edi stuff.
But in `_create_or_link_to_invoice`, we check that the transaction has no invoice_ids linked (make sense with the name of the method). However, at this stage, we already created the invoice in
https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/controllers/portal.py#L419-L424

And unfortunately, it will be effectively possible to "let the post process of transaction create" the invoices only in Master (the code is not ready yet). For now it would be too risky for a stable version to make such change.

## Solution:
We ensure EDI documents are generated whenever a `subscription_action` is set.

To achieve this, modify the `_post_subscription_action` hook to call `_subscription_post_success_payment` for any `subscription_action`, including `assign_token`.

From `_subscription_post_success_payment`, we can call `_generate_and_send_invoices` on any invoice that has an EDI associated with it, which sends & signs the required EDI documents.


opw-4648189

Forward-Port-Of: odoo/enterprise#93130
Forward-Port-Of: odoo/enterprise#84815

Currently, an error occurs when trying to remove a move line from a bank statement line if the journal entry contains lines with different reconciliation models.

**Steps to Reproduce:**
1. Install the Accounting module.
2. Duplicate the "Internal Transfer" reconciliation model.
3. Accounting dashboard > click on Bank > create new record.
4. Add the invoice, apply "Internal Transfer" reconciliation model.
5. Edit the balance of the line to lower, apply duplicated model(Internal Transfers (copy)).
6. Try deleting the generated Liquidity Transfer line.

(Refer [this video](https://drive.google.com/file/d/1cz80Q5325x3rqYUlGahVzFIXH2iqrbRF/view?usp=drive_link) for steps to reproduce.)

**Error:**
ValueError - Expected singleton: account.reconcile.model(8, 6)

**Cause:**
In the method `delete_reconciled_line` at [1], the `reco_model_id` is fetched from `self.move_id.line_ids.reconcile_model_id`. If the move contains lines linked to multiple reconcile models, this causes a singleton error during subsequent processing.

**Fix:**
This commit uses the already computed `move_lines_to_remove` to retrieve `reconcile_model_id` instead of accessing it from `self.move_id.line_ids`, which may result in a multi-recordset.

[1] - https://github.com/odoo/enterprise/blob/89aa58029a79928788277489414f8192aa5353e4/account_accountant/models/account_bank_statement.py#L1041-L1049

sentry-6781788260

Forward-Port-Of: odoo/enterprise#91619

### Steps to reproduce:
	- Install Helpdesk, Sale Subscription apps
	- Create a service recurring product and set its invoicing policy as 'Based on Timesheets'
	- Create a SO with the created product and set the qty to 0
	- Create a Helpdesk ticket and link it to the SO
	- Record some timesheets in this SO
	- Run the cron for generating recurring invoices
	- Notice no invoice will be created for the SO and it will be considered as free renewal

### Cause:
When trying to create a recurring invoice we check if the invoice that will get generated is free by checking the MRR and the total amount of the SO and if one of them are 0 we will flag this invoice as free so we won't generate it

### Fix:
We check if the order lines to be invoiced is invoiced based on delivery and they have delivered quantity already and if so we create the invoice even if the MRR and the total amount is equal 0

opw-4990478

Forward-Port-Of: odoo/enterprise#93245
Forward-Port-Of: odoo/enterprise#93115

### Steps to reproduce:
	- Install Planning app
	- Create a portal user and an employee for this user
	- Create a shift for this user and Publish it
	- Go to the email that has been sent and click on View Your planning
	- Notice you are redirected to the portal dashboard home

### Cause:
Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my

https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26

### Fix:
We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view

opw-5045746

Forward-Port-Of: odoo/enterprise#93359
Forward-Port-Of: odoo/enterprise#93333