Issue:
-------------------------
In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically.

Steps to Reproduce:
-------------------------
- Create an MO for a lot-tracked product.
- Assign a lot number to the product, then remove the assigned lot number.
- Notice that the component is automatically marked as Consumed.

With this commit:
-------------------------
Previously, removing the lot number triggered an `onchange`, which called `_set_qty_producing`. This method auto-marked the component as consumed. As a result, users cannot re-reserve the components using the Check Availability button unless they manually uncheck the Consumed field.

This commit updates the logic to ensure that removing an assigned lot does not trigger component consumption. This allows users to reassign and re-reserve components smoothly in the production flow.

Task ID: [4797711](https://www.odoo.com/odoo/all-tasks/4797711)

Forward-Port-Of: odoo/odoo#210571

Issue:
------------------------------------------
When we create MO having one picking, open this picking via Studio and switching 
to other view giving a ValidationError: `The modes in view_mode must not be 
duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of 
switching to the selected view.

How to reproduce:
------------------------------------------
1.Install Manufacturing,
2.Enable 2-step manufacturing,
3.Create MO for any product, e.g.Wood Panel
4.Go to the Transfers(having 1 picking),
5.Open Studio -> views -> Activate list view,
Switching to Studio list view giving a ValidationError.

Cause of the issue:
------------------------------------------
In the `action_view_mo_delivery` method when there is a single picking for the MO, only form 
view is passed in views, so it is not able to open other views.

Solution:
------------------------------------------
In action_view_mo_delivery for single picking passes the form view and append
the other views. This prevents the ValidationError and opens the 
selected view in Studio.

This is similar to the issue previously fixed in:
https://github.com/odoo/odoo/pull/37582

Forward-Port-Of: odoo/odoo#206269

Currently, an error occurs when loading sample data for **Attendances** if a referenced employee record has been deleted by the user.

**Steps to reproduce:**
- Install the `hr_appraisal` module without demo data.
- Load sample data for **Appraisals**.
- Navigate to **Employees** and delete record for **Emma Granger**.
- Install `hr_attendance` module and load sample data for **Attendances**.
- Observe the error.

**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/odoo/saas-18.2/addons/hr_skills/data/scenarios/hr_skills_scenario.xml:209, ...`

The error occurs because the method at [1] tries to load the `hr_skills_scenario.xml` file, which references a deleted `employee_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/odoo/blob/547327f30d2d4bf778b9d358dbea4b133d55188a/addons/hr_skills/models/hr_employee.py#L49
[2] - https://github.com/odoo/odoo/blob/5c1db495828a7fe8c6ec987de432b1916ad32922/addons/hr_skills/data/scenarios/hr_skills_scenario.xml#L210

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6426462322

Forward-Port-Of: odoo/odoo#207737

Versions
--------
- 17.0+

Steps
-----
1. Create a new internal user with some administrator rights;
2. set notification preference to "Handle in Odoo";
3. save changes;
4. switch user type to portal.

Issue
-----
Validation Error: The user cannot have more than one user types.

Cause
-----
In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super().write`[^1].
[^1]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1455-L1457

This was working fine until commit 141852dc6613c introduced the `_inverse_notification_type` method[^4]. It adds or removes the `mail.group_mail_notification_type_inbox` group from users when the `notification_type` gets changed.
[^4]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/addons/mail/models/res_users.py#L54-L58

In our first call to `UsersImplied.write`, we store the user as an internal user and call `super().write`. This unlinks `base.group_user`, links `base.group_portal` and sets `notification_type` to `email`.

Before returning from `super().write`, the `_inverse_notification_type` method gets triggered to unlink the inbox group, which will lead to a recursive call to `UsersImplied.write`.

The recursive call no longer registers the user as internal or being demoted, hence it will re-add `base.group_user` as an implied group[^2] of its still present administrator group, leading to the `api.constrains` violation in `_check_one_user_type`[^3], as we already have the `base.group_portal` group.
[^2]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1466-L1469
[^3]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L589-L599

Solution
--------
Add a context value when calling `super().write`. If this value is present in the current call, this indicates we are in a recursive write, and can return without adding/removing implied groups, as these will get handled later by the base call.

opw-4676929

Forward-Port-Of: odoo/odoo#207961

This reverts commit 2094747717be

Versions
--------
- 18.0+

Steps
-----
1. Create a service product that creates a task on order confirmation;
2. add an attribute that does not create variants;
3. add the product to an order;
4. confirm the order.

Issue
-----
1. The task is named as the attribute.
2. The line's `display_name` shows the attribute instead of the product.

Cause
-----
Commit 2094747717be removed the extra new line that was added before attribute-based line descriptions for custom attributes and attributes that create no variants.

This did not impact the task or display name in previous versions, as the default sale order description started with the product name, and could be replaced.
But as of 18.0, while the default sale order description still starts with the product name, it's no longer possible to replace it, hence it gets skipped to get the first line of the editable description, which in this case is the attribute name.

Solution
--------
By re-adding the empty line before the attribute descriptions, the display & task names will fall back on the product name.

See commit 47d223759f07 for display name & c3877b2acd74 for task names.

Also adds a test to prevent regression.

opw-4792351

Forward-Port-Of: odoo/odoo#211867

When mixing cross-dock (XD), MTO and MTS products, it may lead to
incorrect partners on the pickings.

To reproduce the issue:
1. Enable Multi-Routes
2. Edit the warehouse: 2-steps reception, 2-steps delivery
3. Unarchive MTO route
4. Setup 3 products:
   - Storable
   - Routes:
     - All with buy
     - One MTO
     - One XD
   - Same supplier
5. Create and confirm one SO for each product (starting with XD one),
   each one with a different customer
6. Validate the generated replenish
7. Confirm the PO
8. Process the receipts

Error: The internal pickings have the same defined partner, the
customer of the XD product.

There are two issues:
- The destination address of a purchase is defined on the PO level,
not the POL one
- When looking for a PO, the `_run_buy` mechanism doesn't filter on
the destination address

This explains why:
- All purchases are gathered on the same PO
- On the internal pickings, we will find the first destination address

Even though the first point is convenient, since the destination
address is defined on the PO level, it leads to incorrect results.
However, changing this on stable is too risky. The only (and sad)
thing we can do so far is the creation of an ICP that would split
all PO based on their destination address. On master, this address
will be defined on POL level.

OPW-4552316

Forward-Port-Of: odoo/odoo#211431

Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel.

This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float.

To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing.

Failing in Distro Build , python version >=3.10  raises a `TypeError`
build_error-110207

Forward-Port-Of: odoo/odoo#211782
Forward-Port-Of: odoo/odoo#210551

Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is unable to open and keeps loading with an error visible on the console. This is because when the session tries to open, the compute_discount_product_ids method is called which runs into an error because it cannot use the domain. Ideally, the pos screen should still load and give an alert message saying “The reward "xxx” contains an error in its domain, your domain must be compatible with the PoS client” and after closing the popup, the pos shop can be used however this does not happen as the code line for deleting the erroneous loyalty reward runs into an error because the delete method expects a record but receives an id. The alert message written before never appears because this delete statement runs into an error.

Purpose: Passing the correct argument to the delete function so that the loyalty program with issues in domain can be properly deleted from loaded models. After this correction, the pos session will load and there will be an alert warning the user of the reward error.

Steps to Reproduce on Runbot:
1. Choose any discount program for the pos shop. Open the reward pop up and choose to put the discount on specific products.
2. Edit domain in the “Discount Product Domain” and put <Products> <contains> <screen> in the rule `[("product_variant_ids", "ilike", "screen")]`. We can see 3 records here on the reward.
3. Save and close the program screen. Open the pos shop and check the console. The screen keeps loading and there is a traceback error in the console.

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

Forward-Port-Of: odoo/odoo#196875

Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds.

As a reminder, the "is typing..." feature in discuss is implemented as follow:
- when typing, notify `is_typing: true` once every 50 seconds.
- when stop typing for 5 seconds, notify `is_typing: false`.
- other members assume stop typing if nothing received after 60 seconds.

This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow

```
- time: 0sec.   -> is_typing: true sent + received
- time: 50sec.  -> is_typing: true sent + received
- time: 60sec.  -> is_typing: false (assuming stop typing)
- time: 100sec. -> is_typing: true sent + received
```

This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing.

This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime.

runbot-223760

Forward-Port-Of: odoo/odoo#211961

**Steps to reproduce:**
- Install l10n_cz_reports_2025
- Switch to a Czech company (e.g. CZ Company)

- Create a bill:
  * Customer: [a Czech customer]
  * Bill Reference: [any] (e.g. XYZ)
  * Invoice Lines: [a line with an amount higher than 10000 and a tax]
- Confirm the bill

- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "VAT Control Statement (CZ)" as Report
- Select a period covering the bill date

The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section.

**Issue:**
The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill.

According to the documentation:
https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 
For purchase-type documents, this field should have the bill reference as value.
It should identify the original reference coming from the vendor.
If there is no bill reference, the field should be empty.

opw-4737630

Forward-Port-Of: odoo/enterprise#85005