- Use the `init_storage` field attribute to initialize the stored computed
  column `l10n_co_edi_type`, `l10n_co_edi_cufe_cude_ref`, `l10n_co_edi_state`,
  `l10n_co_edi_operation_type`, `l10n_co_edi_commercial_state` directly in
  the database.

- This prevents Odoo from computing and writing the field for all existing
  `account.move` records when installing `l10n_co_edi`.

- This is particularly important for large databases with a high volume of
  Colombian accounting moves, where the initial computation can take too long
  and cause the module installation to hit the time limit.

- Keep the compute method unchanged so the field continues to be computed
  normally for subsequent record creation or dependency changes.

- Remove the `default` from `l10n_co_edi_commercial_state` since the
  `default` sets the field to `pending` while the compute sets it to
  `False` when no accepted EDI document exists. Move `pending` to
  `default_get` to preserve the current behavior while keeping the
  initialization consistent with the compute.

**opw-6451331**

Forward-Port-Of: odoo/enterprise#130808
Forward-Port-Of: odoo/enterprise#129507

With the abundance of tests we are accumulating, common test classes
have become the go to way to make test data readily available for all of
your module's tests and/or their dependent modules.

Unfortunately the cost of some of the `setUpClass` implementation has
also been rising as tests require more and more data.

As an example `AccountTestInvoicingCommon` which, with it's override of
`BaseCommon`'s `setUpClass` methods, is called 170 times during the
split from `account` to `auth_signup`.
With each call taking multiple seconds. This is a significant time loss
as (most of the time) the data generated is exactly the same from one
run to another.
(stats collected using `master-profile-setupclass-wbr` branch on runbot)

We realized the following:
 - We can run the whole test suite within a singular transaction without
   it being much more costly.
 - We could provide a way for common classes to define data that could
   be shared between test classes that share the same properties.

The changes only concern `odoo.tests.common.TransactionCase` and their
children.

### Transaction Strategy

Previously `TransactionCase`'s transactions would look like this:
(each box representing a transaction, with nested boxes being savepoints)
```
┌─ TestCaseA.setUpClass ─────────────────────────────────┐
│┌─ TestCaseA.setUp (test_foo) ─────────────────────────┐│
││  test_foo()                                          ││
│└──────────────────────────────────────────────────────┘│
│┌─ TestCaseA.setUp (test_bar) ─────────────────────────┐│
││  test_bar()                                          ││
│└──────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────┘
┌─ TestCaseB.setUpClass ─────────────────────────────────┐
│┌─ TestCaseB.setUp (test_baz) ─────────────────────────┐│
││  test_baz()                                          ││
│└──────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────┘
```

This will also be the case if no `setUpCommonData` is defined on your test class.

However, if `setUpCommonData` IS defined on your class, or a parent class, the
following plan will be executed instead:
Sample python code
```python
from odoo.tests.common import TransactionCase

class ModuleCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.data = cls.env['module.model'].create({'foo': 'bar'})

class ModuleTestA(ModuleCommon):
    def test_bar(self):
        self.assertEqual(self.data.foo, 'bar')

class ModuleTestB(ModuleCommon):
    def test_foo(self):
        self.data.foo = 'foo'
        self.assertEqual(self.data.foo, 'foo')

class ModuleCommonExtended(ModuleCommon):
    @classmethod
    def setUpCommonData(cls):
        cls.data_2 = cls.env['module.model'].create({'foo': 'baz'})

class ModuleTestC(ModuleCommonExtended):
    def test_baz(self):
        self.assertEqual(self.data.foo, 'bar')
        self.assertEqual(self.data_2.foo, 'baz')
```
```
┌─ ModuleCommon.setUpCommonData ───────────────────────────┐
│                                                          │
│┌─ ModuleTestA.setUpClass ───────────────────────────────┐│
││┌─ ModuleTestA.setUp (test_bar) ───────────────────────┐││
│││  test_bar()                                          │││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
│                                                          │
│┌─ ModuleTestB.setUpClass ───────────────────────────────┐│
││┌─ ModuleTestB.setUp (test_foo) ───────────────────────┐││
│││  test_foo()                                          │││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
│                                                          │
│┌─ ModuleCommonExtended.setUpCommonData ─────────────────┐│
││┌─ TestCaseC.setUpClass ───────────────────────────────┐││
│││┌─ TestCaseC.setUp (test_baz) ───────────────────────┐│││
││││  test_baz()                                        ││││
│││└────────────────────────────────────────────────────┘│││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────┘
```

