When applying a downpayment in POS with tax-included prices, a rounding error of 0.01 cent could occur, preventing invoice creation.

For example, with an 8% tax and a downpayment of exactly 2,117.00:
- Calculation: 2117 ÷ 1.08 = 1960.185 → rounds to 1960.19
- Recalculation: 1960.19 × 1.08 = 2117.005 → rounds to 2117.01
- Result: 0.01 cent discrepancy

Root Cause:
-----------
The issue stems from cascading rounding errors when using 'round_per_line' method with standard product price precision (typically 2 decimals). Each intermediate calculation introduces a small rounding error that accumulates.

Solution:
---------
Apply two specific fixes for downpayment products only:

1. Use higher precision (6 decimals) instead of standard product price precision to maintain accuracy through the calculation chain

2. Force 'round_globally' rounding method instead of 'round_per_line' to ensure rounding happens only once at the final step, not at each intermediate calculation

3. Use raw (unrounded) amounts in tax calculations to preserve full precision until final rounding

opw-5040722

When a user is viewing a page, clicks on the Knowledge Book icon, opens an article, and selects the "Send As Message" button in a Knowledge Clipboard block, the macro system performs several actions: it restores the initial view, opens the full mail composer, and inserts the clipboard block's text at the very end of the editor.

Recent updates introduced automatic inclusion of the user's signature in the email body when the full mail composer is opened. As a result, the clipboard text is inserted after the user signature, which is undesirable because users must manually adjust the message to position the signature correctly.

To insert text before the user signature but after the user text, the clipboard macro will now trigger a "click" event on the button opening the full mail composer and set on that event the text to insert. The chatter will then read that value and insert the text at the right place.

Task-4428445

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

Steps to reproduce:
===================
1- Drop the block tab snippet
2- Inside one of the tab panes, drop a Columns snippet.
3- Select background_color for one of the columns
4- Change tab style to tab

-> The background color of the inner column is overridden.

Cause:
======
When the "Tabs" snippet style is set, a `.card` class is added to its container (See [1])
A generic CSS rule, intended to style these tabs, was targeting any `.card` element with a `.card-body` child. (See [2])

However, the Columns snippet also uses a `.card > .card-body` structure (distinguished by a `data-vxml` attribute). This caused the overly broad tab-styling rule to incorrectly cascade and override the background color of the nested column.

Solution
========
The SCSS selector has been made more specific so that works if `card-body` class doesn't have any parent class with class `card` and has attribute `data-vxml`

[1]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/website/static/src/snippets/s_tabs/options.js#L149
[2]: https://github.com/odoo/odoo/blob/4cb3ffc09507fdfdb1aeabb70b2c93105f992700/addons/web/static/src/scss/bootstrap_review_frontend.scss#L55

opw-5394480

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

The runbot builds are currently failing after the recent merge of commit [1]
due to a triggered documents logger warning.

In commit [1], `cls.attachment_txt` is created with invalid `datas` in
`setUpClass`, which triggers an error and raises a log warning at code
line [2]. We already added `mute_logger` to suppress this log, but it does
not work due to caching behavior in setUpClass.

The `setUp` method of the `TransactionCase` test class attempts to flush all
pending data (see code reference [3]). During this flush, it recomputes the
values of `cls.attachment_txt`, which triggers the same logger warning again.
Since this occurs outside the mute_logger context, the log is not suppressed,
resulting in the runbot failure.

This commit fixes the issue by introducing a helper method to create and
return `attachment_txt` for use in the test methods.

[1]: https://github.com/odoo/enterprise/commit/d4ecf6c75bff3fc29a95c40f86528c6b10870e12
[2]: https://github.com/odoo/enterprise/blob/f3e2de6bae7573ad61429a55ff3769ba7fab58ea/documents/models/documents_document.py#L1355-L1356
[3]: https://github.com/odoo/odoo/blob/8e60084924d390632934b5a9bd82a6954d6484de/odoo/tests/common.py#L1038

runbot-238369

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930