This update fixes several visual issues in Odoo Discuss after the web client redesign. Users will see clearer sidebar hover feedback, a better dark mode background, a more consistent send button, and aligned header input sizes.

1. show hover effect in discuss sidebar

With redesign of web client style, hover effect in discuss sidebar
was not longer working.

This comes from buttons hover effect no longer having precedence
to defined bg classnames, e.g. `bg-100`.

This commit fixes the issue by explicitly defining a style for the
background when hovering items in the discuss sidebar.

![sidebar-hover](https://github.com/odoo/odoo/assets/6569390/d83660a2-6539-4d57-9944-b956d7bd66b1)

2. improved background color of discuss app in dark mode

The background color was too dark. This commit fixes the issue by
using `bg-view`, which is the preferred background to put
content in both white and dark theme.

![Screenshot 2023-05-15 at 16 00 21](https://github.com/odoo/odoo/assets/6569390/e43838e3-b71a-4bd2-9edf-5ba768e6cef2)

3. Send button visual matches composer rounded border

Send button lacked its border. This commit fixes the issue by
including Send button inside the element that does the pretty rounded
border of composer. That way, the border of send button will not
longer be affected by change of button style.

Also make the send button active / inactive state more visible, by
using button link (green when active, muted when inactive).

![Screenshot 2023-05-15 at 16 06 38](https://github.com/odoo/odoo/assets/6569390/b0933a82-c9a6-4e25-b1e7-8fce6de6f0e2)

4. consistent size of input in discuss header

Before this commit, input size of thread name was bigger than the description one. This happens because the input is sized according to the font size, and the thread name was bigger due to lead classname.

This commit fixes the issue by reducing the padding of input of thread name input, so that both input have the exact same height.

![discuss-header-input-size](https://github.com/odoo/odoo/assets/6569390/4f829fa5-9d85-40f1-a498-68d2f3129117)

This update makes several small visual corrections in Odoo Discuss after the MILK redesign. It improves readability, spacing, button clarity, and status indicator placement so users have a cleaner and more consistent messaging experience.

This update adjusts affected tests and related credit note flows after a change removed an outdated cancellation option from the credit note wizard. It helps keep accounting, localization, subscription, commission, helpdesk, and tax reporting checks reliable without changing normal business workflows.

This PR fixes a bunch of tests broken by removal of option 'cancel' for 'refund_method' field on 'account_move_reversal' model (credit note wizard)

No description available.

Switzerland changes its rates at the beginning of next year, this change already has some implications on client's flow so we add them to the localization so they can coexist with old rates till the end of the year. Changes: - Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%) - Added tax fiscal positions to match those taxes - Added tax groups - Adds migration script to l10n_ch to apply those changes Note newly created taxes will be inactive on new installations but active for

Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes
Note newly created taxes will be inactive on new installations but active for databases that
retrieved them through module update.

Task: 3162286

Add translation of taxes name and description in case of multilang localization.

Forward-Port-Of: odoo/odoo#121469
Forward-Port-Of: odoo/odoo#113001

- Create a Deferred Revenue Model on a Current Liability account - Create a Sale Order yourself (User 1), with Salesperson User 2 - Create the invoice from it - Remove the salesperson from the invoice and add User 3 instead - Change the account to the Revenue Model's one - Post the invoice - Post the deferred revenue created => User 2 is follower of the entries generated The problem is that the context comes from the sales order, and contains a `default_user_id` in the context. The sol

- Create a Deferred Revenue Model on a Current Liability account
- Create a Sale Order yourself (User 1), with Salesperson User 2
- Create the invoice from it
- Remove the salesperson from the invoice and add User 3 instead
- Change the account to the Revenue Model's one
- Post the invoice
- Post the deferred revenue created => User 2 is follower of the entries generated

The problem is that the context comes from the sales order, and contains a `default_user_id` in the context.
The solution provided is to remove it from the context given, as it serves no purpose (the invoices are already created).

opw-3141495

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#121514
Forward-Port-Of: odoo/odoo#120419

- Add missing account tag on repartition line taxes to fix the report 104 amounts for per tax Description of the issue/feature this PR addresses: The Ecuadorian localization report 104, shows wrong amounts per tax. Current behavior before PR: The Ecuadorian localization report 104, shows wrong amounts per tax. Desired behavior after PR is merged: Show correctly base and net amounts per tax in Ecuadorian localization report 104. --- I confirm I have signed the CLA and read the PR

- Add missing account tag on repartition line taxes to fix the report 104 amounts for per tax

Description of the issue/feature this PR addresses:
The Ecuadorian localization report 104, shows wrong amounts per tax.

Current behavior before PR:
The Ecuadorian localization report 104, shows wrong amounts per tax.

Desired behavior after PR is merged:
Show correctly base and net amounts per tax in Ecuadorian localization report 104.

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

Forward-Port-Of: odoo/odoo#121326
Forward-Port-Of: odoo/odoo#121095

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118626

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#118626

This pull request updates Odoo's release information for the SaaS 16.3 version. It helps align the product metadata with the current release so deployments and version references are consistent.

Steps to reproduce the bug: - Enable “subcontracting” in the mrp settings - Create a storable product “P1”: - Add a vendor: - supplier: “Azure interior” - currency: euro - price: 20 - Add a BoM: - Type: subcontracting - add any product as component - Save - Check that the currency of the company is in dollars - Click on Compute Price from BoM button in the product form Problem: The seller's price is not converted into dollars opw-33

Steps to reproduce the bug:
- Enable “subcontracting” in the mrp settings
- Create a storable product “P1”:
    - Add a vendor:
    - supplier: “Azure interior”
    - currency: euro
    - price: 20
    - Add a BoM:
        - Type: subcontracting
        - add any product as component 
        - Save
- Check that the currency of the company is in dollars
- Click on Compute Price from BoM button in the product form

Problem:
The seller's price is not converted into dollars

opw-3321346

Forward-Port-Of: odoo/odoo#121281
Forward-Port-Of: odoo/odoo#121063

Cast website_id so that if it contains more than 1 digit, we do not browse() a tuple with each digit. For example, if we pass pagenew() the website_id '123', this is the current behavior: - browse('1', '2', '3') After this fix: - browse(123) To reproduce the erroneous behavior: - Create at least 10 websites so that the id of this website is at least in the double digits. - Create a new page for the website with a double digit id. Issue was introduced in this commit: https://git

Cast website_id so that if it contains more than 1 digit, we do not browse() a tuple with each digit. For example, if we pass pagenew() the website_id '123', this is the current behavior:
 - browse('1', '2', '3') 
After this fix:
 - browse(123)

To reproduce the erroneous behavior:
 - Create at least 10 websites so that the id of this website is at least in the double digits.
 - Create a new page for the website with a double digit id. 
 
Issue was introduced in this commit: https://github.com/odoo/odoo/commit/d6014c60acc4231a5e56d492d2a39deaf789cbe8

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

Forward-Port-Of: odoo/odoo#121486

Description of the issue/feature this PR addresses: - Adding PND53 and PND3 tax tags to tax data - Additional Thai states - Translations for accounting terms 2879718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118319 Forward-Port-Of: odoo/odoo#113331

Description of the issue/feature this PR addresses:

- Adding PND53 and PND3 tax tags to tax data
- Additional Thai states
- Translations for accounting terms

2879718


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

Forward-Port-Of: odoo/odoo#118319
Forward-Port-Of: odoo/odoo#113331

When unit prices have more than 2 digits, it is currently not reflected in the UBL formats. Consequently, the line amounts are not equal to the unit price * quantity (assume there is no discount, charges or allowance) and it raises validation errors: "Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount". To fix this, we no longer round the unit prices. NB: the decimal ac

When unit prices have more than 2 digits, it is currently not reflected in the UBL formats. Consequently, the line amounts are not equal to the unit price * quantity (assume there is no discount, charges or allowance) and it raises validation errors: "Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount".

To fix this, we no longer round the unit prices.

NB: the decimal accuracy should be set in the settings (otherwise, the default is 2 digits for unit prices).

See https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding

opw-3290035

Forward-Port-Of: odoo/odoo#121573
Forward-Port-Of: odoo/odoo#120821

This pull request marks the repository for the SaaS 16.3 release. It appears to be a release housekeeping change rather than a functional update, helping align versioning and deployment tracking for the business release cycle.

No description available.

Steps to reproduce: - install sale_management, crm and partner_commission; - create a commission plan with two rules for the same category of product but one with a product and one without; - link this commission plan and a partner level to a partner in "Partner Assignment" tab; - create an order with the product specified in the rule. Issue: The commission plan applied is not the right one. Cause: To find the commission plan rule to apply, we order all possible rules with the follo

Steps to reproduce:
- install sale_management, crm and partner_commission;
- create a commission plan with two rules for the same category of product but one with a product and one without;
- link this commission plan and a partner level to a partner in "Partner Assignment" tab;
- create an order with the product specified in the rule.

Issue:
The commission plan applied is not the right one.

Cause:
To find the commission plan rule to apply,
we order all possible rules with the following
order: `product_id`, `template_id`, `pricelist_id`. Then we take the first rule.
The desired result is that if there is
a `product_id` defined, it is at the top of the list. Unfortunately, to sort the `product_id`,
we use the following order:
`'priority desc, default_code, name, id'`.
The null ids will not necessarily be in
the last position and vice versa.

Solution:
Order the rules by sequence.
This solution is intuitive.
With all the rules that match,
we take the one we have defined as the first.

opw-3285638

Forward-Port-Of: odoo/enterprise#41108