## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277708
Forward-Port-Of: odoo/odoo#277425

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

# Step to reproduce
- Install eCommerce
- Activate dev mode with tests assets (important!)
- Go to the website & add a Countdow in the footer
- Add a new product from the website system tray
- Put any name & Save
- Go into Edit mode
- In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times)

> Note that the issue is quite inconsistent to reproduce
# Issue
A traceback is shown

# Cause
The only thing I'm sure of is that the error is caused by this code :
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20

And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and
WysiwygAdapter interaction :
https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60

But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment
in the associated PR for more information.

# Proposed Solution
Since this code is only used for this test :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15

And the test directly parses from the `window.localStorage` :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50

We can use `window.localStorage` instead of `browser.localStorage`  as it fixes the issue

opw-6246850

Forward-Port-Of: odoo/odoo#272736

Issue :-

Steps to Reproducet: SaaS 19.3
- Create a new database Install the Sale module.
- Create a product set some On Hand quantity for that product (via Inventory adjustment).
- Create a Quotation using that product.
- Confirm the quotation (turning it into a Sales Order).
- Open the Forecasted Report for that product.

The Reserve / Unreserve button in the Forecasted Report not render.
<img width="1811" height="323" alt="image" src="https://github.com/user-attachments/assets/4093bddb-f332-4b84-a482-a6604ebcb318" />

Regression from the OWL3 rendering context migration ("[REF] stock,*: run rendering context migration script"), which rewrote the template call `displayReserve(line)` into `this.displayReserve(line)`. https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae and it comes in 19.2 onwards version.

The previous bare call compiled to `ctx['displayReserve'](...)`, so the method executed with `this` bound to that render context, which does own `line` and `line_index`. The lookups resolved by accident, not by design. as far as i have known.

