Original PR description

Currently, when the user tries to open any activity of the knowledge article, 
it opens all articles instead of the one which has an activity assigned to them.

**Steps to reproduce this issue:**
1) Install the Knowledge module
2) Set up an activity for yourself on a Knowledge article 
3) Open the activities from Activities (top left corner)

**Issue:**
You will end up in the all articles list, with no filters applied.

**Cause:**
When the user clicks on the activities, a default search filter is added 
in the context, which is then applied on the view.

But in the knowledge article, we don't have any search filters for the activities.
Therefore, it renders all knowledge article records.

**Solution:**
Add search filters for the knowledge articles.

opw-4997201

Forward-Port-Of: odoo/enterprise#93609

Original PR description

**Step to reproduce:**
- install Attendances app
- turn on debug mode
- go to Attendance -> kiosk mode
- open the scanner

**Observation:**
- We get a traceback

**Cause:**
-  we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it
https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12
- this raises issue from OWL when we have debug-mode on

**Fix:**
- reuse the actual `scanBarcode` method and remove the faulty one.
https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60

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

Forward-Port-Of: odoo/odoo#227551
Forward-Port-Of: odoo/odoo#225738

Original PR description

**Steps to reproduce:**
    - Install industry_fsm_sale
    - Create a task template with "Under Warranty" enabled
    - Create a task from that template

**Issue:**
   The created task does not carry over the "Under Warranty" value from the task template.

**Cause:**
  The `under_warranty` field has `copy=False`, so the value is not transferred.

**Fix:**
   Updated the copy method to check for `copy_from_template` in the context. If the task template has "Under Warranty" enabled, the field is explicitly set on the new task.

task: 5083386

Original PR description

This commit addresses two corner cases that cause `fetch()` to crash:

Mixing new and real records:
- Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`.
- Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM.

Using `False` as a record id:
- Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called.
- Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error.

Forward-Port-Of: odoo/odoo#227447

Original PR description

**Description of the issue this PR addresses:**
------------------------------------------------

Pressing the ArrowUp key in the editing composer when it is empty while editing 
a message with only an attachment caused a JavaScript traceback. This happened 
because the composer was not associated with a thread, and the code tried to 
access `composer.thread.lastEditableMessageOfSelf`.

**Current behavior before PR:**
---------------------------------

- Pressing ArrowUp in the empty editing composer triggers a TypeError  
- The error occurs when editing a message that only has an attachment  
- The composer does not have a thread reference  

**Desired behavior after PR is merged:**
-----------------------------------------

- Pressing ArrowUp in this scenario safely checks if a thread exists  
- No TypeError occurs, and the composer remains stable  

**Task:** 5068553

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