### Issue
When receiving vendor bills that include bank details, if the partner has archived bank accounts, Odoo may attempt to update them. This leads to a duplicate key violation on `res_partner_bank` when the same account number already exists for the partner.

#### Affected versions
16.0 and later

#### Error example
```bash
2025-07-08 13:36:52,942 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Routing mail from "Client Name" <erp@odoo.com> to "M7- Odoo V17" <purchases@test.odoo.com>,purchases@test.odoo.com with Message-Id <*****.****.*****-****-*****-****.****@******>: direct alias match: ('account.move', 0, {'company_id': 1, 'move_type': 'in_invoice', 'journal_id': 10}, 1, mail.alias(6,))
2025-07-08 13:36:52,946 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Primary email missing on account.move
2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.sql_db: bad query: UPDATE "res_partner_bank" SET "acc_holder_name" = 'M7 GROUP INC.', "company_id" = NULL, "has_iban_warning" = false, "has_money_transfer_warning" = false, "sanitized_acc_number" = '1234567', "write_date" = '2025-07-08T13:36:52.897826'::timestamp, "write_uid" = 1 WHERE id IN (63)
ERROR: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.

2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.addons.account.models.account_move: Error importing attachment 'factur-x.xml' as invoice (decoder=_import_invoice_ubl_cii)
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 3219, in _extend_with_attachments
    with self.env.cr.savepoint():
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 85, in __exit__
    self.close(rollback=exc_type is not None)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in close
    self._close(rollback)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 113, in _close
    self._cr.flush()
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 137, in flush
    self.transaction.flush()
  File "/home/odoo/src/odoo/odoo/api.py", line 879, in flush
    env_to_flush.flush_all()
  File "/home/odoo/src/odoo/odoo/api.py", line 739, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/odoo/models.py", line 6362, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/odoo/models.py", line 6464, in _flush
    model.browse(ids)._write(vals)
  File "/home/odoo/src/odoo/odoo/models.py", line 4548, in _write
    cr.execute(SQL(
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#224248
Forward-Port-Of: odoo/odoo#223873

Issue
-----
The problem is when a subcontracted product has a component tracked by lots. Creating a receipt for the subcontractor, marking it as Todo then changing the quantity leads to the reception being impossible to validate because the lots for the components cannot be set from the move.

Steps to reproduce
-----
- Create a product (Comp1)
    - Tracked by lots
- Create a product (Prod1)
    - Add a BoM - Subcontracted - Flexible consumption - Set Comp1 as consumable
- Create a receipt for 2 Prod1
- Mark as Todo
- Set Quantity to 3
- Save
- Try to validate the receipt

Situation
-----
Before changing the quantity, the user has 2 buttons ("Record components" and the move's hamburger) which open the "Subcontract" wizard. This wizard is where they can set a lot/serial for the products.

When they change the quantity of the move, the inverse method of quantity is called

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/stock/models/stock_move.py#L170-L171

This method is overridden in the mrp_subcontracting module

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L75

The part that's important to our use case is

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L81-L82

Recording components leads us to create a backorder production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/mrp_production.py#L90-L91

In our specific use case, this is problematic because the subcontract wizard loads the form of the last production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L245

The user has no way to access the previous production which lacks lot/serial (other than opening the MO itself). Obviously, we don't want to mess with this flow, but there are 2 things we can do:

1. Avoiding weird cases such as this one by forcing the user to change the quantity through the appropriate wizard
2. Providing a link to the mrp.production once some production has been recorded

For the first point, the stock.move model already has a field we can use

https://github.com/odoo/odoo/blob/8c8449f51d5e327ccd2e4bb7c3c4868d51c6d619/addons/stock/models/stock_move.py#L180

We can just override the compute to fit our use case.

For the second point, there is already a button for this. The problem is that its display condition was changed in 9ca1064 to only show once the move is picked. This fix was a bit of an over correction because we also want to show the button for unpicked moves for which a production has been recorded.

-----
Ticket:
opw-4751896

Forward-Port-Of: odoo/odoo#219268

### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.  

### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.  

### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:

```xml
<cac:PartyTaxScheme>
    <cac:TaxScheme>
        <cbc:Name>TAX OFFICE NAME</cbc:Name>
    </cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.

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

Forward-Port-Of: odoo/odoo#223770