### Class selection and dependency strategy

One of our goals for `setUpCommonData` is that it could pretty much be a
drop-in replacement for `setUpClass`.
As indicated by the schema above however, it is not really compatible with our
new system, we want to be able to single out `setUpCommonData` for tests that
rely on that singular common class, which is why calling `super` is NOT allowed
within `setUpCommonData` (or at least calling `super().setUpCommonData`).
We take care of picking the class on which to call `setUpCommonData` and for
you, while the order is defined by the test class's `__mro__`.

Some common classes also provide methods that can be overwritten to change the
data generated by `setUpClass`, for which we provide the decorator
`odoo.tests.common.data_depends`.
`data_depends` takes a list of strings that are used as attributes to generate
a hash for our class; these can be regular attributes or methods (note that we
do not call the method, we simply store the reference to it).

The hash key for a class is defined as follows:
```python
tuple(
    tuple(
        Type[TransactionCase], # The class that defined `setUpCommonData`
        Tuple[Any], # The dependency data
        Type[TransactionCase], # The class that will be used to call `setUpCommonData`
    ),
    ...
)
```
The dependency data is built by iterating over the `__mro__` of said class and
adding each new definition for each attribute defined by `@data_depends`.

The class to install is the first class in the `__mro__` which has different
dependency data, with the added condition that it must be a subclass of the
previous installed class if there is one.

Consider the following:
```python
from odoo.tests.common import TransactionCase, data_depends

class ModuleCommon(TransactionCase):
    _name = 'foo'

    @data_depends('_name')
    @classmethod
    def setUpCommonData(cls):
        cls.data = cls.env['module.model'].create({'name': cls._name})

class ModuleTestA(ModuleCommon):
    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)

class ModuleTestB(ModuleCommon):
    _name = 'bar'

    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)

class ModuleTestC(ModuleCommon):
    _name = 'bar'

    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)
```

Whilst all classes share the exact same `__mro__`, their dependencies differ.
This will of course cause a split as all test can not be ran within the same
transaction/savepoint.

```
┌─ ModuleCommon.setUpCommonData (_name = 'foo') ───────────────────────────────┐
│                                                                              │
│┌─ ModuleTestA.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestA.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
┌─ ModuleCommon.setUpCommonData (_name = 'bar', install on ModuleTestB) ───────┐
│                                                                              │
│┌─ ModuleTestB.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestB.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
┌─ ModuleCommon.setUpCommonData (_name = 'bar', install on ModuleTestC) ───────┐
│                                                                              │
│┌─ ModuleTestC.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestC.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
```

The system takes care of organizing and ordering tests in a way to reuse data as
much as possible (according to the dependencies defined on the tests).
NOTE: While we do re-order tests we still follow `test_sequence` if defined.

#### Edge cases

A)
Consider the following:
```python
from odoo.tests.common import TransactionCase

class ModuleACommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.module_a_data = cls.env['module_a.model'].create({'name': 'foo'})

class ModuleBCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.env = cls.env(context={'some_context': 'bar'}) # This could be creating+changing company
        cls.module_b_data = cls.env['module_b.model'].create({'name': 'bar'})

class ModuleCTestA(ModuleACommon, ModuleBCommon):
    def test_data(self):
        self.assertEqual(module_a_data.name, 'foo')

class ModuleCTestB(ModuleACommon, ModuleBCommon):
    def test_data(self):
        self.assertEqual(module_b_data.name, 'bar')
```

`ModuleCTestA` and `ModuleCTestB` actually share the same `__mro__` _AND_
dependencies.
In this case we can also note that `ModuleBCommon` will have an impact on
`ModuleACommon` due to changing the environment (according to `__mro__`).

This is the reason we include the install class in our hash key, the
dependencies would otherwise be the exact same between our test cases, but we
in fact need to know which class the data was installed upon to make sure the
data is available.