With the explicit [`this.`](https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae#diff-c556e01f9a3ebdb27bb6599d12b74c7bb0a433177cc0e126365cb763a874d9f4R81) form required by OWL3, `this` is correctly the component instance, so `this.line` and `this.line_index` are undefined:

```py
  - `this.line_index - 1 >= 0`    -> NaN >= 0 -> false, the block is
                                     skipped and `splittedLine` stays true
  - `this.lines[this.line_index]` -> undefined
  - `.includes(undefined)`        -> false, so `isOnHand()` is false
```
<img width="1404" height="786" alt="image" src="https://github.com/user-attachments/assets/6d2cb88b-a695-4388-9b5e-3eac266f1877" />

`displayReserve()` therefore always returns a falsy value and the `t-if` never renders the button. `isOnHand(line)`, which the template also calls directly to render the reservable quantity, is broken for the same reason.

Root cause: 
loop variables produced by `t-foreach`/`t-as` live only on the template render context and must never be read off `this` in a component method. The previous code depended on OWL2 resolving a bare template call against that context, which OWL3 no longer does.

``` with the displayReserve(line) ```
<img width="1185" height="599" alt="image" src="https://github.com/user-attachments/assets/ed79f6db-f95c-437f-baf8-f65391df14e7" />

```with the this.displayReserve(line)```
<img width="1020" height="641" alt="image" src="https://github.com/user-attachments/assets/61103db5-7e0a-4362-9dd4-c2f47db2bd97" />

Fix: 
derive the values from the `line` argument the methods already receive, instead of reading them off `this`.
```py
  - `displayReserve()`: `const line_index = this.lines.indexOf(line)`, and
    use the `line` argument in place of `this.line`
  - `isOnHand()` / `isReconciled()`: test against `line` directly, since
    `this.lines[line_index] === line` inside the loop
```
The template is unchanged: the OWL3-compliant `this.displayReserve(line)` call stays as the migration left it, and no method signature changes.

``` with the current fix```
<img width="1100" height="480" alt="image" src="https://github.com/user-attachments/assets/39147abb-ba5e-42ae-84f5-3d7cbadda1e1" />

<img width="1879" height="304" alt="image" src="https://github.com/user-attachments/assets/fafd3d6a-7591-4dbd-a85c-8fb9de541dd8" />


OPW:- 6363290


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

Steps to reproduce:
- Install `project`, open a project and switch to the Gantt view
- Start dragging a task while holding Ctrl (copy mode), then switch browser tab with Ctrl+Tab (or Ctrl+Shift+Tab, Ctrl+PgUp/PgDn)
- Come back to the Gantt tab and drop the task without holding Ctrl

Issue:
The task is duplicated instead of rescheduled.

Cause:
The copy/reschedule behavior is tracked through window keydown/keyup listeners on the Control key. While the document is hidden, the keyup for Control is never received, so the drag sequence resumes with a stale "Ctrl pressed" state and the drop is treated as a copy.

Fix:
Keyboard and pointer states cannot be reliably tracked while the document is hidden, so cancel any ongoing drag sequence from `makeDraggableHook` as soon as the tab is no longer visible (through the `visibilitychange` event). This applies to every drag and drop instance built on the hook builder.

opw-6298440

Forward-Port-Of: odoo/odoo#277014
Forward-Port-Of: odoo/odoo#276859

**Description of the issue/feature this PR addresses:**
----------------------------------------------
On mobile devices, the meeting view had two UI issues affecting the call
experience.
The call permission dialog could display an unwanted focus outline around
its content because the dialog body was focused on touch devices.
Additionally, meeting action buttons could be partially hidden,
especially in portrait mode, as the meeting view could extend beyond the
visible viewport height.

**Current behavior before PR:**
----------------------------------------------
- Opening the call permission dialog on mobile could show an unwanted
  focus outline around the dialog content
- Meeting action buttons could be partially hidden on mobile devices
- In portrait mode, the footer could overflow below the visible viewport


**Desired behavior after PR is merged:**
----------------------------------------------
- Call permission dialog opens on mobile without showing the unwanted
focus outline on main body.
- Meeting action buttons remain fully visible on mobile devices


Task-6232825

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

Forward-Port-Of: odoo/odoo#266620

**Steps to reproduce:**
1. Create a Sales Order.
2. Create a 50% down payment invoice.
3. Create a credit note for the down payment invoice.
4. Reset the credit note to Draft and cancel it.
5. Create the final invoice from the Sales Order.

**Issue:**
The final invoice is generated for 100% of the order amount, acting as if the down payment invoice does not exist.

**Expected behavior:**
The final invoice should only include the remaining 50% of the order amount because a valid 50% down payment invoice still exists.

**Why this happens:**
- The `price_unit` on the Sales Order's down payment line is manually updated during `action_post()` based on the sum of posted invoices minus posted credit notes.
- When the credit note is posted, `price_unit` drops to 0. However, when that credit note is subsequently reset to draft and cancelled, it triggers `button_cancel()` which only refreshed the line's display name and failed to recalculate `price_unit`. As a result, `price_unit` remained at 0 even though the credit note was no longer active, causing the final invoice to deduct nothing.

opw-6373578

Forward-Port-Of: odoo/odoo#277043
Forward-Port-Of: odoo/odoo#275684

Steps to reproduce:
- Install Argentina(l10n_ar) localization > Change Company
- Accounting > Customers > Invoices > Select an invoice > Click "Pay"
- In "Journal" select "Third Party Checks" > In "Payment Method" select "New Third Party Checks" > Fill the rest of the check info (Number, Bank Account, Issuer Vat, Payment Date and Amount) > Click on "Create Payment"
- Repeat the payment process for another invoice with same info > Validation Error

A change in [PR] caused the check uniqueness constraint apply to all checks. Because of this, using the same check number with the "New Third Party Checks" payment method now raises a validation error.

This is not the intended behavior. The uniqueness constraint should only apply to "Own Checks" when using a "Bank" journal for Vendor Bills. It should not apply to "Third Party Checks" with the "New Third Party Checks" payment method in Customer Invoice.

Avoid linking `l10n_latam_check_ids` on liquidity lines for outbound "Own Checks" payments so that the uniqueness constraint is enforced only for the "Vendor Bills".

[PR]: https://github.com/odoo/odoo/pull/243509/changes

opw-6334965

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

**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#276771
Forward-Port-Of: odoo/odoo#275294

Issue:
When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an amount of 0 is created. But, the 0 invoice is never emailed to the customer. Whereas, for orders where the total is more than 0, an invoice is created, then emailed to the customer. The customer should be emailed the invoice, even if its amount is 0.

Steps to reproduce:
1. Enable automatic invoicing.
2. Create a code for a 100% discount.
3. As a shopper, add a product to cart on the website.
4. While checking out, apply the 100% discount code to the order.
5. Complete the checkout.
6. Confirm that an invoice was created and posted, but was not emailed to the customer.

Explanation:
Normally, order confirmation and invoicing are handled by the `_post_process` method on the `payment.transaction` model. With automatic invoicing enabled, `_post_process` confirms the sale order, creates the invoice, and sends the invoice via `_send_invoice` (another method on the `payment.transaction` model). If `sale.async_emails` is enabled, `_post_process` will trigger a cron that invokes `_send_invoice` instead of invoking it directly.

When an order is fully covered by a reward, there's nothing to pay. In this case, no payment.transaction record is ever created, and `_post_process` never runs. Instead, the order is confirmed through the `_validate_order` method on the `sale.order` model. The `sale_loyalty` module extends `_validate_order` so that, with automatic invoicing enabled, it will create and post an invoice for zero-amount orders. But, nothing in this path ever calls `_send_invoice` or an equivalent. So, the invoice is created and posted but never sent.

Solution:
This adds logic for sending invoices to the extension of `_validate_order` in the `sale_loyalty` module. We mirror the logic used in `_send_invoice` in the `payment.transaction` model.

Notes:
There is duplicated code from `_send_invoice` in this fix. That is because `_send_invoice`, a method on the `payment.transaction` model, can't be used in this flow. A fix that avoids code duplication would require serious refactoring.

This will never trigger a cron to send the invoice, even if `sale.async_emails` is enabled. That is because the cron invokes `_send_invoice`. Since fully reward-covered orders are probably not common, any performance benefits of using a cron are probably not significant. But, making a new cron to be used in this case is also an option.

opw-6363334

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

Forward-Port-Of: odoo/odoo#275750
Forward-Port-Of: odoo/odoo#275190

# Step to reproduce
- Install eCommerce
- Activate dev mode with tests assets (important!)
- Go to the website & add a Countdow in the footer
- Add a new product from the website system tray
- Put any name & Save
- Go into Edit mode
- In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times)