Versions
--------
- saas-18.2+

Steps
-----
1. Have a product with extra eCommerce images;
2. enable zoom-on-click on the product page;
3. add a recently-sold product carousel to the page;
4. click on an image to zoom in;
5. attempt to use arrow keys to navigate or using esc to exit zoom.

Issue
-----
Keys don't appear to do anything.

Cause
-----
Commit b8d0ab4275b24 set `oe_website_sale` as `snippet_classes` on the `s_dynamic_snippet_products` snippet, in order to enable the `websiteSaleTracking` widget, which uses this class as `selector`.

Issue is this class also gets used as the selector by the `WebsiteSale` widget which adds zoom-on-click event listeners. As there are two elements with the `oe_website_sale` class now, this widget gets called twice, and because the query selector selects all image elements on the sale page, images get duplicate event listeners assigned to them.

Consequently, clicking on an image opens two lightboxes, and the keys only impact the one hidden behind the other, making it appear as if key presses aren't doing anything.

Solution
--------
Instead of querying all images on the sale page in each call of the widget, only query for images in `this.el`.

opw-4908881

Forward-Port-Of: odoo/odoo#223231

> [!Note]
> This PR unreverts fc6b9ed22728 with a minor modification to ensure one `res.currency` record to compare amounts.

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: - 0.75 for quantity ≥ 0 - 0.50 for quantity ≥ 1000
   - Pricelist B with a -10% discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since e1b22257a714, `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

Forward-Port-Of: odoo/odoo#223548

When a user tries to apply an inventory adjustment with an accounting date, the system raises error.

**Steps to produce:-**
- Install the `Inventory` and `Accounting modules` with demo data.
- `Navigate to Inventory > Reporting > Stock`.
- Click the pencil icon next to a product that already has an on-hand quantity.
- Set an `Accounting Date` (any date)(if not showing accounting date then add from the column dropdown).
- `Modify the Quantity` and click `Apply`.

**Error:-**
`KeyError: 'name'`

**Root cause:-**
- The `_get_inventory_move_values` method in the `stock_account` module overrides the corresponding method from the base stock module. It attempts to modify the name.
- However, the parent method in the stock module was changed in [commit](https://github.com/odoo/enterprise/commit/d0c1e7845feeee1c2e85a21b5d40570d051458d3), and it no longer returns a 'name' key in its result dictionary.

**Solution:-**
- This fix adjusts the logic in `_get_inventory_move_values` to properly set
  `inventory_name` with the accounted date and user information.

**sentry-6791413899**

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

**Issue description:**
When creating a UBL credit note, a line with a zero unit price and a negative quantity would have its gross unit price calculated as `0.0 / <negative_qty>`. This results in a negative zero `-0.0`, which is considered an invalid negative net price by some EDI validators (e.g., Romanian CIUS-RO), causing the file to be rejected.

**Steps to reproduce:**
1. Create a Sales Order with two lines: one product for €100 and a second (e.g., a delivery service) for €0.
2. Create and pay a downpayment invoice for a fixed amount greater than the order total, e.g., €200.
3. Go back to the Sales Order and create a "Regular Invoice". This will generate a credit note with negative quantities on the lines.
4. Ensure the journal is configured for UBL export (e.g., CIUS-RO).
5. Post, then send the credit note and inspect the generated XML file. The zero-priced line will show `cbc:PriceAmount = '-0.0'`.

opw-5000314

Forward-Port-Of: odoo/odoo#223643
Forward-Port-Of: odoo/odoo#223074

[this](
https://github.com/odoo/odoo/commit/a9532d64c3f9c541f602979225a319ec89af5194#diff-f0beb94587c1e74a64245761f99c97af110a898c0da1b3b9f195b971ee284588L42-L43) commit remove the ``mute_until_dt`` formatting from from_settings which cause json serialzation issue and not letting login in database while dumping ``session_info`` as value can still exist database are coming from older version. For handling that adding back condtion to solve the issue and handle the ``mute_until_dt`` field formatting

**Note**: This issue won't reproduce on ``18.4`` instance but if database is coming from older version ``mute_until_dt`` will have  the value that will break
```py 
Traceback (most recent call last):
  File "<193>", line 199, in template_web_webclient_bootstrap_193
  File "<193>", line 181, in template_web_webclient_bootstrap_193_content
  File "<193>", line 149, in template_web_webclient_bootstrap_193_t_call_0
  File "<193>", line 24, in template_web_webclient_bootstrap_193_t_set_2
  File "/home/odoo/py_env/src/odoo/18.0/odoo/tools/json.py", line 57, in dumps
    return _ScriptSafe(json_.dumps(*args, **kwargs))
  File "/usr/lib/python3.10/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/usr/lib/python3.10/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.10/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib/python3.10/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type datetime is not JSON serializable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 2666, in __call__
    response = request._serve_db()
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 2169, in _serve_db
    return self._transactioning(
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 2233, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/service/model.py", line 176, in retrying
    result = func()
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 2200, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 2369, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/addons/base/models/ir_http.py", line 356, in _dispatch
    result.flatten()
  File "/home/odoo/py_env/src/odoo/18.0/odoo/tools/facade.py", line 83, in wrap_func
    func(self._wrapped__, *args, **kwargs)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 1472, in flatten
    self.response.append(self.render())
  File "/home/odoo/py_env/src/odoo/18.0/odoo/http.py", line 1464, in render
    return request.env["ir.ui.view"]._render_template(self.template, self.qcontext)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/addons/base/models/ir_ui_view.py", line 2463, in _render_template
    return self.env['ir.qweb']._render(template, values)
  File "/home/odoo/py_env/src/odoo/18.0/odoo/addons/base/models/ir_qweb.py", line 623, in _render
    result = ''.join(rendering)
  File "<193>", line 207, in template_web_webclient_bootstrap_193
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
TypeError: Object of type datetime is not JSON serializable
Template: web.webclient_bootstrap
Path: /t/t/t[1]/script/t
Node: <t t-out="json.dumps(session_info)"/>
```
opw - 5016301
upg - 3095362

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/746217ad6 [REL] 18.4.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/eaa43f6de [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426)
https://github.com/odoo/o-spreadsheet/commit/dd5bb2738 [FIX] Clipboard: clear useless function argument [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5a7c6fbd7 [FIX] clipboard: fix copy-paste from Excel [Task: 4730469](https://www.odoo.com/odoo/2328/tasks/4730469)
https://github.com/odoo/o-spreadsheet/commit/157d55c76 [FIX] menu: Fix menu item alignment [Task: 5028721](https://www.odoo.com/odoo/2328/tasks/5028721)
https://github.com/odoo/o-spreadsheet/commit/87e875b60 [FIX] Figure: icon of the menu item is not vertically aligned [Task: 4992687](https://www.odoo.com/odoo/2328/tasks/4992687)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

## Version
saas-18.4+

## Steps to reproduce
- Open the shop;
- Select any product;
- Open the Editor:
  - Select the product's main image;
  - Change the image width to either `100 percent` or `None`, then save;
- Click on `Add to cart`.

## Issue
Commit eac892a4ad7373d18f954afbbcd2f1213ac5f281 introduced a UI update that reorganizes the layout of the product configurator, placing the `Add to cart` button next to the form rather than below it.

Although the button remains inside the form in the original template, using the Editor to adjust the layout can result in the button being saved outside the `<form>` element in the final DOM.

This breaks the logic that relies on `closest('form')` to locate the surrounding form, since the button is no longer a descendant of the form element.

## Solution
Find the first product form relative to the button, since it may be a sibling rather than an ancestor in the DOM.

opw-4942986

See also:

- https://github.com/odoo/odoo/pull/218902

## Version
saas-18.4+

## Steps to reproduce
- Open the shop;
- Select any product;
- Open the Editor:
  - Select the product's main image;
  - Change the image width to either `100 percent` or `None`, then save;
- Click on `Add to cart`.

## Issue
Commit bbb2d98d9ab97ce729d59b9858b63daccf5434e2 introduced a UI update that reorganizes the layout of the product configurator, placing the `Add to cart` button next to the form rather than below it.

Although the button remains inside the form in the original template, using the Editor to adjust the layout can result in the button being saved outside the `<form>` element in the final DOM.

This breaks the logic that relies on `closest('form')` to locate the surrounding form, since the button is no longer a descendant of the form element.

## Solution
Find the first product form relative to the button, since it may be a sibling rather than an ancestor in the DOM.

opw-4942986

See also:

- https://github.com/odoo/enterprise/pull/90631