*:website, website_payment

> Commit 1:

[FIX] web_editor: prevent infinite bounce loop when clicking undo
Steps to reproduce:
1. Click on a snippet without dragging it.
2. Notice that the "Drag building blocks here" section starts bouncing.
3. Observe that a step is added to the history (Undo becomes available).
4. Click on Undo button.

Issue:
1. The `o_catch_attention class` is repeatedly added and removed, creating unnecessary history steps in the editor.
2. No actual changes occur in the wrap area, yet the editor records history steps.
3. This leads to an infinite bounce loop when using Undo/Redo.

Expected behavior:
1. The Undo button should not be activated.
2. Infinite bouncing should not occur.

This PR prevents unnecessary history steps by disabling history tracking during this phase using `observerUnactive` and `observerActive`. This ensures that the editor does not record redundant changes, preventing infinite bounce loops.
 
 
 > Commit 2:
 
 [FIX] website_payment: fix donation amount not updating issue
 Steps to Reproduce:
1. Go to Website → Add a Donation snippet.
2. Enter a custom amount and click "Donate". You will be redirected to the donation/pay page.
3. Use the browser's back button to return to the previous page.
4. Change the amount in the custom amount field.
5. Click "Donate" again.
- The old amount is still used instead of the new one.

Expected Behavior:
The donation amount should update correctly when changed.

The issue occurs because clicking the "Donate Now" button appends a hidden value to the form snippet, which is then used in payment_form. When navigating back and selecting "Donate Now" again, a duplicate hidden value is added instead of replacing the previous one. This PR ensures that if a value already exists, it is replaced instead of being
appended, resolving the issue.


> Commit 3:

[FIX] web_editor: fix dropdown options value

Steps to reproduce:
1. Go to the website and drag and drop the form snippet.
2. Change the action to 'Subscribe to Newsletter'.
3. Click on multi-checkbox field to view its options.

- Even after selecting an option, it remains in the dropdown, allowing multiple selections of the same option.

Expected behaviour:
- Once an option is selected, it should be removed from the dropdown.

Solution:
This PR removes the count from the display name, ensuring correct form behavior.

task-4583314

Forward-Port-Of: odoo/odoo#234513
Forward-Port-Of: odoo/odoo#203454

When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.

`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.

The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.

The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.

Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown

=> Archived teams appear in the dropdown

Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801

Forward-Port-Of: odoo/odoo#261300

Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
    - Kit bom
    - Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery

> Error message: "You are trying to reconcile some entries that are already reconciled."

/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.

Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.

When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.

However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.

Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.

This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.

https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225

-----
Ticket:
opw-5722072

Forward-Port-Of: odoo/odoo#263418
Forward-Port-Of: odoo/odoo#258013

Cause:
======
Commit [1] kept model-required fields enabled when conditionally hidden so their default value is still submitted (needed e.g. for the "Create an Opportunity" action where the Subject field has to reach the server).

The Subject field of the "Send an Email" form was incorrectly flagged as `modelRequired`, but `mail.mail.subject` is not actually required on the server. As a side effect of the above commit, hiding the Subject field through visibility conditions left the empty input enabled, which then triggered the client-side "Please fill in the form correctly" error (when no default value was set) or sent an empty subject.

Solution:
=========
Mark the field as `required` instead of `modelRequired`: it stays required for the user when visible, but when conditionally hidden it is disabled like any other non-model-required field and excluded from submission.

Steps to reproduce:
===================
1. Drop a Form snippet on a page (default action: Send an Email).
2. Edit the Subject field, set a visibility condition that is not met.
3. Save and submit the form.

=> "Please fill in the form correctly".

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

opw-6199682

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

**Steps to reproduce:**
- Accounting > Configuration > Settings > Default Accounts > Product Accounts
- Change the default expense account (and income account)
- Create a new product category
- category still proposed the old accounts

Affected versions: from 18.2 till 19.2

**Cause:**
`ir.default` for `product.category` (`property_account_expense_categ_id` and `property_account_income_categ_id`) was not updated when `res.company.expense_account_id` / `income_account_id` changed, so new categories kept using stale defaults.

and in 19.0
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L490
and
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L753
calls
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L1136-L1139

However, when stock_account is installed

https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/stock_account/models/res_company.py#L361-L366

this gets called, without calling super, that's why it didn't work although the fix is there, we will need to adapt another fix in 19.0+

**Solution:**
Call `_set_category_defaults()` in `res.company.write()` so `ir.default` stays aligned with the company's current product default accounts.

opw-6145491

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

Forward-Port-Of: odoo/odoo#261594

### Issue before this commit:
In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Go to Tax Report and visualize the Annual Tax Report (IT)
3. Go to VF VAT Report
4. See the VF25 is mixing taxes and balances

### Cause of the issue:
The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24).
https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299

It's just a typo in this commit: https://github.com/odoo/odoo/pull/164064/changes/f292ba119d6376dbfb3c1fac4960c9c56a74d938

### Reason to introduce the fix:
From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : 

> Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13.

opw-6172791

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

Forward-Port-Of: odoo/odoo#264379

## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#263792

this pr fixes 3 bug, as all are closely related.

  Step to reproduce (hide is_custom attr in kiosk mode):
  - have two attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B can have any two value ( ex. gender: male/female)
  - use it on a product  and make it available in POS for kiosk
  - start kiosk and open that product

  Observation:
  - we do not get option to select option from A but the heading is visible
  - when we select from B, Add to cart is disabled.

  Cause:
  - we do not allow attribute values with is_custom = True in kiosk
  - but we display the attribute regardless
  - the Add to cart btn depends on `selectedValues`, which requires
  value from each attribute, in this case, we are not seletion anything from A
  - so it is disabled

  Fix:
  - we introduced  `attributesToDisplay` which will hide heading in case of single
  custom value for any attribute
  - for Add to cart, wenow do not expect value from `is_custom`  attribute values.

 Allow product with 1 attr which is `is_custom` to be    configurable in configs other than kiosk: correct fix for [commit](https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7)
  Step to reproduce 
  - have attributes A
  - A has only 1 attribute value with is_custom = True
  - use it on a product and make it available in POS
  - start pos and open that product

  Observation:
  - we do not get option to select add text for A

  Cause:
  - in pos, we consider product to be configurable only it has more than 1
  attributes, which misses is_custom attr

  Fix:
  - we backport [commit](https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7) and also considers its side effect by introducing
  `isProductConfigurable` for pos_self_order, which will still avoid
  `is_custom` attrs for kiosk
  
    Empty page is displayed if product has only `is_custom` attribute value
    and other attribute with type other then 'no_variant' for combo item

   Step to reproduce
  - have attributes A and B
  - A has only 1 attribute value with is_custom = True
  - B has two values with type "always"
  - use it on a product and add that product in combo item and make it available
    in Kisok
  - start kiosk and open that combo and select that product

  Observation:
  - we do not get option to select

  Cause:
  - `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
     values in attributeSelection component.

  Fix:
  - before mounting Attributeselection component, we check if product has required
    attribute or not.


  [1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7

opw-6100965