Currently, an error occurs when creating a `vendor bill` for a product with
multiple purchase `UOMs` are defined for the same vendor.

**Step to produce:**
- Install the `account` and `purchase` modules.
- From the `Settings`, enable `Units of Measure & Packagings`.
- Create a new product, in the `Purchase` tab, add two lines with the same
 `Vendor: Azure Interior`, but with a different `Unit`.
- Create a new vendor bill, set `Vendor: Azure Interior`, click on `Catalog`,
  and select the newly created product.

**Error:**
`ValueError: Wrong value for account.move.line.product_uom_id: uom.uom(4, 5)`

**Root Cause:**
At [1], the field `product_uom_id` is a `Many2one` field expecting a single
record. When multiple UOMs match the vendor, an error occurs.

[1]
https://github.com/odoo/odoo/blob/07b9644b3abf5bc8fd8621bdcfa50db131d7058a/addons/account/models/account_move_line.py#L807

This commit ensures and prevents an error when multiple vendor UOMs exist.

Sentry – 6718849231

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

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

Forward-Port-Of: odoo/odoo#215615

Previous style had the following problem:

- message content was moved up during the animation of message highlighted, which annoys immediate reading of content when scrolled to the message
- style was too soft, especially in dark theme, because there's only the shadow effect outside of translate effect, and this is dark on dark bg.

This commit solves the issue as follow:

- highlighted message is not moved at all
- bg color of highlighted message uses low opacity active color
- highlighted message has left inset border to easily spot the message at hand
- when highlighted message has bubble, the bubble outline is also colored to attract reader. Bubbles can make the highlight border hard to find, even with the left inset border, as replies to bubble also have a left-border inset.

Task-4543530

