Steps to reproduce:
- Product A with a price-included tax, product B with a negative price and another tax (or none)
- Promotion with a fixed amount discount on specific products (or on the order), both products eligible
- Add both products to a PoS order

Issue:
The discount is split per tax group with a common factor, so the negative line gets a positive reward line, which is expected. But the reward lines add up to less than the discount and the customer pays too much.

Cause:
Since 7280f3597ece each tax group is capped with
`Math.min(get_total_with_tax(), amount)`. A single tax group is compared with the total of the whole order: here the total includes the negative line, so the positive group is lowered while the negative one is kept as is.

Fix:
Apply the cap proportionally: every tax group is scaled by the ratio between the order total and the discountable amount when the total is lower. The scenario of 7280f3597ece gives the same result, and the reward lines add up to the discount whatever the number of tax groups.

opw-6567973

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

Forward-Port-Of: odoo/odoo#288985
Forward-Port-Of: odoo/odoo#288853

Before this commit, when adding a line without a product to an invoice or credit note, `_get_most_frequent_account_for_partner` picked the partner's most-used account, filtered to an income or expense account depending on `get_inbound_types` and `get_outbound_types`.

Those helpers classify move types by cash-flow direction which is correct for choosing a receivable and payable account but wrong for choosing an income ro expense account: they group `in_refund`  with `out_invoice` as "inbound", and `out_refund` with `in_invoice` as "outbound".

As a result, a Vendor Credit Note line with no product would be filtered to income accounts instead of expense accounts, and a Customer Credit Note line to expense accounts instead of income accounts. This only surfaced for contacts who are both customer and vendor, since the query needs matching history to return a result; otherwise it silently falls back to the journal's default account, masking the bug for ordinary contacts.

This commit uses `get_sale_types` and `get_purchase_types` instead, which classify by document side, sale vs. purchase rather than cash-flow direction, matching the classification already used for product-based lines `is_sale_document` and `is_purchase_document`

opw-6373124



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

Forward-Port-Of: odoo/odoo#278794
Forward-Port-Of: odoo/odoo#276846

Before this commit, mail_template_dynamic_placeholder_tour could fail when the server answers the onchange of "Applies to" slowly:

    Tour mail_template_dynamic_placeholder_tour failed at step Check if
    the dynamic placeholder popover is opened
    (trigger: div.o_model_field_selector_popover)

This happens because the tour waits a fixed 200ms after picking "Contact" before typing "#" in the subject. The popover needs the model, and the record only holds the model once the onchange answers. On runbot the answer came after 230ms, so "#" showed the "select a model" notification instead of the popover.

This commit fixes the issue by waiting for the internal link button of the many2one, which only renders once the record holds the model.

Note that this step relies on "[FIX] web: cancel the pending search on autocomplete select": without it, a search still pending on the picked value marks the input as edited, which hides that button.

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

Ref commit: https://github.com/odoo/odoo/pull/287888

Forward-Port-Of: odoo/odoo#290364
Forward-Port-Of: odoo/odoo#290185