```
┌─ ModuleBCommon.setUpCommonData (install on ModuleCTestA) ───────┐
│┌─ ModuleACommon.setUpCommonData (install on ModuleCTestA) ─────┐│
││                                                               ││
││┌─ ModuleCTestA.setUpClass ───────────────────────────────────┐││
│││┌─ ModuleCTestA.setUp (test_data) ──────────────────────────┐│││
││││  test_data()                                              ││││
│││└───────────────────────────────────────────────────────────┘│││
││└─────────────────────────────────────────────────────────────┘││
│└───────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
┌─ ModuleBCommon.setUpCommonData (install on ModuleCTestB) ───────┐
│┌─ ModuleACommon.setUpCommonData (install on ModuleCTestB) ─────┐│
││                                                               ││
││┌─ ModuleCTestB.setUpClass ───────────────────────────────────┐││
│││┌─ ModuleCTestB.setUp (test_data) ──────────────────────────┐│││
││││  test_data()                                              ││││
│││└───────────────────────────────────────────────────────────┘│││
││└─────────────────────────────────────────────────────────────┘││
│└───────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
```

B)
Consider the following:
```python
from odoo.tests.common import TransactionCase

class ModuleCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.data = {
            'company': cls.env['res.company'].create({'name': 'test'})
        }

class ModuleTestA(ModuleCommon):
    test_sequence = 0
    def test_foo(self):
        self.data['company'] = self.env['res.company'].create({'name': 'test_2'})

class ModuleTestB(ModuleCommon):
    test_sequence = 1
    def test_bar(self):
        self.assertEqual(self.data['company'].name, 'test')
```

The above code will actually result in a cache error; the company referenced
within `cls.data` does not exist anymore.
It is also not possible to add a dependency on `setUpCommonData` as `data` does
not exist outside of running the tests.
It is not recommended to use dictionaries within `setUpCommonData` (or use
frozen ones) as they can not be rollbacked, one should stick to orm records.

A meeting held in Discuss left no trace outside of its own channel: whoever
just spent an hour on a call had to write that fact down by hand on the lead
or the task it was about.

A discuss.call.history can now be tied to a mail.activity, the way a voip.call
already is. It happens on its own when the meeting was planned from a document:
the call taking place in it is logged on the activity that planned it, so that
marking that activity done posts "Meeting done (1h 23m 45s)" in the chatter of
that document, linking back to the call and telling whether it was recorded and
transcribed. A call nobody planned is logged by hand from the Call History,
through the wizard voip contributed and mail now owns.

The duration wording shared by both call models moves to mail.tools.call, and
ai contributes the transcript icon to that message the way it already does for
a voip.call.

Join Meeting opens the Discuss channel of the meeting for an attendee who is
already a member of it, instead of navigating away to the invitation link.



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

Description of the issue/feature this PR addresses:

The "Computed Arch" debug dialog displays the fully computed view architecture, after inheritance, xpaths and studio customizations have been applied, in a read-only pre block. Extracting that text previously required manually selecting it in the browser, which is unreliable for long or deeply indented XML.

Being able to copy this text to the clipboard helps with several common scenarios:

- Debugging inherited views: when a view looks wrong and it is not clear which of several inheriting modules caused it, the computed  arch can be diffed against the base view's arch to see exactly what  changed.
- Writing new xpath inherit rules: the exact final structure (attribute values, node ordering) is needed to write a correct
  expr="//field[@name='x']", which is easier to do in a scratch file or  editor with search than by eyeballing a read-only dialog.
- Bug reports and support tickets: the computed arch can be pasted into a Slack message, GitHub issue or support ticket so others can  inspect the view without needing access to the database.
- Studio customizations: consultants often need the underlying  computed arch to understand why a Studio-added field appears in an unexpected position.
- Comparing environments: the arch from a customer's staging instance can be diffed against production to spot config drift, e.g. a view customization made directly on prod.


Current behavior before PR:

In the "Computed Arch" debug dialog, the only way to get the arch text out of the browser is to manually click-drag to select it inside the pre block, then copy it. This is error-prone for long or deeply indented XML, where whitespace and line breaks are easy to select incorrectly or truncate.


Desired behavior after PR is merged:

A "Copy Arch" button is added next to "Close" in the dialog's footer. Clicking it copies the full computed arch to the clipboard in one click, with a brief "Copied" confirmation, removing the need to manually select the text.

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

Forward-Port-Of: odoo/odoo#286894
Forward-Port-Of: odoo/odoo#286619

A meeting held in Discuss left no trace outside of its own channel: whoever
just spent an hour on a call had to write that fact down by hand on the lead
or the task it was about.

