Issue before this commit:
=========================
When creating a product by adding a barcode using the Barcode Lookup service,
the product image was fetched properly but was not displayed in the UI.

Steps to Reproduce:
=========================
- Install the stock module.
- Enable the Stock Barcode Database.
- Add a valid API key for the Barcode Database.
- Create a product by adding a barcode available in the Barcode Lookup API.
- Notice that the product image is not displayed.

Cause of the issue:
=========================
This issue was introduced by this [PR](https://github.com/odoo/odoo/pull/244421), 
which improved the behaviour of **fields.Binary**. As a result, the image returned by 
the Barcode Lookup API was not converted to the expected binary format, preventing
it from being displayed in the UI.

With This Commit:
=========================
With this commit, convert the fetched image to the expected binary format 
before assigning it to the product, ensuring that it is displayed correctly in the UI.

opw-6434478

Forward-Port-Of: odoo/enterprise#126314

Steps to reproduce:
===================
1. Create a subscription product, allow one-time sale, sale price 5
2. Add a recurring price 10/month
3. On the pricelist, add an advanced rule: -10% for the monthly plan
4. Open the shop page and look at the product tile

Cause:
=======
On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`.

In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price

With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price.

Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan.
=> Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9).

Solution:
=========
The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`.

opw-6307398

Forward-Port-Of: odoo/enterprise#124815
Forward-Port-Of: odoo/enterprise#120872

**Issue:**
In the website builder, when entering "Edit" mode through "Edit" button, the main navbar is hidden.
An animation is moving the navbar upwards and a "d-none" class is added to it after a delay of 200ms to avoid it disappearing suddenly.
It is displayed again after saving the changes by removing the "d-none" class.
However, when entering "Edit" mode and leaving it quickly, it is possible that the code hiding the navbar is executed after the code displaying it again because of the 200ms setTimeout().

The issue is not reproducible in the UI directly, but the `test_32_website_background_colorpicker` tour is often failing with the following error:
```
FAILED: [53/65] Tour website_page_options → Step <b>Click Edit</b> to start designing your homepage. (trigger: body:has(:iframe body[is-ready=true]) .o_menu_systray .o_menu_systray_item.o_edit_website_container button).
Element (body:has(:iframe body[is-ready=true]) .o_menu_systray .o_menu_systray_item.o_edit_website_container button) has not been found.
TIMEOUT step failed to complete within 10000 ms.
```

During the tour several clicks on "Save" and "Edit" are executed, leading to the navbar being unavailable when trying to click on "Edit".

runbot-243712




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

Forward-Port-Of: odoo/odoo#278645

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

### Issue before this commit:
When generating a tax closing entry, the VAT credit carryover from the previous period is missing from the journal entry lines. This results in an incorrect net payable amount.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Vendor > Bills
3. Create a vendor bill with date in June and price > 0 (ex. 1000$) and the 15% tax that produce a 150$ VAT tax
4. Go to Customers > Invoices
5. Create an invoice with price > 0 (ex. 9000$), the date in July and the 15% tax that will produce a 1350$ VAT tax
6. Go to Tax Return and validate all opened months up to July and see that for June the balance is -150$
9. Then go to View Entries of July using the 3 dots next to the "submit" button and see that there is no mentioning of the 150$ carry over of credit from the month before

### Cause of the issue:
During a forward-port merge conflict resolution, the code block responsible for retrieving the historical balance from the receivable_account_id was wrongly removed ([diff](https://github.com/odoo/enterprise/compare/b760c1dbee6bfb628bae32041c5b5c7dcaa623a4..4ea95b0c15f5f791d088330596c64ece58effa44)). Consequently, the system only checked the advance_account_id for previous balances, completely ignoring existing credits parked in the standard receivable account.

### Reason to introduce the fix:
Restore the dropped logic and the _create_tax_receivable_current_line function. This ensures the tax closing process automatically factors in previous VAT credits from the receivable account, providing accurate closing entries out-of-the-box without requiring extra configuration from the user.

opw-6438648

**Issue**
When rental transfers are enabled and rental pickups/returns are processed through stock pickings, it may become impossible to perform a subsequent rental return through the rental return wizard.

**Steps to reproduce**
- Activate "Rental Transfers" in the settings
- Create a rental product P, tracked by serial number
- Create two serial numbers for P
- Create and confirm a rental order for 2 units of P
- Validate the pickup transfer
- Partially validate the return transfer without creating a backorder
- Open the rental order and click on "Return" 
-> The return wizard opens without any available serial number and validation fails with a serial number-related error.

**Cause**
When clicking on "Return", if there is no pending pickup/return transfer: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/models/sale_order.py#L62-L68 the rental return wizard is opened directly:
https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/models/sale_order.py#L316 No serial number is prefilled in the wizard because `returned_lot_ids` is empty: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L122-L124 This is because `returnable_lot_ids` is empty as well. `returnable_lot_ids` is computed while generating the wizard lines: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L38 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L47-L48 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L99-L106 and `returnable_lots` is empty because both `pickedup_lots` and `returned_lots` are. Those fields are currently only populated through the rental wizard flow: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L42-L43 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L160-L161 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L166-L167

Since this flow uses stock pickings instead of the rental wizard, those fields are never updated, preventing the wizard from determining any returnable serial number.

opw-6150305

Forward-Port-Of: odoo/enterprise#126594
Forward-Port-Of: odoo/enterprise#119257

When attempting to refund orders that were created with the "Consumidor Final" customer. The refund validation would crash with a TypeError instead of showing the proper error message.

Steps to reproduce:
-------------------
In POS with l10n_ec_edi module activated:
* Create a new order with "Consumidor Final" as customer
* Add products and pay the order
* Validate the order
* Attempt to refund this order

> Observation:
The refund validation would crash with:
TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid

Why the fix:
------------
The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError.

opw-6427113

Forward-Port-Of: odoo/enterprise#126308

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#126520

Steps to reproduce:

0. Create an employee with a fixed working schedule and an overtime ruleset, then enable Absence Management in attendances
1. Go to Attendances and make sure that the employee has no attendances recorded for the previous working day
2. Run the "Attendance: Detect Absences for employees" scheduled action
3. Observe the absence attendance created on the previous working day, along with the amount of overtime hours calculated
4. Create an attendance on the day that the absence was recorded
5. Observe that the overtime hours on the absence attendance are not updated 5a. If a full day attendance is recorded on that day, the overtime hours on the absence attendance should change to 0, since we've now recorded hours worked for the day

When an absence attendance is created from the Absence Management feature, overtime hours are calculated to represent the time the employee was unjustifiably absent on a given day. If an attendance is later created on the day the absence was recorded, the overtime hours should update to reflect the hours the employee actually worked. Changes were introduced in [this PR](https://github.com/odoo/odoo/pull/272447) that broke this functionality due to the use of `pytz`, which incorrectly calculated timezone offsets. This caused absence attendances to not be picked up by `_get_overtimes_to_update_domain()`, and overtime was not correctly updated. This commit ensures that we get proper time calculations with respect to the employees timezone.

[opw-6380343](https://www.odoo.com/odoo/my-tasks/6380343?debug=assets)

Forward-Port-Of: odoo/odoo#281613
Forward-Port-Of: odoo/odoo#279556

`#right-elements` (tax totals block) is floated (`float-end`). Per CSS spec, an `auto` margin on a floated element always resolves to 0, so the `ms-auto` class added by 9767e8f5c1da5a9c9e38472ad576ffa3c4e32075 is a no-op, leaving no gutter before adjacent content such as the legal notes paragraph.

Partial revert of 9767e8f5c1da5a9c9e38472ad576ffa3c4e32075

Steps to reproduce:
-------------------
* On a tax, set a multi-line paragraph in Legal Notes (Advanced Options tab)
* Apply it on an invoice line and print/preview the invoice PDF
> Observation: the legal notes text touches/overlaps the tax totals
table, with no spacing.

Why the fix:
------------
`ms-5` gives `#right-elements` a real left margin, restoring the spacing lost when `ms-auto` (a no-op on floats) replaced it.

BEFORE:
<img width="596" height="753" alt="Screenshot 2026-08-05 at 10 52 00" src="https://github.com/user-attachments/assets/c596d6e9-4b61-434c-9b38-3ff0797e7fa7" />
AFTER:
<img width="494" height="596" alt="Screenshot 2026-08-05 at 10 51 44" src="https://github.com/user-attachments/assets/f9a1792d-22c2-4586-9a75-53c4695f17e4" />


opw-6384085

Forward-Port-Of: odoo/odoo#280654

When attempting to refund orders that were created with the "Consumidor Final" customer. The refund validation would crash with a TypeError instead of showing the proper error message.

Steps to reproduce:
-------------------
In POS with l10n_ec_edi module activated:
* Create a new order with "Consumidor Final" as customer
* Add products and pay the order
* Validate the order
* Attempt to refund this order

> Observation:
The refund validation would crash with:
TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid

Why the fix:
------------
The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError.

opw-6427113

Forward-Port-Of: odoo/enterprise#126308

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#126520

### Problem

When an AI agent includes a document source whose underlying `ir.attachment`
has `res_field` set (e.g., an invoice PDF generated from a Sale Order),
triggering **Update With AI** from **Website → Site → Optimize SEO**
raises a `KeyError` in `_build_rag_context`.

### Steps to Reproduce

1. Open the **AI** app.
2. Configure the **Odoo Agent**.
3. Add a source → **Add From Documents**.
4. Select a document whose underlying `ir.attachment` has `res_field` set
   (e.g., an invoice PDF generated from a Sale Order).
5. Go to **Website → Site → Optimize SEO**.
6. Click **Update With AI**.
7. Observe the following error:

```
KeyError: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
```

[Video](https://drive.google.com/file/d/1AAg0AvC3TRQzMLhI9hWFuSarOTHzQE-b/view?usp=sharing)

### Root Cause

In `ai/models/ai_agent.py`, `_build_rag_context()` retrieves the
`ai.agent.source` records corresponding to the embeddings by searching on the
attachment checksum:

```python
agent_sources = self.env["ai.agent.source"].search([
    ("attachment_id.checksum", "in", embeddings_attachment_checksums),
    ("agent_id", "=", self.id),
])
```

This domain traverses `attachment_id.checksum`, which internally calls
`ir.attachment._search()`.

As part of the standard attachment search behavior,
`ir.attachment._search()` automatically injects a
`('res_field', '=', False)` filter unless:

- `skip_res_field_check=True` is set in the context,
- the domain explicitly references `id` or `res_field`, or
- `bypass_access` is enabled.

```python
domain = Domain(domain)
if (
    not self.env.context.get("skip_res_field_check")
    and not any(d.field_expr in ("id", "res_field") for d in domain.iter_conditions())
    and not bypass_access
):
    disable_binary_fields_attachments = True
    domain &= Domain("res_field", "=", False)
```

[Reference](https://github.com/odoo/odoo/blob/19.0/odoo/addons/base/models/ir_attachment.py#L630)

Because of this implicit filter, attachments with `res_field` set are excluded
from the search. Consequently, `agent_sources` does not contain all the sources
corresponding to the retrieved embeddings.

Later, `_build_rag_context()` builds a checksum-to-source mapping:

```python
source_map = {
    source.attachment_id.checksum: source
    for source in agent_sources
}

for embedding in similar_embeddings:
    checksum = embedding.attachment_id.checksum
    agent_source = source_map[checksum]
```

Since `source_map` is built from the incomplete `agent_sources` recordset, it is
missing entries for attachments filtered by `ir.attachment._search()`.
However, `similar_embeddings` still contains embeddings for those attachments.

As a result, the lookup:

```python
agent_source = source_map[checksum]
```

raises a `KeyError`.

### Solution

Bypass the implicit `res_field` filter when searching `ai.agent.source`:

```python
agent_sources = (
    self.env["ai.agent.source"]
    .with_context(skip_res_field_check=True)
    .search([
        ("attachment_id.checksum", "in", embeddings_attachment_checksums),
        ("agent_id", "=", self.id),
    ])
)
```

This ensures that all `ai.agent.source` records matching the requested
attachment checksums are returned, including those referencing attachments with
`res_field` set. As a result, `source_map` contains all expected entries and
`_build_rag_context()` no longer raises a `KeyError`.

opw-6379816

Steps to reproduce:
-------------------
1. Install `l10n_mx_edi_pos` and set the company to Mexico.
2. In PoS, make an order with one product and pay it.
3. Open the order in the backend, click "Return Products" to make a refund, but don't pay it, cancel it instead.
4. From the same order, click "Return Products" again to make a second refund, and pay it normally.
5. Go to the orders list, select the main order and the paid refund (not the cancelled one), then Actions > Create Global Invoice.

-> Observation: error in the global invoice.

In the CFDI tab of the main order the line is "Send Global In Error", and hovering on it the detail says "Failed to distribute some negative lines".

Why:
----
When we make the global invoice, we remove the refunds from the order. A cancelled refund was never paid, so we should not count it. But we were counting it too. So we removed the refund amount twice in our case, one for the paid refund, and one for the cancelled one, and we end up with an order with negative amount that cannot be distributed.

The fix:
--------
We now skip the cancelled orders when we search the refunds, the same way it is done above when we collect the refunded orders.

opw-6261404

Forward-Port-Of: odoo/enterprise#127454
Forward-Port-Of: odoo/enterprise#120996

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#126614
Forward-Port-Of: odoo/enterprise#119262

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#124096

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

## Behavior Before the PR
When an employee did not have explicit `hours_from` and `hours_to` values defined, their shift was in the **Schedule by X** pivot view but was not included in the **Planning / Timesheets Analysis** report.

## Steps to Reproduce
1. Create an employee with a Flexible Working Schedule in the Employee form, or configure working hours where both `Hour from` and `Hour to` are left unset.
2. Add a shift for this employee linked to a project and a task.
3. Publish the shift.
4. Navigate to **Planning → Schedule → By Project**, switch to the pivot view, and observe that the shift created in step 2 appears and is counted.
5. Navigate to **Planning → Reporting → Planning / Timesheets Analysis**, switch to the pivot view, and observe that the same shift does not appear.

## Behavior After the PR
When an employee does not have explicit `hours_from` and `hours_to` values, their shift is now considered valid in both the **Schedule by X** views and the **Planning / Timesheets Analysis** report.

## Additional Notes
- In earlier versions of Odoo, the `Work From` and `Work To` fields were mandatory. With a change to flexible working schedules and the option to define only the total number of hours per day, these fields may now be left empty. This change exposed the underlying issue addressed by this fix.

task-[5969788](https://www.odoo.com/odoo/project/4105/tasks/5969788)

Forward-Port-Of: odoo/enterprise#127300
Forward-Port-Of: odoo/enterprise#110606

## Current behavior:
The user Partner Commissions access rights as All Documents or Own Documents and Purchase access rights as User. With this configuration, the user is unable to create new Purchase Orders, and existing Purchase Orders are also not visible in the Purchase module.

## Expected behavior:
The expected behavior is that the user should be able to create and view Purchase Orders with these access rights. Additionally, clarification is required regarding the purpose of the new Partner Commissions access group.

## Steps to reproduce:
- Go to user and assign Partner Commission rights as All or own document.
- On Purchase, select group as User.

## Cause of the issue:
partner_commission adds commission-specific purchase order record rules, but purchase users have no matching purchase-order rule in that module. For mixed-role users, the commission rule ends up restricting standard purchase orders as well.

## Fix:
Apply the module's explicit all-purchase rule to purchase users so mixed users keep base procurement access while commission-only users remain restricted by the commission rules.

opw-6366074

Forward-Port-Of: odoo/enterprise#127188
Forward-Port-Of: odoo/enterprise#126003

Issue before this commit:
=========================
When creating a product by adding a barcode using the Barcode Lookup service,
the product image was fetched properly but was not displayed in the UI.

Steps to Reproduce:
=========================
- Install the stock module.
- Enable the Stock Barcode Database.
- Add a valid API key for the Barcode Database.
- Create a product by adding a barcode available in the Barcode Lookup API.
- Notice that the product image is not displayed.

Cause of the issue:
=========================
This issue was introduced by this [PR](https://github.com/odoo/odoo/pull/244421), 
which improved the behaviour of **fields.Binary**. As a result, the image returned by 
the Barcode Lookup API was not converted to the expected binary format, preventing
it from being displayed in the UI.

With This Commit:
=========================
With this commit, convert the fetched image to the expected binary format 
before assigning it to the product, ensuring that it is displayed correctly in the UI.

opw-6434478

Forward-Port-Of: odoo/enterprise#126314

Steps to reproduce
---
1. Enable Storage Locations and Lots & Serial Numbers.
2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1.
3. Confirm a receipt reserving 2 units of that product; putaway sets the reserved move line destination to WH/Stock/Shelf 1.
4. In the Barcode app, scan a first lot, then a second lot.

The second lot lands on a separate line at WH/Stock instead of WH/Stock/Shelf 1.

Issue
---
The first lot reuses the reserved line and keeps its Shelf 1 destination. The second lot cannot reuse it because its tracking number differs, so `_findLine` returns nothing and `_getNewLineDefaultValues` builds a new line with `location_dest_id` set to `_defaultDestLocation()`, the picking's default destination (WH/Stock).

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L1591-L1601

Putaway relocates the destination on the move line at reservation, never on the picking, so only the reserved line carries Shelf 1. Since `groupKey` includes `location_dest_id`, the new line does not group with the first lot and shows separately at WH/Stock. This is not a regression: new lines have always defaulted to the operation destination.

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L239-L241

The new line now inherits the selected line's `location_dest_id`, already relocated by putaway, instead of the default.

opw-6317077

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#126520

**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Start Date** and **End Date** fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Reports → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written.
* Inside the header loop, set `annotations_header_written = True` after writing the header.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header.

opw-6354473

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 instead of assigning swiss contract type to the non-swiss emp.

Note: I started to fix it from 17.0 BUT:

. in above versions field overwrite might be in different CH modules . fix all in the above versions

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358