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

# How to reproduce
- Use a browser extension to manage your browser's timezone
- Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe)
- Go to the form view of an opportunity
- Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity)
- In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00)
- Go back to the opportunity for view

# The problem
The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11

# Why
The calendar view uses the browser's timezone to manage the dates. The smart button does not.

It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly.

The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences.

opw-5898520

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

Forward-Port-Of: odoo/odoo#247984

# 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

Forward-Port-Of: odoo/odoo#249025