# How to reproduce
- Install the Events, Porject & CRM apps
- Create two event A & B with tickets that can be purchased
- Go to Events > Configuration > Lead Generation
- Create a Lead Generation Rule with :
	- Create : Per Order
	- When : Attendees are created
	- Event : None
- Create a new quotation with two lines :
	- Product : Even Registration for event A 1st, then B
- Confirm the SO

# The problem
A traceback will appear

# Cause of the issue
When confirming the SO, we create `event.registrations`s that will check for
lead generation rules and create or update `crm.lead`s accordingly :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35

We will then group the registrations by leads & grouping model :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166

For all groups, if the lead does not exist, we create one :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187

`_get_lead_values()` works fine with multiple `event.registrations`s, but crashes
when those registrations does not have all the same event, which is our case :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170

# Proposed solution
Since we have multiple events and leads are associated to a single event :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11

We group the registrations by event and create multiple leads accordingly

opw-6167518

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

Forward-Port-Of: odoo/odoo#265017

**PROBLEM**
In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case.

**STEP TO REPRODUCE**

1. Install l10n_pe_edi
2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding
3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means).
4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount.

**CAUSE**
We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues.

opw-6010388

Forward-Port-Of: odoo/enterprise#113689

this pr fixes 3 bug, as all are closely related.

Step to reproduce (hide is_custom attr in kiosk mode):
- have two attributes A and B
- A has only 1 attribute value with is_custom = True
- B can have any two value ( ex. gender: male/female)
- use it on a product  and make it available in POS for kiosk
- start kiosk and open that product

Observation:
- we do not get option to select option from A but the heading is visible
- when we select from B, Add to cart is disabled.

Cause:
- we do not allow attribute values with is_custom = True in kiosk
- but we display the attribute regardless
- the Add to cart btn depends on `selectedValues`, which requires
value from each attribute, in this case, we are not seletion anything from A
- so it is disabled

Fix:
- we introduced  `attributesToDisplay` which will hide heading in case of single
custom value for any attribute
- for Add to cart, wenow do not expect value from `is_custom`  attribute values.

 Allow product with 1 attr which is `is_custom` to be
 configurable in configs other than kiosk) correct fix for commit

 Step to reproduce
- have attributes A
- A has only 1 attribute value with is_custom = True
- use it on a product and make it available in POS
- start pos and open that product

Observation:
- we do not get option to select add text for A

Cause:
- in pos, we consider product to be configurable only it has more than 1
attributes, which misses is_custom attr

Fix:
- we backport commit[1] and also considers its side effect by introducing
`isProductConfigurable` for pos_self_order, which will still avoid
`is_custom` attrs for kiosk

