Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear

<details><summary>Exact Traceback</summary>
<p>

```
RPC_ERROR

Odoo Server Error

Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
    return retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
    return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
    return report_method(model, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
    self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
    self._get_vat(),
    ^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
    if vat.startswith(('GB', 'XI')):
       ^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
        at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```

</p>
</details> 

Reason:
- No VAT set on the current company.

Solution:
- Blocking level error for the user to set VAT on the current company.

Task-5929908

Forward-Port-Of: odoo/enterprise#107150

## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.

## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].

## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.

runbot-241028

Forward-Port-Of: odoo/enterprise#108333

Steps to produce:
---
- Install sales module.
- Open sales module > orders > switch to kanban view.
- Then make it group by status.

Observation:
---
- The order of status is not proper.
- It comes as Cancelled, Quatation, Sale order, Quatation sent.

Root cause:
---
- When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself.
- Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order  as `cancel, draft, sale, sent`.

Solution:
---
- Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly.
- This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view.

opw-5497664

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

Forward-Port-Of: odoo/odoo#248776

## Issue Before This PR:
The fields `used_weight_percentage` and `used_volume_percentage` in the
list view were showing incorrect values. These fields were incorrectly
aggregating totals across all batches, as the calculation of
`estimated_shipping_weight` and `estimated_shipping_volume`
was not handled per batch, resulting in wrong percentages.

## Steps to Reproduce:
- install inventory module and enable settings for
  batch transfers and dispatch management,
- add two batch records with vehicles assigned
  (having weight or volume capacity), and transfers
  having products with weight or volume defined
- Observe different values of weight % or volume %,
  in form and list view.

## Cause of the Issue:
In the method `_compute_estimated_shipping_capacity`
the computation loop referenced all records together,
causing totals to be shared across batches.

## With This PR:
Each batch now computes its own estimated shipping weight and volume correctly,
ensuring correct per-batch values consistent with the form view and
match what users see when opening individual records.

Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7)

Forward-Port-Of: odoo/odoo#250317
Forward-Port-Of: odoo/odoo#249239

**Steps to reproduce:**
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner or payrun report
- Pay with "Swiss ISO20022" > generate xml pain001
- Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml !

**Cause:**
In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf).

**Solution:**
Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6).

opw-4872507

Forward-Port-Of: odoo/enterprise#108461

On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package.

Steps to reproduce:
-------------------
* Create a Package "Pa" with a package type that has a weight
* Create a product "Po" tracked by quantity
* Add two units of the product Po to the package Pa
* Create Delivery with two units of Po.
* Confirm the Delivery and print the delivery slip -> The total weight is the weight of the package type without including the products inside.

Observation:
-------------
When computing the shipping_weight for the delivery, it will fallback on the package_weight to calculate it weight, https://github.com/odoo/odoo/blob/ca14f1aa21a75398919c1453be19011522bb3b5c/addons/stock/models/stock_picking.py#L893-L906 
It retrieve the weight calculated by _get_weight
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_package.py#L435
Except for the outermost package,  where it incorrectly considers only the package type weight and does not include the products weight

opw-5499770

Forward-Port-Of: odoo/odoo#247227

Followup to previous fix: 705e27a2d3d9e3c4d075a1e8fb599333a504a316 

If the user configured his database with more than one Buy or Manufacture route, the `_get_route_domain` would trigger a Singleton Error.

# Steps to Reproduce:
- Create new Manufacture Route:
  - Create new Warehouse W2
  - Create new 'Manufacture 2' route (no rule yet)
  - Go to the 'Manufacture' route
  - Select the new rule for W2, expand popup
  - Update the route to 'Manufacture 2'
- Create new Product P
  - Storable
  - Create Basic BoM
- Product form -> Actions wheel -> Replenish => Singleton Error

OPW-5960493

---

## Configuration
<img width="1844" height="628" alt="image" src="https://github.com/user-attachments/assets/b90c070c-4af5-427c-bd3d-79904a7881a0" />