Before (white theme)
![before-white](https://github.com/user-attachments/assets/19ed2138-e32c-46cf-8d42-5ec977ab508d)
Before (dark theme)
![before-dark](https://github.com/user-attachments/assets/cf6f8cb2-f2cc-4db4-a16b-1baf6f377729)
After (white theme)
![white](https://github.com/user-attachments/assets/bbe0d27a-7600-4c58-8c57-1ec161cf24cc)
After (dark theme)
![dark](https://github.com/user-attachments/assets/fd29fc68-c50e-42c8-bd6a-24971f48a037)

- Open the Project app. The URL is `/odoo/project`;
- Open a project. For example, the project with ID 5. The URL is `/odoo/project/5/tasks`;
- Click on an embedded action. For example, 'Planning'. The URL  is `/odoo/project/5/tasks/5/action1574`;
- Switch to another embedded action. For exemple, `Timesheet`. The URL is `/odoo/project/5/tasks/5/project-timesheets`. Note that in this case, the last action of the URL has changed.

Reload the browser (F5).

When reloading the router and the action service will use the URL to reconstruct the breadcrumb. It will decompose the URL as follows:

- `/odoo/project` : The list of projects;
- `/odoo/project/5` : The form view of the project '5', this is a known limitation; this step was not included the initial flow;
- `/odoo/project/5/tasks`: The list of tasks of the project 5;
- `/odoo/project/5/tasks/5` : The form view of the task 5. This line is an error, the task 5 should not be included in the breadcrumb.
- `/odoo/project/5/tasks/5/project-timesheets` : The `Timesheet` embedded action.

The issue occurs because the 'active_id' of the 'Timesheet' embedded action is taken as a 'resId' for the action tasks, which add an error on the breadcrumb.

This commit, changes the behaviour to allways replace the last action with the embedded action. This behaviour is already done when changing of embedded action, but not for the first one.

If we take our example again :
- `/odoo/project`;
- `/odoo/project/5/tasks`;
- Click on an embedded action: `/odoo/project/5/action1574`;
- Switch to another embedded action: `/odoo/project/5/project-timesheets`

After reloading, the breadcrumb will be:
- `/odoo/project` : The list of projects;
- `/odoo/project/5` : The form view of the project '5';
- `/odoo/project/5/project-timesheets` : The `Timesheet` embedded action.

However, this commit causes a side effect. The list of tasks will no longer appear in the breadcrumb. Users can still access it via the Top Menu.

opw-4889557

Forward-Port-Of: odoo/odoo#219404

Steps to Reproduce:
1. Go to the POS Settings
2. Enable the "Restrict Categories" option
3. Leave the categories M2M field empty
4. Open the POS store
5. No products will be loaded

<img width="483" height="162" alt="empty categories" src="https://github.com/user-attachments/assets/2c932954-e67a-4faa-8915-b0ebacc57525" />

Issue:
The _load_pos_data_domain functions do not check on the size of the available_categories array before attempting to create a domain. As such, a domain entry `["category_ids", "in", []]` will be added, preventing any products from being loaded. This wasn't the case in version 18.0, which had a check on the array.

Fix:
Add an extra check on the existence of the available_categories array before attempting to create a domain.

Addendum:
Field "Restrict Categories" description is: 
> If no category is specified, all available products will be shown

task-4962323

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

*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#219954
Forward-Port-Of: odoo/odoo#219389

Steps to reproduce
------------------
1. Create a Sales Order, add a product with QTY = X
2. Open PoS
3. Load this same Sales order (by clicking "Settle the order"-> QTX is
   X as expected
4. Return to Sales order (in the sales app)
5. Edit QTY from X to Y and save
6. Go back to PoS
7. Delete the laoded Sales Order and load it again
   -> Notice that QTY is still X and not the updated Y!!

Other Flow in frontend
----------------------
1. Create a Sales Order, add a product with QTY = X
2. Open PoS
3. Load this same Sales order (by clicking "Settle the order"-> QTY
   is X as expected
4. Change the quantity manually, to pay for X - 1
5. Validate and pay for the order
6. Load the same Sales order again with "Settle the order"
   -> The quantity is still X and the price is the unit price times X!!

Why the issue
-------------
When settling the order, we get its value using _getSaleOrder
which basically reads it from the cache. So it will read the old
order lines having the old qty, and not the updated one.

The fix
-------
Instead of reading the lines from the cache, we read them direcly from
the backend, to accomodate for cases where the data might have been
changed on another device or has not been updated in the cache.

opw-4819708
opw-4913397

Co-authored-by: Arthur Nanson <artn@odoo.com>

Forward-Port-Of: odoo/odoo#218331

Steps to reproduce
------------------
1. Click on an unreserved table and add some lines.
2. Click on the "Tables" button to go back to floor page.
3. Click back on that same table, and delete all the lines.
4. Click on "Release Table". You will be redirected to floor page.
5. Click back on that same table.

Observe that the old lines (the ones deleted in step 3) are now all back!!

Why the issue
-------------
When going back to the floor page on step 2, we a call to `sync_from_ui` is made to write the new order with all of its orderlines to the backend, as expected. We can also expect that on step 4, when clicking "Release table", a call to `sync_from_ui` is made with the updated order, i.e. the order with no orderlines. However, that is not happening!! Because when we are removing the lines in step 3, we are not marking the order as 'pending' and hence, the call to `syncAllOrders` [1] is skipping calling the `sync_from_ui` API [2] since `orderToUpdate` is empty [3], so our deleted lines are not written to the backend on the first time. So when we open the table again, we sync the current order (the empty one) with the backend order (the one that still has the lines), which results in a new local order having all the lines from the backend!!!

The fix
-------
When removing a line, we also mark the order as pending. Note that idealy we would want to override `removeOrderline` [4] as it would be much simpler, however, since in `removeOrderline`, we don't have access to the `PosStore`, and hence we cannot call `this.pos.addPendingOrder`, we had to override `_setValue` instead, which added slightly more complexity in the form of few `if` checks (matching the ones in the original `_setValue` that lead to calling `removeOrderline` [5]).

[1]: https://github.com/odoo/odoo/blob/7b8699dc07daeeb261bd880d969321f7e94f23f0/addons/pos_restaurant/static/src/app/services/pos_store.js#L472
[2]: https://github.com/odoo/odoo/blob/1d12dd16b1bed4e6a6fe8c1eb9823f89a5ee8e97/addons/point_of_sale/static/src/app/services/pos_store.js#L1229
[3]: https://github.com/odoo/odoo/blob/1d12dd16b1bed4e6a6fe8c1eb9823f89a5ee8e97/addons/point_of_sale/static/src/app/services/pos_store.js#L1198
[4]: https://github.com/odoo/odoo/blob/45e300461c299796313c46c469b548cc438a18cd/addons/point_of_sale/static/src/app/models/pos_order.js#L493
[5]: https://github.com/odoo/odoo/blob/76a4fb579c34e0d82b07a44cbca3679f4cc2ac74/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.js#L136

opw-4922152
opw-4938953

Prior to this fix, when filtering on the `Next Activity Type` (e.g., “To-do”) in any model using `mail.activity.mixin`, records with  **done** activities were incorrectly included in the results — **if the corresponding activity type had keep_done=True**.

This regression was observed after upgrading to saas-18.1. It stems from the fact that the `activity_type_id` field was implemented as a related field across a one2many (`activity_ids.activity_type_id`). This led Odoo to use `_search_related`, which does not re-evaluate `active_test` during nested search queries.

1. Go to CRM -> Configuration -> Activity Types
2. Select an activity type (for example To-Do) and Set `keep_done = True` on the “To-do” activity type.
3. Go to CRM Pipeline or any App with a chatter , do an activity to-do and make it as done
3. In the search view, filter by `Next Activity Type = To-do`.  The record appears, even though the only “To-do” activity is done.

This is not the expected behavior — `Next Activity Type` should refer only to open (active) activities, regardless of chatter visibility settings (`keep_done`).

- Replace `activity_type_id` as a `related` field with a `computed` one.
- Ensure the compute method picks the first *not-done* activity by deadline.
- Update the `_search_activity_type_id` method to match only records with active activities of the given type.

This approach avoids low-level issues with `_search_related`, and properly respects the semantic meaning of "next" activity.

Task: 4843918

Steps to reproduce:
- Have the main company in USD
- Have 3 different currency rates in date 1, 2 and today
- Create a Vendor Bill in EUR in date 1
- Make Payment (EUR) in date 1, it should not have an associated move
- Create a Bank transaction, at date 2, matching the payment amount in EUR Bank Journal
- Make a batch payment including the created payment
- Open bank reconciliation of EUR Bank journal
- Select the transaction and the batch payment
- Validate

Issue: User Error will raise
```
The move (OTR/2017/00001) is not balanced.
The total of debits equals $ aaa and the total of credits equals $ bbb
You might want to specify a default account on journal "Bank other currency" to automatically balance each move.
```

This occurs because when retrieving the exchange rate values, amounts are converted using the payment values, computed at payment date. Later on, when we aggregate payment amounts, we convert manually the result without specifying a date, creating an issue in case the reconciliation date occurs after a rate change

Forward-Port-Of: odoo/enterprise#88299

**Steps to reproduce:**

- Install `sale_subscription`
- Create a recurring product (P1) and a non-recurring product (P2)
- Create a Sale Order (S1) with P1 (quantity > 0) and confirm it
- Create an upsell of S1 (new child order S2)
- In S2, edit the P1 line, and select P2
- Set quantity > 0 for P2
- Confirm S2

**Issue:**

After confirming the upsell order (S2), the quantity of P1 on the
original subscription (S1) is incorrectly increased by the quantity of
P2 from S2. The _compute_parent_line_id method did not reset the
parent_line_id when the product was not a subscription Product,
which caused it to incorrectly update the subscription

This issue is present in all three versions: **16.0, 17.0, and 18.0**.

**Solution:**

Reset parent_line_id to False if the product is not a subscription
product to prevent incorrect subscription updates.

[opw-4638955](https://www.odoo.com/odoo/project.task/project.task/4638955)

Forward-Port-Of: odoo/enterprise#90715
Forward-Port-Of: odoo/enterprise#88282

**Steps to reproduce**:
1. Install `l10n_cz` and `l10n_cz_reports_2025`.
2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill.
3. Go to Reporting → Tax Return → VAT Control Statement (CZ).
4. You will see the bill listed under section B2. Now export the XML.
5. In the exported XML, the field `dan_dppd` is present.

**Observations**:
When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`.
According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized.

**Issue**:
The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section.

**Solution**:
The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation.

opw-4868515

Forward-Port-Of: odoo/enterprise#90394