A discuss.call.history can now be tied to a mail.activity, the way a voip.call
already is. It happens on its own when the meeting was planned from a document:
the call taking place in it is logged on the activity that planned it, so that
marking that activity done posts "Meeting done (1h 23m 45s)" in the chatter of
that document, linking back to the call and telling whether it was recorded and
transcribed. A call nobody planned is logged by hand from the Call History,
through the wizard voip contributed and mail now owns.

The duration wording shared by both call models moves to mail.tools.call, and
ai contributes the transcript icon to that message the way it already does for
a voip.call.

Join Meeting opens the Discuss channel of the meeting for an attendee who is
already a member of it, instead of navigating away to the invitation link.

https://github.com/odoo/odoo/pull/285269

Changing the notification preference silently promoted a light user to a regular user, granting them access rights they were never meant to have.

Steps to reproduce:
- log in as a light user (light/light)
- open My Profile
- in Preferences, switch "Notification" from "Email" to "Odoo"
- log back in as an administrator and open that user's form
- the Role field now reads "User" instead of "Light"

The notification preference is not a plain field: choosing "Odoo" puts the user in a dedicated technical group. That group grants no access right of its own, but a user is considered light only as long as every group they hold is explicitly known to be a light one. Since this group was never declared as such, it was treated like any ordinary access group, which was enough to have the user reclassified as regular.

This commit declares the group as a light one, so the preference stays a preference and no longer affects the user's role. A regression test covers both directions of the toggle for a light and a regular user, checking the role, the underlying group and the role search filter.

Note that existing databases need a `mail` upgrade to clear the stale link.

Task-6575413

Forward-Port-Of: odoo/odoo#288646

`areItemsWrapping` decides whether the statusbar buttons fit on one line by comparing `getBoundingClientRect()` heights. Those rects are rounded to physical pixels, so depending on the zoom/DPI ratio a single-line height can come out a fraction of a pixel taller than the reference button height, even though nothing actually wraps.

That false positive made the whole statusbar collapse into a single dropdown at some (but not all) browser zoom levels, most noticeable on high-DPI screens where OS scaling and browser zoom combine into non-integer ratios.

Steps to reproduce:
1. On a high-DPI screen (e.g. 4K) with OS display scaling enabled.
2. Open any record with a statusbar field (e.g. a CRM opportunity).
3. Set the browser zoom to a value close to 100%.
4. The statusbar collapses into a single "More" dropdown instead of showing every stage inline, even though there is enough room.

Round both heights before comparing to ignore that sub-pixel noise while still detecting genuine wrapping.

Regression introduced by 7e77b99d2845.

task-6545990

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

When we save a sale order just after reordering its sale order lines, there's a chance that an error is thrown

