Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure.

Do a bit of rejiggering to fix things up:

- in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing)
- only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames

Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already.

And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs.

Forward-Port-Of: odoo/odoo#232472

**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)

**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)

When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)

Also, we can't just remove any of the two as they serve different purposes.

```
-> (backend) -> mail.thread
    -> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
        -> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
    -> _notify_thread_by_web_push -> stored devices -> push_to_end_point
        -> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```

**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.

The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.

Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).

The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.

opw-4639507

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

Forward-Port-Of: odoo/odoo#221259

| saas-18.4 and above | This PR |
|--------|--------|
| <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img width="437" height="392" alt="image" src="https://github.com/user-attachments/assets/b6896545-34b5-4816-a35f-5c2605d4153b" /> | 

Prior to Commit[^1], the front-end badges using `.badge.o_tag` were receiving a `12px` font size, which came from a rule defined in portal. This looked fine, although odd, since a style from portal was affecting the entire front end.

After Commit[^1], this rule no longer exists, meaning that `.o_tag` now falls back to `0.875rem` (14px by default), while standard badges use a default font size of `0.75em` (12px by default)

Since using `.badge.o_tag` never allowed overriding the `font-size` value, we fixed the issue by assigning the `--badge-font-size` CSS variable directly to the badge definition, ensuring the correct visual result.

task-4900376

[^1]: https://github.com/odoo/odoo/commit/8f8a370a84d136f3d2316eb1a55c7168b7ae6ccf#diff-23677f06a9aaf2e3395e957cfb9580ce6fcc9aba2635b560fe8f15fa27707313L29
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

…xported pdf

#### Issue
In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name.

#### Step to reproduce:
- Create an account group (e.g Group_101 from 101 to 101)
- Create some AML in an account related to the previously created group (e.g. in 101501 Cash)
- Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance )
- In the Options select "Hierarchy and subtotals"
- Add a filter including your group name (e.g. Group_101)
- Export to pdf

#### Current behavior:
- No lines are displayed in the pdf as the backend uses only the account name to apply the filter

#### Expected behavior:
- Lines are displayed using account name and group name to filter

#### Cause:
- Filter was applied only on account name

#### Solution:
- If hierarchy is enabled, display accounts where filter appears on either account or group

opw-4906593

Forward-Port-Of: odoo/enterprise#96338
Forward-Port-Of: odoo/enterprise#90403

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing Print Assets (Public View)**
   The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode.

### Fix

This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle.

The remaining issues are tackled in odoo/enterprise#92665

opw-4816241

Forward-Port-Of: odoo/odoo#230639
Forward-Port-Of: odoo/odoo#223434

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing CSS rules (Public View)**
   The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode.

### Fix

This PR fixes problems 2, 3 and 4 by:

* Removing the unused/irrelevant planning print styles
* Ensuring `web.assets_web_print` is loaded in portal
* Creating a new print bundle for the frontend view
* Hiding the knowledge header in the public view when printing (to improve layout)


The first issue is tackled in odoo/odoo#223434

opw-4816241

Forward-Port-Of: odoo/enterprise#96656
Forward-Port-Of: odoo/enterprise#92665

Description of the issue/feature this PR addresses:
When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. 

<img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" />

Each reconnect attempt causes a log entry: 
```
2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 
2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Lead/Opportunity, Modern Open Space (crm.lead: 25)

Blame the following rules:
- Personal Leads

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. 

```



Current behavior before PR:
Reconnect loop.

Desired behavior after PR is merged:
Do not add channels without sufficient rights.


Related to: https://www.odoo.com/de_DE/my/tasks/5026412

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

Forward-Port-Of: odoo/odoo#231599
Forward-Port-Of: odoo/odoo#223890

## Steps to reproduce

### Bug 1
1. Create a bill receipt
2. Add deferred dates
3. They're reset to False

### Bug 2
1. Create a bill
2. Set the deferred dates
3. Switch to receipt type
4. Confirm
5. The account of the generated deferral entries is incorrect

## Fix

While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value.

In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates.

In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator.

For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account.

opw-5129561

Forward-Port-Of: odoo/enterprise#97824
Forward-Port-Of: odoo/enterprise#97653