## Traceback
```
RPC_ERROR

Odoo Server Error

Occured on 102180409-19-0-design-theme.runbot119.odoo.com on model product.replenish on 2026-02-25 08:12:03 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http.py", line 2273, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 185, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2328, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 2543, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http.py", line 788, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 94, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/models/models.py", line 1964, in onchange
    defaults = self.default_get(missing_names)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/purchase_stock/wizard/product_replenish.py", line 12, in default_get
    res = super().default_get(fields)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/stock/wizard/product_replenish.py", line 77, in default_get
    res['route_id'] = self.env['stock.route'].search(self._get_route_domain(product_tmpl_id), limit=1).id
                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/purchase_stock/wizard/product_replenish.py", line 92, in _get_route_domain
    domain = super()._get_route_domain(product_tmpl_id)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/mrp/wizard/product_replenish.py", line 51, in _get_route_domain
    domain = Domain.OR([domain, Domain('id', '=', manufacture_route.id)])
                                                  ^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.route(6, 20)
```


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

Forward-Port-Of: odoo/odoo#250580

*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us

When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.

For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron

Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std

ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
    <field name="name">United States: Employee</field>
    <field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
    <field name="country_id" ref="base.us"/>
</record>
```

The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.

sentry-7166574553

Forward-Port-Of: odoo/enterprise#106950

Steps to reproduce:
- Set up a Company with BR localization
- Create a product as follows:
  - [General Information] Product Type: Service
  - [Sales] LC116 Code: 14.01
  - [Sales] Purpose of Use: Not applicable
  - [Sales] Service Code Origin: 14.01.3/168061/1524
  - [Sales] Service Codes: 14.01.3/168061/1524
- Create an Invoice with Document Type "Electronic Service Invoice - NFS-e"
- Add the product on the line
- Compute taxes
- Compute taxes again

Issue:

Action will be blocked by a validation error resulting from the external
taxes call
```
odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice.
Errors: Rejection: Total Installments doesnt match Total Lines
∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0
```

It occurs because during the call the system is considering the
existing taxes on the line and it will send to the avatax service wrong
amounts

opw-5412456
opw-5409735

Forward-Port-Of: odoo/enterprise#108403
Forward-Port-Of: odoo/enterprise#108088

When syntax error will raise ``node`` will not assign. So, assign ``None`` before error will surpess.

Note:- found it during testing. 

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2273, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2328, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2543, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 788, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 113, in web_read
    values_list: list[dict] = self.read(fields_to_read, load=None)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
    return self._read_format(fnames=fields, load=load)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6686, in __getitem__
    return self._fields[key].__get__(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1746, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1917, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4952, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 366, in _compute_invalid_locators
    if invalid_locator := assess_locator(source, spec):
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 330, in assess_locator
    if node is None:
UnboundLocalError: local variable 'node' referenced before assignment
```
opw-5956964





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

Forward-Port-Of: odoo/odoo#250589

Why this commit
---

When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error
 preventing it from being added to the cart.

This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there.

After this Commit
---
The rental start and end dates from the current sale order are  passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error.

Steps to Reproduce
---
1. Create two rental products A and B.

2. Configure product B as an accessory of product A.

3. Add product A to the cart with any rental period(except default).

4. From the cart page, attempt to add product B from suggested products.

5.Observe the error about mixing different rental periods.

Here is the video demonstrating on how the error is reproduced :


https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7



Expected Result

The accessory product is added to the cart using the same rental period as the existing cart's rental period.


Community PR: https://github.com/odoo/odoo/pull/249289

OPW: 5823691

Forward-Port-Of: odoo/enterprise#106426

**Steps to reproduce:**
* Install the **product_unspsc** module.
* Create a product with a **UNSPSC category**.
* Create and post an invoice for this product.
* Send the invoice via **Peppol**.

