Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243).

To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically.

However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge.

To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`).

This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16.

Task-5999878

Forward-Port-Of: odoo/enterprise#109379

**Steps to Reproduce:**
1. Install `hr_payroll` with demo data.
2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties.
3. Add a new property for Payroll and fill in the value also.
4. Go to Payroll > Configuration > Benefits.
5. Create a new benefit with:
   Salary Structure Type: Worker
   Cost Field: Payroll Properties (Employee Contract)
6. Save the record.

Video: https://drive.google.com/file/d/1gHRkDW5G0bURlo9_IRgCnvqpE-8Fk1xa/view?usp=drive_link

**Error:**
`TypeError - unsupported operand type(s) for +: 'int' and 'Property'`

**Cause:**
The method `_get_benefits_costs()` directly sums values using: 
```
self[benefit.cost_field]
```
When the selected cost field is a property field, it returns a **fields_properties.Property** object instead of a numeric value, and this object is not directly compatible with the arithmetic sum operation.

**Fix:**
This commit prevents selecting property fields as cost fields from the list of supported field types.

sentry-7388663038

Forward-Port-Of: odoo/enterprise#113238

When a user expands the report line of a no-depreciation asset
in the depreciation schedule report, a traceback is raised.

Steps to reproduce the error:
- Install ``account_asset`` module with demo data
- Go to Accounting > Accounting > Assets > Create a new asset >
  Set Depreciation Model: No depreciation and Fixed Asset Account > Confirm
- Go to Accounting > Review > Depreciation Schedule
- Select the current fiscal year in filters
- Expand the asset report line

Traceback:
```py
UnboundLocalError
cannot access local variable 'period_suffix' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/5edd033ce05d65a79bc5b21ad2d1559a1af78056/account_asset/models/account_assets_report.py#L388-L390
Here, ``period_suffix`` is only assigned when the asset method is ``linear`` or ``degressive``,
For assets using the ``no_depreciation`` method, the variable remains undefined,
leading to the traceback when returning the depreciation rate string.

sentry-7504906018

**Problem:**
Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard "New" label.

**Steps to reproduce:**
1. Settings / Technical / Discuss / Link Previews
2. New
3. Observe the breadcrumb

**Current behavior:**
The breadcrumb displays `mail.link.preview,<id>`.

**Expected behavior:**
The breadcrumb should display "New" until the record is saved, and the source URL once saved.

**Cause of the issue:**
The model defines no `name` field and does not set `_rec_name`, so the default `_compute_display_name` falls into its fallback branch and returns `f"{record._name},{record.id}"` — exposing the technical reference in the breadcrumb both for unsaved records (`NewId_...`) and saved ones.

**Fix:**
Setting `_rec_name = 'source_url'` lets the standard display name machinery compute a meaningful label from the existing required field. Unsaved records then surface the standard "New" placeholder via the web client and saved records surface their URL, without introducing a redundant `name` field or overriding the compute.

opw-6095012

Forward-Port-Of: odoo/odoo#263577

**Problem:**
When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders white-on-white in the field, and clicking the dropdown shows an empty-looking popup (white options on white system menu).

**Steps to reproduce:**
1. Enable dark mode in user preferences
2. Open Sign > Templates > duplicate any template
3. Add a Selection field with a few options (e.g. Low / Medium / High)
4. Save and Sign Now
5. Reach the Selection field and click it
6. Observe: the dropdown options are invisible (white on white) and, after picking one, the selected value in the field is also invisible

**Cause of the issue:**
The Selection sign item is rendered with a native `<select>` element inside the PDF.js iframe (`sign_items.xml`, `t-if="type == 'selection'"` branch). The iframe's stylesheet (`sign/static/src/css/iframe.css`) declares the `select` rule with `background: transparent` but no explicit `color`, and never styles `<option>` at all. When the OS or the user activates dark mode, the iframe document resolves to a `color-scheme: light dark` root, so the browser's UA stylesheet paints form controls with the dark palette (white text). The popup background stays white (`<option>` has no explicit background), so options render white-on-white. The same UA-white propagates to the displayed value of the `<select>` inside the pink-tinted sign item, which is also nearly white.

**Fix:**
Pinning the `<select>` text color and the `<option>` color/background to fixed light-mode values restores predictable contrast inside the iframe regardless of the surrounding color scheme. We deliberately do not rely on `color-scheme: dark` here — that would only swap which side of the contrast issue we land on (browsers don't reliably honor it for `<option>` background painting), and the sign item background (the pink dashed default style) is itself light, so dark option text on a white popup is the readable target in all themes.

opw-6197638

Forward-Port-Of: odoo/enterprise#117697

# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
	- Name : X
	- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)

# The problem
We see both records even tho we should only see one

# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589

In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601

The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.

opw-6224811

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

Forward-Port-Of: odoo/odoo#266231
Forward-Port-Of: odoo/odoo#265835

Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes.

This occurred because the method manually injects the new Addenda string at the end of the XML without checking if one was already present from a previous execution.