> Note that the issue is quite inconsistent to reproduce
# Issue
A traceback is shown

# Cause
The only thing I'm sure of is that the error is caused by this code :
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20

And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and
WysiwygAdapter interaction :
https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60

But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment
in the associated PR for more information.

# Proposed Solution
Since this code is only used for this test :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15

And the test directly parses from the `window.localStorage` :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50

We can use `window.localStorage` instead of `browser.localStorage`  as it fixes the issue

opw-6246850

Forward-Port-Of: odoo/odoo#272736

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

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

Forward-Port-Of: odoo/odoo#270635
Forward-Port-Of: odoo/odoo#267781

**Steps to reproduce:**

- Create an attribute of type always, 2 values A and B for it
- The two values should have an extra price, like 100 for A and 150 for B
- Create an attribute of type dynamic, 2 values C and D for it
- C should have an extra price of 100 and 150 for D
- Make a product with both of those product, set the price to 100

2 possibilities:

- In the PoS, click the product, on the product popup, the price is 100
- This 100 is the product's price and does not change even if we change the values
- Order that product and buy it with variants A and C
- Click on the product again, the price is 300, which is correct
- When we click on D, the price is reset to 100, but should be 350

**Why the fix:**

When computing the popup's title, we try to get the current product based on the variants choices in the popup. If the product is found, we take that, because it means that it's already in the database.