[1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7

Empty page is displayed if product has only `is_custom` attribute value
and other attribute with type other then 'no_variant' for combo item

 Step to reproduce
- have attributes A and B
- A has only 1 attribute value with is_custom = True
- B has two values with type "always"
- use it on a product and add that product in combo item and make it available
  in Kisok
- start kiosk and open that combo and select that product

Observation:
- we do not get option to select

Cause:
- `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
   values in attributeSelection component.

Fix:
- before mounting Attributeselection component, we check if product has required
  attribute or not.

opw-6100965

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

Forward-Port-Of: odoo/odoo#266138
Forward-Port-Of: odoo/odoo#257880

## Steps to reproduce:

1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
    1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
    2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
    1. Azure Interior is listed under /MasterFiles/Customers/Customer.
    2. There are no /MasterFiles/Suppliers.
    3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.

Video: [2]

## Explanation

This is one of several errors found with the FAIA export. See PR #113316 for more.

It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].

This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.

The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4].  This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.

The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.

The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.

> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate

[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173

opw-6107107

Forward-Port-Of: odoo/enterprise#117799

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

opw-6211908 

## Summary

When selecting a vendor price from `product.supplierinfo`, the purchase module converts `purchase.order.date_order` (a `fields.Datetime` stored in UTC) to a `date` using Python's `.date()` method. This extracts the **UTC calendar date** rather than the user's local date.

For users in positive-offset timezones (e.g. `Pacific/Auckland` UTC+12, `Africa/Johannesburg` UTC+2), this produces the wrong day, causing `product.supplierinfo` records with `date_start`/`date_end` to be incorrectly included or excluded during vendor price selection.

### Affected methods

| File | Method |
|------|--------|
| `addons/purchase/models/purchase_order_line.py` | `_compute_selected_seller_id` |
| `addons/purchase/models/purchase_order_line.py` | `_prepare_purchase_order_line` |
| `addons/purchase/models/purchase_order.py` | `_get_product_catalog_lines_data` |

### Fix

Replace `.date()` calls with `fields.Date.context_today(record, timestamp=...)` which correctly converts the UTC datetime to the user's timezone before extracting the date.

Also fixes `fields.Date.today()` → `fields.Date.context_today(self)` in `_prepare_purchase_order_line` for consistency (same issue — `fields.Date.today()` returns UTC date, not the user's local date).

## Steps to reproduce

1. Set user timezone to **Pacific/Auckland** (UTC+12).
2. Create a product with a vendor pricelist (`product.supplierinfo`) entry:
   - **Vendor**: any partner
   - **Price**: 50.00
   - **Start Date**: 2026-05-13
   - **End Date**: 2026-05-31
3. Create a **Purchase Order** for that vendor.
4. Set the **Order Deadline** to **2026-05-13 08:00** NZST (stored as `2026-05-12 20:00 UTC`).
5. Add the product as a line on the PO.

**Expected**: The supplier price of 50.00 is selected — the user's local date (May 13) is within the validity window.

**Actual**: No supplier price is matched. `.date()` on the UTC datetime returns `2026-05-12`, which is before `date_start` of `2026-05-13`, so the supplierinfo record is skipped.

Forward-Port-Of: odoo/odoo#266468
Forward-Port-Of: odoo/odoo#263992

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

### Steps to reproduce:

- In the settings enable: Multi-steps routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with a bom using the MTO Route
- In the Miscellaneous tab of the bom tick Batch Size and set it to 2
- Create and confirm a sale order for 6 units of P
#### > Three MO's are created but only the last one will update the quantities of the delivery at validation of the production.

### Cause of the issue:

The `move_dest_ids` of the `move_finished_ids` is only set on the last of the three productions. That is only the last MO is properly chained to the delivery via an MTO chain. This happens because the `move_dest_ids` field of the `mrp.production` model is a `One2Many` field: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L223-L224 Which implies that each move can be linked to at most one mrp.production via the `created_production_id` field. However, if you have set a batch size on your bom, it is expected for a single move to create multiple mo's. While the `move_dest_ids` of each of these MO is appropriately set in the create vals to be the mto `stock.move` of the delivery, due to the nature of the `created_production_id` field only the *last* mo will created with a set `move_dest_ids` as this is the only record that will be set as `created_production_id`. However, after the creation of these MO's, the related `move_finished_ids` will be recomputed:
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1089-L1093 However, the `move_dest_ids` of the created moves will be set to be either the `move_dest_ids` of their production (which is unset for all but the last one) or these of the first production of the same `production_group` that is these generated by a common production split: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1263-L1267
Now, since neither are set in our use case, the `move_dest_ids` will not be set on the `move_finished_ids` which implies in particular that the mto link between our productions (but the last one) and the delivery is lost.

Fix:

Since we can not change the nature of the `move_dest_ids` and `created_production_id` in stable to become Many2Many fields, we need to find a way to propagate the `move_dest_ids` on moves without relying on the probably inaccurate value provided by the production. And, since the compute of the `move_finished_ids` could be launched at many other points than during a create process (because of the many dependencies), we can not solely rely on the creation context but rather new to provide a way to recreate the link from relations at any given point. We therefore rely on the `stock.reference`'s similar to what was done prior to 19.0 via the `procurement_group_ids`: https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/mrp/models/mrp_production.py#L1198-L1202

opw-6188069

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

Forward-Port-Of: odoo/odoo#266184
Forward-Port-Of: odoo/odoo#264951

[FIX] website: improve carousel accessibility
    
    To improve keyboard accessibility on carousels, the indicators container
    is not focusable anymore, and the indicators themselves now only have
    one focusable button at a time.
    The tab order is thus: previous button > active indicator > next button.
    (The previous and next button may both appear before.)
    You can still navigate among indicators with the left and right arrows,
    which also moves the focus to the newly targetted indicator.
    
    Note that other accessibility improvements remain to be done on the
    carousels (add a pause/play button on auto-sliding carousels, place the
    buttons before the carousel slide in the tab order, add some aria
    attributes (roledescription, live), adaptative labels...).

[FIX] website: make focus visible on carousel arrows
    
    When focusing manually (with tab / shift+tab) the previous/next arrows
    in carousels, it is hard to follow where the focus is, because there is
    no outline and the contrast is too small.
    
    This commit adds a specific outline if the button is `:focus-visible`
    (with both black and white to work on any background).

[IMP] website: pause carousel on focus within
    
    Carousels are paused on hover (or touchstart), but if the focus is
    inside one, it won't pause. That can make it hard to navigate within
    interactive carousels during the sliding interval (e.g. the dynamic
    products, which by default has 4 different products with 3 different
    focusable links/buttons).
    This commit applies the same behavior on focusin as Bootstrap's default
    on mouseover, and on focusout as on mouseout.

[IMP] website: support home/end keys on carousels

    When the focus is in a carousel, pressing the "home" key displays the
    first slide and pressing the "end" key displays the last slide.

task-5470023

Forward-Port-Of: odoo/odoo#266428
Forward-Port-Of: odoo/odoo#244939

## Issue
When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but not the *Officer: Manage attendances* (`hr_attendance.group_hr_attendance_officer`) group, the user won't be able to see their own attendance on their own employee's form view.

Additionally, a user without no Employee group but with the *Officer: Manage attendances* group could not see the attendance smart button on other employees form view.

## Steps to reproduce
1. Install *Attendances* (`hr_attendance`)
2. Set Marc Demo's groups:
    - *Employees: Administrator*
    - *Officer: Manage attendances*: unchecked
    - *User: Read his own attendances*: checked (implied by Role / User)
3. Log in as Marc Demo and open his own form in Employees
4. **The attendance smart button is missing, even though Marc Demo has the group to see his own attendance.**

For the second issue:
1. Set Marc Demo's groups:
    - *Employees: No*
    - *Officer: Manage attendances*: checked
    - *User: Read his own attendances*: checked (implied by Role / User)
2. Log in as Marc Demo and open another employee's form
3. **The attendance smart button is missing, even though Marc Demo has
the group to manage other employee's attendance.**

## Cause
There are two employee views defined in `hr_attendance`: `hr_employee_public_view_form` and `view_employee_form_inherit_hr_attendance`. The two views have different conditions under which the attendance smart button is displayed:
- In the public view, which is seen by users who do not have the *Employee: Administrator* group, the button is only displayed if the employee form is the one of the current user.

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_public_views.xml#L9-L15

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr/models/hr_employee_public.py#L119-L123

**This means that a user without the _Employee: Administrator_ group cannot see the attendance button of other employees, even with the _Officer: Manage attendances_ group.** This view should take into account the *Attendance Manager* group.

- In the other view, which is displayed for users with the *Employee: Administrator* group, the button is only displayed for attendance officers.

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_view.xml#L24-L29

**This means that if a user is an Employee Administrator, but is not an Attendance Officer, they cannot see their own attendance, even with the "own attendance" group.** This second view should take into account the _User: Read his own attendances_ group.

opw-6167399

Forward-Port-Of: odoo/odoo#263826

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

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
We have two conflicting css styling on mobile:
- `overflow-hidden` was added for mobile to avoid multiple scroll bars
- `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css

This means that the element is present at the bottom of the page, but we can't get to it manually.
When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top).

Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter.

**Fix:**
Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed.

original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd

opw-6061993

Forward-Port-Of: odoo/enterprise#118134
Forward-Port-Of: odoo/enterprise#113168

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

This commit fixes several issues which can cause websocket messages to not be received:

1. If the IoT box does not have an IP when it first starts, the Websocket class will not be started (due to `@require_db`). It will remain closed even if the IoT box connects to the network shortly after.
2. If the IoT box does have an IP but can't reach the database when it starts, the Websocket client will crash due to a missing try/except around the request to get a session from the DB.
3. If the IoT box fails the first `send_all_devices` call, the websocket channel will not be set when the Websocket client starts. This causes no messages to be received, since it does not subscribe to the channel.

The changes are as follows:

1. The `@require_db` helper is removed from the Websocket client, and instead the server URL is provided explicitly.
2. Any exception raised by the session request is caught and logged, and the websocket can still continue connect attempts.
3. Instead of starting the websocket client after the first call to `send_all_devices`, it is started after the first *successful* call to `send_all_devices` so the channel is guaranteed to be set.
4. The closing status code is now logged as a warning instead of debug. This is to make it easier to troubleshoot websocket disconnections at a glance.

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

Forward-Port-Of: odoo/odoo#266710

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