According to the SAT's Anexo 20 and the CFDI 4.0 XSD, the Addenda must be a single node and the last element of the Comprobante. Duplicating root-level nodes like `cfdi:Addenda` is a bad XML formation practice that can cause rejection by the recipient's automated systems.

This fix ensures the CFDI structure remains valid by:
1. Searching for an existing `{*}Addenda` node in the CFDI string.
2. Removing the old node before reconstructing the XML.
3. Preventing the string replacement logic from stacking multiple Addenda blocks.

This ensures that the CFDI remains clean and compliant with the official standard even if the process is triggered multiple times.

Forward-Port-Of: odoo/enterprise#109760

**Problem**:
When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers.

**Before this commit:**
If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving.

**After this commit:**
Only SN-002 and SN-003 will be added to the move, which matches the quantity.

**Steps to reproduce:**
1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product.
2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0.
3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking.
4. SN-001 will be added to the move automatically, but the quantity stays at 2.

opw-6121208

Forward-Port-Of: odoo/odoo#266583
Forward-Port-Of: odoo/odoo#263080

**Steps to Reproduce**

1. Install the **Live Chat** module in version 18.4 or above.
2. Go to: **Settings → Users**
   * Open your user and change the access rights from **Live Chat / Administrator** to **Live Chat / User**.
   * Alternatively, create a new user giving him rights of the **Live Chat / User** group.
3. Login using the Live Chat user.
4. Open the **Live Chat** application and navigate to: **Live Chat → Sessions**
5. Open any existing session. The session and its messages are accessible without any issue.
6. In the search bar, click: **Filters → Custom Filter**
7. Select the field `Chatbot Messages (chatbot_message_ids)`. You will face the below traceback.

**Issue Description:**
The issue happens because `discuss.channel` records are accessible to users having the `im_livechat_group_user` group through the Sessions menu: https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/views/im_livechat_channel_views.xml#L310-L315

The field `chatbot_message_ids` is defined as:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/models/discuss_channel.py#L165

This field points to the `chatbot.message` model, but access to that model is restricted to `im_livechat_group_manager` only:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/security/ir.model.access.csv#L15

As a result, when a Live Chat user tries to use `chatbot_message_ids` in a custom filter, Odoo attempts to read `chatbot.message` records and raises an `AccessError`.

This issue started happening after the access rights changes introduced in pr : https://github.com/odoo/odoo/pull/201880

Specifically, the following ACL changes:
https://github.com/odoo/odoo/pull/201880/changes#diff-c1592d633a34db44a7cc2a527482cecc56127cbba72649e7318dcf63ccf477afR19-R20

**Solution:**
To fix this issue, added the group `im_livechat_group_manager` on the field `chatbot_message_ids` so only those user can access the field who belong to the group.

**Traceback:**

```.py
odoo.exceptions.AccessError: You are not allowed to access
'Chatbot Message' (chatbot.message) records.

This operation is allowed for the following groups:
        - Live Chat/Administrator

Contact your administrator to request access if necessary.
```

opw - [6169395]
upg - [4274573]



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#266817
Forward-Port-Of: odoo/odoo#264682

**Steps to reproduce**
- Have user A with Sign admin rights and user B without Sign rights.
- With user A, create a sign request activity on a record that user B can access. Send the signature request.
- With user B, try to access the record. -> AccessError when trying to fetch the chatter.

**Cause**
By default, users get access to all the activities associated to records they have access to (see `_search` of `mail.activity`). This is an issue since some of the fields added in `_store_activity_fields` for the sign request activity display might not be accessible for a user with access to the activity.

**Change**
Use `sudo` to be able to display the activity, even if the user doesn't have access to the sign request.
Also, in that case, `can_write` should be `False` in order to hide the action buttons of the activity, which trigger access errors when trying to make operations on the sign request.

Another related change is to create the activity for the user creating the sign request, this avoids falling back on the `user_id` of the record associated with the activity and makes sure the activity's user has access to the sign request.

opw-6157455

Forward-Port-Of: odoo/enterprise#116540

Versions
--------
- saas-19.3+

Steps
-----
1. Go to the product page in editor mode.
2. Press the "Add More" button next to "Extra Media"
3. Add an image by URL.
4. Select the new image and press "Add".

Issue
-----
Traceback
```python
Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/router.py", line 432, in serve_db
    return retrying(serve_func, env=request.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ...
  File "/data/build/odoo/addons/website_sale/controllers/main.py", line 757, in add_product_media
    product_product.write({"product_variant_image_ids": media_create_data})
  ...
  File "/data/build/odoo/odoo/orm/fields_binary.py", line 84, in convert_to_cache
    raise TypeError(f'{self}: use BinaryValue instead of {value.__class__.__name__}')
TypeError: product.image.image_1920: use BinaryValue instead of bytes
```

Cause
-----
When saving the image, the remote URL is fetched and the raw `bytes` are stored in the `product.image.image_1920` field. However, since commit 41fe2ebdb9cc37341362d7af829c087a5f72f9f1, raw `bytes` cannot be directly assigned to `Binary` fields.

Solution
--------
Use the new `BinaryBytes` wrapper.

See also:
- https://github.com/odoo/enterprise/pull/116273