https://github.com/odoo/odoo/blob/0d7f5058664b501779b833609468e535b34356bf/addons/point_of_sale/static/src/app/components/popups/product_configurator_popup/product_configurator_popup.js#L260

If we do not find it, we just take the product template, which does not contain the current extra prices, which is why we got a price of 100 in the exemple.

The product is not found because in the case of dynamic variants, the product is only created once it has been ordered at least once. Which means that for this newly created product, it is not yet in the database, so we take the product template instead of the product itself.

We now also add the extra price for a product if it is undefined, meaning it has not been found in the database yet.

We can't directly update the getter for the priceExtra, as it's also used to build the payload. As the rest of the code works fine with dynamic products with extra price the way it is sent now, we only change the title instead of changing the entire logic and computation.

opw-6326125

Forward-Port-Of: odoo/odoo#273411

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

## Current behavior:
In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative

## Expected behavior:
The VAT value in the minimum layer should be consistent with the upper layers and kept positive

## Steps to reproduce:
- Install l10n_vn (l10n_vn_reports will install as well)
- Switch to VN Company
- With demo data, go to Invoicing / Reporting / Tax Report
- Change Tax Report (VN) to Sales/Purchase Tax Report (VN)
- Unfold the lines all the way to the minimum layer: VAT on sales of goods and services 10% -> INV/2026/00003
- Observe that the VAT 10% line is at negative, which is inconsistent with the Total line below

## Cause of the issue:
- In Odoo, tax journal items store tax_base_amount with the accounting sign (negative for sales). This is expected behavior
- However, Vietnamese VAT listing expects commercial amounts, which means sales bases need to be displayed as positive numbers

## Fix:
Normalized tax_base_amount sign in _query_tax_lines function before building the SQL query

opw-6344577

Forward-Port-Of: odoo/enterprise#122785

### Description of the issue/feature this PR addresses:

- Opening Studio on a form containing a `Many2many` field using the `many2many_tags_email` widget crashes with an OWL prop validation error.

- **Steps to reproduce:**

1. Open any form view (e.g., Contacts) and enter `Studio`.
2. Create a new `Many2many` custom field on a model such as `res.partner` .
3. Set the field's widget to `many2many_tags_email` and save the customization.
4. Exit Studio and populate the field with one or more related records.
5. Open Studio again on the same form view.

This results in the following error:
```.js
Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined (should be a value)

```

### Current behavior before PR:

- When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag](https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js) component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an Invalid props for component 'RecipientTag' error.

### Desired behavior after PR is merged:

- `RecipientTag` should allow `onDelete` to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available.

opw:6395209

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

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `mrp` module
- Go to the setting enable `Lots & Serial Numbers` and `Storage Locations`
- Create a storable product tracked by Lots
- Configure a Putaway Rule for the product so it is stored in a
  sub-location
- Create a Bill of Materials for the product with at least one
  component