Steps to reproduce:
1. Install Sales
2. Go to Sales and open any quotation that has multiple sale order lines
3. Reorder a sale order line and immediately save (there's more chance to reproduce if you have a lot of sol and if you use the shortcut `ALT + S`)
4. An error is thrown

Issue:
It is possible that the save takes place during the execution of super.sortDrop. This reassigns the id of all the records in this.props.list.records
Therefore, calling `_handleQuantityAdjustment` with the recordMap computed before the save uses an id that has disappeard from this.props.list.records so we cannot find it at
https://github.com/odoo/odoo/blob/4973903252865a6a7a2da235bc3a01675dbbff4d/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L263
which eventually throws an error

Solution:
Suspend any save mechanism when sortDrop starts and resume it when sortDrop has finished

opw-6483206

Forward-Port-Of: odoo/odoo#288370
Forward-Port-Of: odoo/odoo#286787

### Description of the issue/feature this PR addresses:
This PR fixes a server crash in the Peruvian localization (l10n_pe_reports_lib) that occurs when generating the "Inventory and Balance" General Ledger report. The crash is triggered by strict validation rules within Python's csv module, which rejects the custom line terminator used to fulfill the SUNAT PLE formatting requirements.

### Current behavior before PR:
When a user attempts to generate and export the "Inventory and Balance" report, the server crashes with a ValueError: bad delimiter or lineterminator value. This happens because the csv.DictWriter is initialized with lineterminator='|\n' to ensure every row ends with a pipe. Python's underlying csv implementation rejects this, as it expects standard line endings (\r, \n, or \r\n) and throws an error if the delimiter character (|) is included in the terminator string.

### Desired behavior after PR is merged:
The "Inventory and Balance" report generates successfully without server errors. The code now uses the standard lineterminator='\n' to satisfy Python's validation rules. To maintain the mandatory trailing pipe (|) at the end of each row required by SUNAT, a dummy empty column (['']) is appended to the field names with restval=''. This prompts the writer to naturally append the final pipe as a column delimiter before the newline, resulting in the exact |\n output format required, safely and reliably.

opw-6509674

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

Forward-Port-Of: odoo/enterprise#131302
Forward-Port-Of: odoo/enterprise#129636

When a recurring product (with `allow_one_time_sale = True`) is sold as a one-time purchase (no subscription plan), the stock forecast report and replenishment logic incorrectly treat it as an active subscription. This results in infinite projected future outgoing moves for standard sales.

This occurs because the logic only checks if `recurring_invoice` is True on the product, ignoring whether the parent order actually has a `plan_id`.

This commit fixes the issue by:
1. Updating `_get_stock_subscription_lines` in `sale.order.line` to filter out lines using `_subscription_is_one_time_sale()`.
2. Updating the domains in `stock.forecasted_product_product` to require `order_id.plan_id != False` for subscription forecasts, while correctly routing one-time sales (`order_id.plan_id == False`) back to the standard sale domain.
3. Adapting existing tests to verify that one-time sales do not generate future subscription stock forecasts.

Task-6193648

Forward-Port-Of: odoo/enterprise#128018
Forward-Port-Of: odoo/enterprise#116889

### Issue:
When a bank account is manually set on a bill for a partner with multiple bank accounts, using the Auto-Complete feature could reset the manual selection even without a currency change

### Cause:
When `invoice_vendor_bill_id` is set, an onchange assigns `currency_id` unconditionally, even when it is the same value
This triggers `_compute_partner_bank_id`, which always recomputes the best matching bank account from scratch without considering the currently set value
If the currency did not change, this recompute is unnecessary and silently overrides the manual selection

### Steps to reproduce:
- Install `account`
- Create a Vendor with 2 bank accounts (keep default values to have equal priority on all accounts)
- Create and post a Bill for this vendor with at least one line
- Create a new Bill for the same vendor
- Set the Recipient Bank to the second account in the list
- In Auto-Complete, select the first Bill
 
Before the fix, the Recipient Bank is reset to the first account

opw-6210414

Forward-Port-Of: odoo/odoo#288386
Forward-Port-Of: odoo/odoo#283479

Steps to reproduce:
- Colombian company with DIAN electronic invoicing enabled in PoS
- On the company contact, set more than one obligation type (e.g. O-13, O-15 and O-23)
- Open a PoS session, sell a product and pay

Issue:
The order fails to sync with "Expected singleton:
l10n_co_edi.type_code(x, y, z)" as soon as the DIAN document is accepted, and the receipt cannot be printed. On 18.0 to saas-19.1 the same crash happens when the receipt data is generated for printing.

Cause:
`_compute_l10n_co_edi_pos_receipt_data` fills
`obligation_type_description` by reading `description` directly on `l10n_co_edi_obligation_type_ids`, which is a many2many. The read only works when the company carries exactly one obligation type, while a Colombian company commonly has several (they are all sent to the DIAN in `TaxLevelCode`).

Fix:
Join the descriptions of all obligation types, the same way the DIAN invoice PDF report already does.

opw-6576523

Forward-Port-Of: odoo/enterprise#131747

The "Outstanding credits" or "Outstanding debits" sections of a Credit Note or Vendor Bill will overflow when the "Bill Reference" is too long.

We resolve this by applying the text-truncate class.

Steps to Reproduce:
1. Create a new 19.0 db and load demo data.
2. Accounting -> Vendors -> Refunds -> RBILL/2026/09/0001
3. Click the entry in the Outstanding credits section.
4. Enter a long "Bill Reference" value, e.g. asdf asdfasfasdfasdfasdfasdfasdfasdfasdfasdfasdf.
5. Go back to the Credit Note and observe the text overflow.

opw-6558982

<img width="1254" height="1162" alt="bill_reference_long" src="https://github.com/user-attachments/assets/8c762b50-65a8-44bf-9a28-bd34887d5928" />

<img width="1620" height="1294" alt="overflow" src="https://github.com/user-attachments/assets/f5c47404-fb7f-4715-8815-cabe5dda3805" />

<img width="1586" height="1159" alt="truncated" src="https://github.com/user-attachments/assets/2a80f656-0a12-4805-9c1d-fd20379655ce" />

Forward-Port-Of: odoo/odoo#288389

## Problem

When rendering PDF invoices that contain **section** or **note** lines, the `l10n_gcc_invoice.arabic_english_invoice` QWeb template raises:

```
TypeError: argument of type 'bool' is not iterable
```

This happens because `account.move.line` records of type `line_section` or `line_note` have `name = False`. The template evaluates `arabic_name not in line.name` (and the same for `english_name`), which fails because Python cannot apply the `in` operator on a boolean value.

## Fix

Add a `line.name and` guard before each `not in` check:

```xml
<!-- Before -->
<span t-if="arabic_name not in line.name" .../>
<span t-if="(english_name != arabic_name) and (english_name not in line.name)" .../>

<!-- After -->
<span t-if="line.name and arabic_name not in line.name" .../>
<span t-if="line.name and (english_name != arabic_name) and (english_name not in line.name)" .../>
```

## Steps to reproduce

1. Install `l10n_gcc_invoice` on an Odoo 16.0 instance.
2. Create a customer invoice and add a **Section** line.
3. Print/preview the invoice PDF.
4. Observe `Internal Server Error` / `TypeError: argument of type 'bool' is not iterable`.

Forward-Port-Of: odoo/odoo#278887
Forward-Port-Of: odoo/odoo#267147

## Description of the issue

When an Argentinian invoice contains advance-payment deduction lines that exactly cancel the product lines (net taxable base = 0 for a given VAT aliquot), the invoice is rejected by the ARCA (AFIP) WSFE web service with:

> **Error 10018**: "Si ImpIva es igual a 0 el objeto Iva y AlicIva son obligatorios. Id iva = 3 (iva 0)"

This is the standard "100% down payment" flow: the customer is invoiced an advance for the full amount, and the final invoice deducts that advance, resulting in a $0 invoice that must still be validated against ARCA.

This is a forward-port to 19.0 of #270846 (same fix, targeted at 18.0, closed unmerged). The bug is still present in 19.0: `_get_vat()` in `addons/l10n_ar/models/account_move.py` evaluates its filter on the raw unrounded aggregated floats.

## Steps to reproduce

1. On a company with the Argentinian localization (`l10n_ar_edi`) configured for electronic invoicing (WSFE), create a sale order with one or more product lines taxed at IVA 21% (e.g. total $121,000).
2. Create a **down payment invoice for 100%** of the order and validate it against ARCA (this one succeeds).
3. Create the final invoice from the sale order: it contains the product lines (positive) and the down-payment deduction line (negative), both at IVA 21%. Total to pay: **$0.00**.
4. Confirm the invoice and send it to ARCA.
5. **Current behavior (bug):** ARCA rejects the request with error 10018. Inspecting the generated WSFE request shows `ImpNeto=0.0`, `ImpIVA=0.0`, `ImpTotal=0.0` and an `Iva` block containing an all-zero aliquot, e.g. `{'AlicIva': [{'Id': '5', 'BaseImp': 0.0, 'Importe': 0.0}]}` — instead of `Iva: null`.
6. **Expected behavior (after fix):** no zero-amount aliquot is sent (`Iva` is `null`) and ARCA approves the $0 invoice.

## Root cause

In `_get_vat()`, the positive product lines and the negative down-payment deduction line share the same VAT aliquot, so the aggregation by `vat_afip_code` nets the group to zero. However, floating-point accumulation in the aggregated tax details leaves a tiny residual (~1e-12) in `base_amount_currency` / `tax_amount_currency`. The filter condition checks the **raw unrounded** values:

```python
if grouping_key['vat_afip_code'] not in (False, '0', '1', '2') and (values['base_amount_currency'] or values['tax_amount_currency']):
```

The ~1e-12 residual is truthy in Python, so the aliquot entry is kept — even though both `BaseImp` and `Importe` are rounded to `0.00` two lines below when building the entry. The WSFE request therefore carries a non-null `Iva` block with all-zero amounts, which ARCA rejects with error 10018.

## Fix

Round `BaseImp` and `Importe` to 2 decimals **before** evaluating the filter condition, so an aliquot whose amounts cancel out is excluded from the `Iva` array (the same rounded values are then reused when building the entry, keeping the sent amounts unchanged for every other case):

```python
base_imp = float_round(amount_sign * values['base_amount_currency'], precision_digits=2)
importe = float_round(amount_sign * values['tax_amount_currency'], precision_digits=2)
if grouping_key['vat_afip_code'] not in (False, '0', '1', '2') and (base_imp or importe):
```

Behavior is unchanged for every invoice whose aliquots round to a non-zero base or tax amount.

---

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

Forward-Port-Of: odoo/odoo#286005

Issue:
Editing the Project task Kanban with Studio fails with an "element cannot be located in parent view" error.

This affects Kanban views whose card architecture is provided through `card_id`. Adding or removing a field produces an XPath targeting the inlined `<card>`, but that node cannot be found when the Studio customization is saved.

Steps to reproduce:
* Open Project > Tasks > My Tasks in Kanban view.
* Open Studio.
* Add or remove a field from the card.

Cause:
The client receives a postprocessed Kanban architecture in which the view referenced by `card_id` has already been appended as a `<card>` node:

https://github.com/odoo/odoo/blob/1aa1f1967c7b9c8fd2c941fbc0c7b4c563698e46/odoo/addons/base/models/ir_ui_view.py#L3138-L3140

Studio therefore generates paths containing `/kanban/card`. However, Studio normalization applies those paths to the pre-postprocessed architecture, which still contains only the `card_id` attribute:

https://github.com/odoo/enterprise/blob/42aa8fafdef159476d708f91467cba6f7fb2c6d3/web_studio/models/ir_ui_view.py#L667-L671

As `<card>` does not exist in that source tree, the inheritance engine cannot locate the target.

Solution:
We need to inline the referenced card before applying or normalizing Studio customization specifications.

This makes Studio operate on the same architecture shape that was presented to the client. The `card_id` attribute is then removed from that temporary source to prevent regular post processing from appending the card a second time.

The behavior is limited to Studio customization views and is a no op for Kanban views without `card_id`, preserving the existing inheritance flow for other views.

opw-6445398

Forward-Port-Of: odoo/enterprise#127393

# How to reproduce
- Go to Sign > Templates
- Upload a PDF & click on Share
- Copy the link
- Go to a page with a EditInBackend systray item (e.g. a Product or Event page)
- In the editor, add the copied link to a button or some text
- Save
- While still in editor mode, click the link

# The issue
A traceback is shown

# Cause
The traceback is caused by the call to this function : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L336

In our case, `this.currentWebsite.metadata.mainObject` is undefined, so trying to access `.model` throws. `mainObject` is undefined because the sign link opens an XML file, which does not have any metadata associated to it :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L150-L155

The call to `getUserModelName` is done by the `EditInBackendSystrayItem` component which subscribes to the "CONTENT-UPDATED" event : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/edit_in_backend.js#L33

However, this method should not be called by the bus because the sign page does not have this systray item. The issue is, the display of the component is managed by the `WebsiteSystrayItem`, based on the `hasEditableRecordInBackend` getter :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.js#L10 https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.xml#L9

And the re-render of that component that would remove the `EditInBackendSystrayItem` component is triggered by a call to `renderAndAdapt`, which is also subscribed to "CONTENT-UPDATED" : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/components/navbar/navbar.js#L48

So the destroy of the `EditInBackendSystrayItem`, which should remove the listener that calls `getUserModelName` is trigerred AFTER the call to that function is already done

opw-6443794

Forward-Port-Of: odoo/odoo#281763

**Steps to reproduce:**
* Install the **Manufacturing** module with **Work Orders** enabled.
* Create and confirm a Manufacturing Order with at least one Work Order.
* Open the **Shop Floor** view.
* On a work order card, click the **gear** icon to open the menu dialog.
* Click **Open Manufacturing Order** on a slow network connection.
* Before the MO form view finishes loading, quickly click the **gear** icon again and open another dialog (e.g. Log Note).
* The MO form view loads, destroying the shop floor component.
* Close the Log Note dialog.

**Observed behavior:**
* An `UncaughtPromiseError: Component is destroyed` error is thrown because the dialog tries to interact with the shop floor component that has already been destroyed by the navigation to the MO form view.

**Cause:**
* When the user clicks "Open Manufacturing Order", `doAction` is called to navigate to the MO form view, and `props.close()` immediately closes the menu dialog. However, the shop floor component is still visible while the new view is loading.
* During this gap, the gear button remains clickable. If the user opens another dialog (e.g. Log Note), that dialog holds a reference to the shop floor component. When the MO form view finishes mounting, the shop floor is destroyed, and closing the stale dialog triggers operations on the destroyed component.

**Fix:**
* Add an `actionPending` state flag to `MrpDisplayRecord`. When the user selects "Open Manufacturing Order" from the menu dialog, an `onSelect` callback sets `actionPending` to `true`, which disables the gear button and prevents any new dialog from being opened.
* The flag is only set for `openMO` (which navigates away and destroys the component), not for other menu actions like Scrap, Add Component, or Log Note which open wizard dialogs and return to the shop floor.

opw-6107579

Forward-Port-Of: odoo/enterprise#131538
Forward-Port-Of: odoo/enterprise#123490

**Issue**
When rental transfers are enabled and rental pickups/returns are processed through stock pickings, it may become impossible to perform a subsequent rental return through the rental return wizard.

**Steps to reproduce**
- Activate "Rental Transfers" in the settings
- Create a rental product P, tracked by serial number
- Create two serial numbers for P
- Create and confirm a rental order for 2 units of P
- Validate the pickup transfer
- Partially validate the return transfer without creating a backorder
- Open the rental order and click on "Return" 
-> The return wizard opens without any available serial number and validation fails with a serial number-related error.

**Cause**
When clicking on "Return", if there is no pending pickup/return transfer: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/models/sale_order.py#L62-L68 the rental return wizard is opened directly:
https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/models/sale_order.py#L316 No serial number is prefilled in the wizard because `returned_lot_ids` is empty: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L122-L124 This is because `returnable_lot_ids` is empty as well. `returnable_lot_ids` is computed while generating the wizard lines: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L38 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L47-L48 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L99-L106 and `returnable_lots` is empty because both `pickedup_lots` and `returned_lots` are. Those fields are currently only populated through the rental wizard flow: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L42-L43 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L160-L161 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L166-L167

Since this flow uses stock pickings instead of the rental wizard, those fields are never updated, preventing the wizard from determining any returnable serial number.

opw-6150305

Forward-Port-Of: odoo/enterprise#127590
Forward-Port-Of: odoo/enterprise#119257

### Issue before this commit:
When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the numbers were correctly translated to Turkish, the currency subunit label was fetched using the customer's language. This resulted in a partially translated string (like "... SIFIR CENTS") instead of the expected fully Turkish text (like "... SIFIR SENT").

### Steps to reproduce the issue:
1. Download Accounting and l10n_tr_nilvera_einvoice
2. Create an API KEY: https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0#heading=h.e6i8a29lff5t
3. Go to a turkish client on the Accounting tab and click on 'Verify' for the Nilvera status
4. Go to currencies and activate EUR (be sure there is also the translation for currency subunit)
5. Go to invoices, create one for the Turkish customer you already verified setting the currency as EUR and send it with Nilvera
6. See that current output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR CENTS</cbc:Note> (Turkish numbers with English subunit)
but the expected output is
<cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR SENT</cbc:Note> (Fully Turkish text)

### Cause of the issue:
The issue occurs because the currency_subunit_label field is not translated but fetched using the language of the customer in the invoice.

### Reason to introduce the fix:
To ensure that the amount in words inside the <cbc:Note> tag is completely formatted in Turkish, complying with Nilvera and local e-invoicing requirements, regardless of the customer language.

opw-6523794

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

Forward-Port-Of: odoo/odoo#288122
Forward-Port-Of: odoo/odoo#287630

Clicking a stale /web/content/<id> link in an HTML field crashed the client after the related attachment had been deleted.

**Steps to reproduce:**
1. Open any record with an HTML field (e.g. Project > Task description).
2. Upload a file into the HTML field to embed an attachment link.
3. Save the record.
4. Delete the uploaded attachment from Chatter > Files, or from Settings > Technical > Attachments.
5. Reopen the record and click the embedded file link.

**Client Error:**

   `TypeError: Cannot destructure property 'mimetype' of '(intermediate value)' as it is undefined at LinkPopover.loadAsyncLinkPreview`

`TypeError: Cannot destructure property 'type' of '(intermediate value)' as it is undefined at LinkPopover.updateDocumentState`

When the attachment is missing, ormService.read returns an empty array, so fetchAttachmentMetaData returned undefined instead of entering its catch block. LinkPopover then crashed while destructuring that result in loadAsyncLinkPreview and updateDocumentState.

Return a safe fallback metadata object when the attachment cannot be found so both code paths keep working without crashing.

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

Forward-Port-Of: odoo/odoo#279281