**Issue:**
The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion checking :
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/odoo/orm/models.py#L5207


This assertion is failing because of the condition related to `is_dropship`. When `is_dropship` is `True`, the `partner_id` is expected to be `p.sale_id.partner_shipping_id.id`
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95
However, for the specific picking record in some cases, `sale_id` is not set
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/sale_stock/models/stock.py#L190
As a result of the current implementation, the [expression](https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95) evaluates to **False**. That False value is then included in the generated list.
**For example** : lot.partner_ids = [2, False, 5, 6]
With the recent changes, when this assignment happens, it **no longer ignores False values**. Instead, during the write process, the ORM internally calls **browse()** on the provided IDs. Since False is not a valid ID, the assertion inside browse() **fails**, this can be seen in the **traceback**.

This shows that when the field is being written, the ORM validates the IDs by calling browse(), and since False is included in the list, the assertion fails.

**Solution:**
To resolve this issue, I have use `mapped. As 'mapped()' will filter out all the empty(False) values from the recordset.

By switching to **mapped()** and returning a recordset instead of a list of IDs, False values are automatically excluded. As a result, no invalid IDs are passed to browse(), and the assertion error is avoided.

I have also added the if `p.is_dropship and p.sale_id.partner_shipping_id` condition because it fallback to the picking partner if there is no sale order partner to use

**Other Optimization:**
I have used `with_prefetch` to fetching `picking_ids`, it is just the purely ORM friendly optimization.
It ensures that all related records are prefetched efficiently across lots. It is not related to the bug above mentioned.

**Traceback:**
```python

   File "/home/odoo/src/odoo/saas-19.1/addons/stock_dropshipping/models/stock.py", line 95, in _compute_partner_ids
    lot.partner_ids = list(p.sale_id.partner_shipping_id.id if p.is_dropship else p.partner_id.id for p in picking_ids)
    ^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1866, in __set__
    self.write(protected_records, value)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 765, in write
    self.write_batch([(records, value)])
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 1553, in write_real
    comodel.browse(
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5202, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 AssertionError: Invalid falsy real id
```
opw: 5922525
upg: 3889582
tgb: 2449

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

Forward-Port-Of: odoo/odoo#249047

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

Forward-Port-Of: odoo/odoo#241809

*: purchase_stock

Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a stock reference, even when the transfers are manually
created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.

Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were        
     created manually and not generated from any same source document like PO/SO.

Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `stock.reference`is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves
without a `reference_ids` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common stock reference.

After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `stock.reference`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a stock reference. This ensures each manual transfer creates its `own next operation` in multi-step routes.

Task-ID: 5242340

Forward-Port-Of: odoo/odoo#251827
Forward-Port-Of: odoo/odoo#235423

__

## Error description
The test fails when it is launched at 23h.
We obtain an assertion error:
`AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)`

## Origin of the issue
In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future.

X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e

Forward-Port-Of: odoo/enterprise#108891

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109437
Forward-Port-Of: odoo/enterprise#109081

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

Forward-Port-Of: odoo/odoo#241809

**Problem:**
When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results.
When the filter is 'set' it returns all records (even the ones without an analytic distribution) and when the filter is 'not set' it returns no records (even the ones without an analytic distribution).

**Steps to reproduce:**
1) Go to Accounting > Journal Entries.
2) Apply a filter for Invoice lines > Distribution Analytic Account.
3) Select "is set" or "is not set".
4) Check records.

Issue is also reproduceable on Purchase Orders.

**Cause:**
The `_search_analytic_distribution` method did not correctly handle the case when the value is [False], so it results in an invalid Query.

**Solution:**
- We need to handle the case when we have False in the value on it's own.
opw-5478688

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

Forward-Port-Of: odoo/odoo#251816
Forward-Port-Of: odoo/odoo#247777

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109437
Forward-Port-Of: odoo/enterprise#109081

Description of the issue this PR addresses:

I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations. This PR reorders the logic so geometry is read first and DOM mutations are
applied afterwards, reducing the number of forced reflows and significantly improving performance.

II. Debounce `updateHints` and `updatePowerButtons` to avoid excessive UI updates on frequent selection changes. Introduce `debounceHints` and `debouncePowerButtons` editor config options so debouncing can be disabled in tests for deterministic behavior.

III. Introduce READ helper for withSequence to explicitly order resource handlers so DOM reads run before DOM mutations.

Before:
<img width="1705" height="399" alt="image" src="https://github.com/user-attachments/assets/2fca797a-0311-4c4a-9063-2051934baa7c" />

After:
<img width="1490" height="343" alt="image" src="https://github.com/user-attachments/assets/0f295969-b962-4190-a7f9-fe5366d7fafd" />


task-5499625

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

Forward-Port-Of: odoo/odoo#249785
Forward-Port-Of: odoo/odoo#244478

This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated.

The original bug was:
create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium
employee > new > payroll > contract > start_date: any date (this should create a first dimona activity)
settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually

`_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one.