- Create and confirm a Manufacturing Order
- Increase the production quantity (e.g. using the "Change Production
  Quantity" wizard)
- Click **Generate Lot/Serial Number**
- Click **Produce All**

Issue:
------
Completing the Manufacturing Order raises:

    Invalid Operation
    You need to supply a Lot/Serial Number for product:
    - Product

even though a single lot should be sufficient for a lot-tracked
product.

Cause:
------
When the production quantity is increased, `change_prod_qty()` updates
the finished move's demanded quantity and re-reserves it through
`_update_finished_moves()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L77

which calls `_action_assign()` on the finished move:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L49

Since finished moves originate from the production location, they
bypass the normal reservation flow:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2070

`_action_assign()` then tries to reuse the move's existing move line,
but the lookup requires `location_dest_id` to still match the move's
generic destination:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2092-L2106

That existing line's `location_dest_id` was already redirected to the
putaway sub-location by the previous `_apply_putaway_strategy()` call
(at MO confirmation), so the lookup no longer matches and a second,
distinct move line is created and appended instead of the first one
being reused:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2170

Later, clicking **Generate Lot/Serial Number** creates a single lot and
stores it on the production order's `lot_producing_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1602

When **Produce All** is clicked, which trigger `button_mark_done()`  it calls
`_post_inventory()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L2227

which assigns that lot to the finished move through `move.lot_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1925

Since `lot_ids` is declared with `inverse='_set_lot_ids'`, this write
triggers that inverse method:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L192

The current implementation of `_set_lot_ids()` only assigns the lot to
a single available move line, regardless of tracking type:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L656-L668

Since only one lot is ever generated for a lot-tracked product, only
the first finished move line receives a `lot_id`. The second move line
created after increasing the production quantity is left without one.

When `button_mark_done()` validates the finished move lines, it
detects that one of them still has no lot assigned and raises the
"Invalid Operation" error, even though a single lot is valid for the
entire production of a lot-tracked product.

Fix:
----
`action_generate_serial` produces a single lot for the whole production.
In `_post_inventory()`, right after the generated lot is set on
the finished move, propagate it to any remaining lot-less move lines
of a **lot**-tracked finished move.

---

opw-6366060

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

Forward-Port-Of: odoo/odoo#275000

# Step to reproduce
- Install eCommerce
- Activate dev mode with tests assets (important!)
- Go to the website & add a Countdow in the footer
- Add a new product from the website system tray
- Put any name & Save
- Go into Edit mode
- In the Style tab, (un)toggle "Tax Indication" (may need to do it multiple times)

> Note that the issue is quite inconsistent to reproduce
# Issue
A traceback is shown

# Cause
The only thing I'm sure of is that the error is caused by this code :
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/website/static/tests/tour_utils/lifecycle_dep_interaction.js#L18-L20

And that it is linked to `browser.localStorage`. I suspect it is due to some weird localStorage and
WysiwygAdapter interaction :
https://github.com/odoo/odoo/blob/d6a08b67a948f569a1ca893b6337ce50b4ef9f07/addons/website/static/tests/tours/widget_lifecycle.js#L53-L60

But I can't be sure because debugging tools do not seem to be working. See the inverstigation comment
in the associated PR for more information.

# Proposed Solution
Since this code is only used for this test :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L14-L15

And the test directly parses from the `window.localStorage` :
https://github.com/odoo/odoo/blob/96a0a9a0332ae460973b6f01b461a0f7e3e2f7fa/addons/website/static/tests/tours/interaction_lifecycle.js#L50

We can use `window.localStorage` instead of `browser.localStorage`  as it fixes the issue

opw-6246850

Forward-Port-Of: odoo/odoo#272736

## Problem
When generating accrual entries for multiple sale orders, the stock variation lines would all show the same order name, even if the line belonged to a different sale order. This is caused by the `order` variable being reused from a previous loop.

## Solution
We will pull the order name directly from the order line in the current iteration.

## Steps to reproduce (Runbot v19)
1. Create a product with AVCO perpetual valuation
2. Make sure all accounts are configured properly (Income, Expense, Stock, and stock variation accounts)
3. Add units to the stock (it can be with an adjustment, as long as the product has a cost already set)
4. Create 2 separate sales orders for this product
5. Deliver both of the sales orders, do not invoice them
6. Now go to the Accounting App Review>Invoices to be issued
7. Select the 2 invoices that were created.

The Revenue accrual lines are correct, with each SO being referenced, but on the Stock variation lines, only the last SO selected will appear.

opw-6361032

Forward-Port-Of: odoo/odoo#277058

Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.

Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.

Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.

opw-6390207

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#124717
Forward-Port-Of: odoo/enterprise#122038

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Forward-Port-Of: odoo/odoo#276861

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

Forward-Port-Of: odoo/odoo#276774

## Current behavior:
In Vietnam's Sales Tax Report, when unfolding until the minimum layer, the VAT now displays the value in negative

## Expected behavior:
The VAT value in the minimum layer should be consistent with the upper layers and kept positive

## Steps to reproduce:
- Install l10n_vn (l10n_vn_reports will install as well)
- Switch to VN Company
- With demo data, go to Invoicing / Reporting / Tax Report
- Change Tax Report (VN) to Sales/Purchase Tax Report (VN)
- Unfold the lines all the way to the minimum layer: VAT on sales of goods and services 10% -> INV/2026/00003
- Observe that the VAT 10% line is at negative, which is inconsistent with the Total line below

## Cause of the issue:
- In Odoo, tax journal items store tax_base_amount with the accounting sign (negative for sales). This is expected behavior
- However, Vietnamese VAT listing expects commercial amounts, which means sales bases need to be displayed as positive numbers

## Fix:
Normalized tax_base_amount sign in _query_tax_lines function before building the SQL query

opw-6344577

When a knowledge article linked to an Annual report is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``accountant_knowledge`` module
- Go to Accounting > Review > Annual Report > Create a new annual report
- Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint 
"audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL:  Key (id)=(67) is still referenced from table "audit_report".
```

https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070
The garbage collector deletes trashed knowledge articles that match its domain.
Since this domain also includes articles linked to Annual Reports,
the cron attempts to delete records that are still referenced by annual report,
resulting in a foreign key violation error.

Solution:
Ensure linked audit reports are also deleted during knowledge article garbage collection.

sentry-7488793071

#### Description of the issue/feature this PR addresses:
On Thai-language documents, `res.currency.amount_to_text` (used e.g. for `account.move.amount_total_words` on invoice reports) renders amounts with satang as "หนึ่งร้อยห้าสิบ Baht และ ยี่สิบห้า Satang". Thai financial wording never uses the conjunction "และ" ("and") between the Baht and Satang parts — the standard format (cheques, tax invoices, Excel's BAHTTEXT) is "หนึ่งร้อยห้าสิบบาทยี่สิบห้าสตางค์". Confirmed by an Odoo translator on opw-6347437.

#### Current behavior before PR:
The Thai translation of the amount_to_text template keeps the English conjunction as "และ", producing incorrect Thai monetary wording such as "หนึ่งร้อยห้าสิบ Baht และ ยี่สิบห้า Satang".

#### Desired behavior after PR is merged:
The Thai msgstr no longer contains " และ ", so 150.25 THB renders as "หนึ่งร้อยห้าสิบ Baht ยี่สิบห้า Satang" (with native labels: "หนึ่งร้อยห้าสิบบาทยี่สิบห้าสตางค์"). The source term and all other languages are unchanged. Includes a regression test asserting Thai output has no "และ" and that English output keeps "and".

opw-6347437

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

Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`.

Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund`  with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound".

As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts.

This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document`

opw-6373124



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

Forward-Port-Of: odoo/odoo#276846

**Issue**
A credit note created before returning any stock may compute an incorrect COGS value.

**Steps to reproduce**
- Create a product valued with AVCO and a standard price of 10
- Create and confirm a SO for 2 units
- Create and post the invoice
- Change the product's standard price to 20.
- Create a credit note without returning the delivered stock
-> The cogs value on the credit note is 40 instead of 20

**Cause**
While posting the credit note:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale/models/account_move.py#L62
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/account/models/account_move.py#L5580
COGS lines are created:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L46
which needs to compute the unit_price:
https://github.com/odoo/odoo/blob/f715337f70bf7eaa8f084da6cd42d674d7a4bfe0/addons/stock_account/models/account_move.py#L132
which is initially computed from the original invoice line:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/account_move.py#L308-L317
However, the `sale_stock` override recomputes that value whenever the invoice line is linked to a sales order:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L173
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/sale_stock/models/account_move.py#L212-L213
This computation will give the standard price since:
- `is_returned` is True but no return move, which means there won't be any candidate:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L921-L923
- As a result, `qty_valued` is zero:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L933-L936
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/stock_valuation_layer.py#L172-L173
- The computation therefore falls back to the current standard price:
https://github.com/odoo/odoo/blob/844853be7956416c0cdcdeeb0d5f22422b528e5c/addons/stock_account/models/product.py#L938-L946

opw-6369550