# 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

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

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606

Forward-Port-Of: odoo/odoo#266111
Forward-Port-Of: odoo/odoo#259370

[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

**Issue:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

Forward-Port-Of: odoo/enterprise#118206
Forward-Port-Of: odoo/enterprise#117921

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

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

Steps to reproduce:
1.Open the website in Edit mode.
2.Add a snippet with an image.
3.Replace the image.
4.After replacing image, double-click on it to open the Media Dialog.
5.Inside the Media Dialog, double-click on the same or any other image.
6.Traceback occurs.

Before this commit:
parentElement was becoming null because parentElement is a DOM
position check.it requires the element to be physically attached in
the DOM tree to find its parent.Since this.props.node is not yet in
the DOM at that point, parentElement returns null.

After this commit:
1.The issue is fixed using a boolean flag: isProcessingClick. Initially,
the flag is set to false. When the first click starts, it is updated to
true. If another click occurs during the same flow
(e.g during a double click), isProcessingClick is already true, so the
function immediately returns and prevents the action from being executed
multiple times.
2.we now pass closestSnippetEl directly from replaceMedia() through
params.this allows the dialog taken snippet reference using
(closestElement(mediaEl , "[data-snippet]")) without depending on the
media node being attached to the DOM.

task-6033320


Forward-Port-Of: odoo/odoo#266664
Forward-Port-Of: odoo/odoo#254790

Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

Forward-Port-Of: odoo/enterprise#118511
Forward-Port-Of: odoo/enterprise#115409

Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

Forward-Port-Of: odoo/enterprise#118511
Forward-Port-Of: odoo/enterprise#115409

It is possible to order as many products as we want of a rental product
that synchronizes shifts depending on a specific service

Steps to reproduce:
1. Install website_sale_renting_planning module
2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period
3. In the General Information tab, click on the internal link to "Developer"
4. Enable Sync Shifts and Rental Orders
5. Go to the eCommerce website and search for product "test"
6. You can add as many quantity of the product to your cart

Issue:
We don't limit the maximum quantity of the product

Solution:
Look through the renting availabilities of the product and set the
maximum quantity to the minimum of the availabilities relevant to the
renting dates selected

opw-6009928

Forward-Port-Of: odoo/enterprise#118332
Forward-Port-Of: odoo/enterprise#111793

## Problem

When creating a database with a country selected (e.g. India, or any 
country with a localization module), installing point_of_sale with demo 
data enabled raises a UserError about a missing bank journal, causing 
the entire demo data installation to fail with this warning:

  Module point_of_sale demo data failed to install, installed without demo data

The issue does NOT occur when no country is selected during database 
creation, because Odoo falls back to generic_coa which sets up all 
journals before POS demo data loads.

## Root Cause

Module loading follows this sequence:
  data -> demo -> state='installed' -> commit

When a localization module (e.g. l10n_in) reaches the installed state, 
the IrModule.write override detects the missing chart template on the 
main company and stores try_loading on registry._auto_install_template.

However, this deferred loading is only executed in _register_hook, which 
runs after ALL modules have finished loading.

When point_of_sale loads after l10n_in but before _register_hook fires, 
its demo data calls load_onboarding_furniture_scenario() which calls 
_create_journal_and_payment_methods(). At this point the bank journal 
from the localization has not been created yet, causing the crash.

Debug proof:
  With India selected at DB creation:
    Chart Template: False
    Journals available: Cash Furn. Shop (cash), Point of Sale (general)
    Bank journal found: False  <- causes UserError

  With no country selected:
    Chart Template: generic_coa
    Journals available: Bank (bank), Cash (cash), Customer Invoices (sale), ...
    Bank journal found: True   <- works fine

## Fix

Add a cr.precommit call in IrModule.write to execute 
_auto_install_template. This ensures the chart template and its journals 
get loaded at the end of the localization module's loading cycle (at its 
commit), making the bank journal available for subsequent modules like 
point_of_sale during their loading phase.

The _register_hook fallback is kept as a safety measure and now simply 
acts as a no-op if the precommit already handled the installation.

## Steps to Reproduce

1. Create a new database from /web/database/manager
2. Enable Load Demo Data
3. Select any country (e.g. India)
4. Login and install point_of_sale
5. Observe warning: Module point_of_sale demo data failed to install

## Expected Result

point_of_sale demo data installs successfully regardless of which 
country/localization is selected at database creation.