**Observed behavior:**
* Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”*
* The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`.

**Cause:**
* The `listID` attribute was set to the literal string **'UNSPSC'**.
* According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'.

**Fix:**
* Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node.
* Update and extend tests to validate the correct scheme identifier.
* Same for CPV code from the documentation i's code is also changed to 'STI'.

ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/

opw-5948723

Forward-Port-Of: odoo/odoo#249788

This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.

18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154

18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160

This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:

https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24

Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.

Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment

=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.

Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725

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

Forward-Port-Of: odoo/enterprise#107519

#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.

#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
  - i.  Select both "Parent Company" and "Child Company A" but not "Child Company B"
  - ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")

#### Current behavior:
i.  Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only

#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"

A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.

opw-5385585

Forward-Port-Of: odoo/enterprise#101898

**Problem:**
When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.

**Steps to reproduce:**
1. Go to Settings app and enable debug mode
2. Navigate to Technical → Reports
3. Search for "slot_report"
4. Click "Add to print menu" button
5. Refresh the browser
6. Go to Planning app and switch to list view
7. Select a few planning.slot records
8. Click Print → Planning

**Current behavior:**
A blank or invalid PDF is generated.

**Expected behavior:**
Users should receive a clear error message directing them to use the correct print method from the calendar view.

**Cause of the issue:**
The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports.

**Fix:**
Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data.

opw-5477184

Forward-Port-Of: odoo/enterprise#105168

Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar.

Steps to reproduce:
- Open General with Demo data on 1080p monitor
- have window take slightly below half of screen width
=> The Discuss app has horizontal scrollbar, from sidebar non-compact, message list, and the member panel all open at once.

This horizontal scrollbar comes from the General demo data that has a sub-thread preview from the 1st message. A sub-thread preview has a max-width of 400px, which shouldn't be an issue on itself. However due to parented container not having `min-width: 0`, it didn't want to shrink lower than this max-width.

This commit fixes the issue with `o-min-width-0` on the parented container to make sure this can shrink lower than the sub-thread preview's max width of 400px.

Task-5956698

Before / After
<img width="882" height="635" alt="Screenshot 2026-02-20 at 16 36 14" src="https://github.com/user-attachments/assets/516b66a1-f8d2-4ee9-b62f-6d94dfe98d11" /> <img width="884" height="637" alt="Screenshot 2026-02-20 at 16 37 07" src="https://github.com/user-attachments/assets/987f418c-f7e2-477b-ae9c-6c68d6a21ec5" />

Forward-Port-Of: odoo/odoo#249846

**Steps to reproduce:**
- Go to Email Marketing app
- Create a mailing campaign
- Set its recipients to Contact
- Click on the test button to send a test mail to any mail
- Go to the first contact record
- Chatter will show `This message has been removed` message

**Issue:**
Previously, message created for testing were ignored by the Chatter as they were empty. As we now keep empty messages visible but with removed content display, they shows up on related records.
```py
record = self.env[mailing.mailing_model_real].search([], limit=1)
```

**Fix:**
Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to `False` to trigger the `unlink` logic.
```py
def unlink(self):
    # cascade-delete the parent message for all mails that are not created for a notification
    mail_msg_cascade_ids = [mail.mail_message_id.id for mail in self if not mail.is_notification]
    res = super(MailMail, self).unlink()
    if mail_msg_cascade_ids:
        self.env['mail.message'].browse(mail_msg_cascade_ids).unlink()
    return res
```

related: https://github.com/odoo/odoo/commit/21f92550f83cbd38df2c223c65c61bd16dc8e2b0

opw-5502787

Forward-Port-Of: odoo/odoo#247805

Problem:
In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a positive number extremely close to 0. There are also issues with negative avco value that are tangential to this error.

Solution:
We will mirror the iterative logic from `_run_avco`, being sure to account for whether we have moved from negative quantity to positive or vice versa. Also, before calculating avco value as `total_value / total_quantity`, we will ensure `total_quantity` is not a floating point number very close to 0 to avoid unit cost inflation.

Steps to replicate (Runbot 19):
Have storage locations enabled to make this easier to test
1. Product with tracked inventory, avco perpetual valuation, non-zero cost
2. Set the on hand quantity to -0.3 Units
3. Set the on hand quantity to -0.2 Units
4. Set the on hand quantity to 0 Units (A well-known python quirk, that .1 + .2 = 0.30000000000000004)

Go to the stock report and inspect the unit cost history for the product, note
1. The nonsense Unit Cost on the top row
2. The negative Unit Cost on the 2nd row

Note to reviewer:
I discussed this issue briefly with dafr, who pointed out that there are further adjustments to come with the `_run_avco` method, and several other issues with this report that are not addressed by this PR. However, the problems with this report are affecting a customer so we'd like to push these fixes forward for now.

opw-5430300

Forward-Port-Of: odoo/odoo#245141