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

[FIX] calendar_sms: calendar reminder event matching

The Issue
SMS reminders are sent to customers for calendar events regardless of whether they are scheduled for 1 hour before or 24 hours before; both reminders are sent.

Steps to Reproduce

1. Create two SMS reminders with different timings: one for 1 hour before the event and another for 24 hours before.
2. Create an attendee (since the calendar event administrator will not receive the SMS). Assign the attendee a phone number and an email.
3. Configure your SMS account to receive free credits (for local: create a SaaS and use its IAP token and UUID to link the IAP service).
4. Create two calendar events:
   - One that starts in 1 hour. (event_1h)
   - One that starts in 24 hours. (event_24h)
5. Add both reminders (1-hour and 24-hour reminders that we will call reminder_1h and reminder_24h) to each event and include the attendee you created. Accept the event invitation on behalf of the attendee.
6. Run the scheduled action that triggers event reminders.

Actual Behavior
For both events, both reminders are triggered.
for event_1h, reminder_1h and reminder_24h are sent.
for event_24h, reminder_1h and reminder_24h are sent.

Expected behavior:
For event_1h, reminder_1h is sent.
For event_24h, reminder_24h is sent.

Why Does This Happen?

After the SQL query, the result is a dictionary:

{"reminder_1h": "event_1h", "reminder_24h": "event_24h"}
(In reality, these should be IDs, but they are represented as strings for clarity.)

The code in the calendar_sms module retrieves all events from the dictionary, so we have a list with [event_1h, event_24h].
It also fetches the reminders that are in the keys of the dictionary (reminder_1h, reminder_24h).
Then it iterates through the events and for each event, checks if the reminders we have exist in the event.
If it exists, it sends an SMS.
(e.g., event_24h has both reminder_1h and reminder_24h linked to it, so it will send both reminders even if one states it starts in one hour, whereas it really starts in 24h).

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

Forward-Port-Of: odoo/odoo#212082
Forward-Port-Of: odoo/odoo#195782

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

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

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
--------
Up to 18.1:
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.

After 18.1:
Implied groups are now added via compute instead of write. No change needed, but leaving in the test.


opw-4676929

Forward-Port-Of: odoo/odoo#211933
Forward-Port-Of: odoo/odoo#207961

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#212256
Forward-Port-Of: odoo/odoo#211961

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

**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