We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it.

[tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)

Forward-Port-Of: odoo/enterprise#109304
Forward-Port-Of: odoo/enterprise#96423

SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google.

Reproduction steps:

* Create a calendar event in Odoo with an SMS reminder.
* Sync the calendar with Google.
* Wait for the reminder to trigger.
* Observe that no SMS is sent by Odoo.

Cause:

The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo.

Fix:

The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master.

opw-5172958

Forward-Port-Of: odoo/odoo#251742
Forward-Port-Of: odoo/odoo#241026

Issue
-----
When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered".

Steps to reproduce
-----
- Create a UPS delivery
- Multiple packages
- Validate transfer
- Return
- Validate IN
- Return again
- Add the UPS under the "additional info" tab
- Ensure still multiple packages
- Validate OUT

Cause
-----
When preparing the shipping data, we go through

https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121

which leads us to do

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155

so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`.

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58

From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns.

-----
Ticket:
opw-5866100

Forward-Port-Of: odoo/odoo#250724
Forward-Port-Of: odoo/odoo#246946

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#107438

When a workspace(folder) linked to a folder setting is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``documents_account`` module
- Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save >
- Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save
- Go to Documents > Click on Workspace A > Actions > Move to trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint
"documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting"
```

solution:
override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings,
preventing their deletion during the garbage collection.

sentry-7193540869

Forward-Port-Of: odoo/enterprise#109434
Forward-Port-Of: odoo/enterprise#104875

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

Forward-Port-Of: odoo/odoo#241809

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109374
Forward-Port-Of: odoo/enterprise#105969

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#105040

### Issue:

Due to this bug, user's inbox can crash and become inaccessible by another user.

#### Steps to reproduce:
1- Create a db with two companies and sale installed with demo data.
2- Demo user should only have access to company A
3- Demo user preference should be handle in Odoo
4- Admin should access both companies
5- Create a partner called partner_b with company set to company B
6- Using admin create a SO in company B, with the partner_b
7- Send a message (not internal note) in SO chatter, and mention Demo user
8- Login using Demo user
9- Open discuss app. As you see the inbox is not accessible anymore.

### Cause:

This is caused because Demo user doesn't have read access to partner_b, as a result `partner_share` cannot be accessed in `_filter_unimportant_notifications`:
https://github.com/odoo/odoo/blob/7a02ae3c220dc53ed541f5a1ec88abcd49c3baeb/addons/mail/models/mail_notification.py#L112-L117


opw-5089738

Forward-Port-Of: odoo/odoo#245704
Forward-Port-Of: odoo/odoo#232894

**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body

**Issue:**
Default table style used for the inline conversion of 
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.

This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.

Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0

**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.

Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).

Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.

opw-5218581

Forward-Port-Of: odoo/odoo#242001

SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google.

Reproduction steps:

* Create a calendar event in Odoo with an SMS reminder.
* Sync the calendar with Google.
* Wait for the reminder to trigger.
* Observe that no SMS is sent by Odoo.

Cause:

The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo.

Fix:

The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master.

opw-5172958

Forward-Port-Of: odoo/odoo#251742
Forward-Port-Of: odoo/odoo#241026

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#107438

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#105040

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109437
Forward-Port-Of: odoo/enterprise#109081

The rounding of time was not correct. I was always flooring, but before
the new duration the rounding was depending of the precision of the
duration. The rounding has been restored as before and put in
formatDuration.
formatFloatTime has been modified to use formatDuration and now take
the same options (specify the unit of time of the value).

The graph view and list view didn't extract the otpions from the fields
with widget. Now, they get the options and give them to the formatter.

The widget was showing the seconds by default, but it doesn't match with
the behavior of the DateTime widget. It has been changed and now the seconds
are shown only if the options 'showSeconds' is true and it's false by default.
The impacted views has been restored as before the original commit.

The options of float_time widget couldn't take falsy values, now it can.

an improvment has also been done: the popover on the float_time widget
doesn't show up if the input value and the formattedValue are the same.

followup of TASK-5347051

Forward-Port-Of: odoo/enterprise#108072

This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated.

The original bug was:
create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium
employee > new > payroll > contract > start_date: any date (this should create a first dimona activity)
settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually

`_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one.

We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it.

[tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)

Forward-Port-Of: odoo/enterprise#96423

# How to reproduce
- A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx)
- This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size)
- If the system parameter web.max_file_upload_size is set, delete it and refresh your page
- Pick any form view and add a file field with studio
- Upload a file larger than the limit set in the proxy, but smaller than 128mb
- Save the form

# The problem
The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+)

# Why
When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb).

So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json.

Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one.

opw-5891662

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

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#102126

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954