**Steps to reproduce:**
* Create a parent company with a branch company (Settings > Companies).
* Create a user whose **only** allowed company is the branch.
* While logged in as a parent-company admin, open the Miscellaneous Operations journal, find the first or second posted entry, reset it to draft, clear its name to a digits-only value (e.g. `0001`) and save – leaving it in draft state.  This stores `sequence_prefix = ''` and `sequence_number = 1` in the database.
* Log in as the branch-company user.
* Navigate to Accounting > Journal Entries > New.
* Set any date and save the draft entry (or simply write `name = '/'` on it).

**Observed behavior:**
* Saving fails with: `odoo.exceptions.AccessError: You are not allowed to access 'Journal Entry' (account.move) records.`

**Cause:**
* `_update_sequence_made_gap`, introduced in 19.0, detects sequence holes by running a raw SQL query that finds the two entries immediately before and after each move in the same journal with the same `sequence_prefix`. The query contains **no `company_id` filter**.

* In a branch-company setup the parent's journal (`journal_id`) is shared across companies.  When an early entry's `name` is cleared to a digits-only value its `sequence_prefix` becomes `''`.  A new entry created by the branch user also starts with `name = '/'`, which gives it `sequence_prefix = ''` and `sequence_number = 0`.  The SQL therefore returns the parent company's entry (`sequence_number = 1`, `sequence_prefix = ''`) as the `next_id` neighbour.

* The IDs from that query are passed to a local `browse()` closure, which in 19.0 read: https://github.com/odoo/odoo/blob/af37df9bee34fe60c1e51896af23fc7fe9b76cfc/addons/account/models/account_move.py#L5770-L5771

* `self.browse()` inherits the **non-sudo** environment of the branch user. When the method subsequently writes `move_n1.made_sequence_gap = …` on the browsed parent-company record, the ORM record-rule check finds the branch user has no access to that company → **`AccessError`**.

* This is a regression from 18.4 where the equivalent `_set_next_made_sequence_gap` explicitly used `.sudo()` when searching for neighbour moves: https://github.com/odoo/odoo/blob/22d84ae99bb79e7b1022367e6bc1b61cc8d9e8b1/addons/account/models/account_move.py#L5453-L5457

**Fix:**
* Add `.sudo()` inside the `browse()` closure so that neighbouring moves are always accessed with elevated rights, regardless of the calling user's company context.
* `made_sequence_gap` is a UI-only flag that indicates sequence holes; it carries no security or financial significance, making the sudo escalation safe.

opw-6231085

Forward-Port-Of: odoo/odoo#266676

…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118548
Forward-Port-Of: odoo/enterprise#114873

Steps to produce:
---
- Install the `Accounting` module.
- Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid).
- Log in as the portal user.
- Navigate to the invoices list and attempt to sort by **Status**.

Issue:-
---
- Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering.

Root cause:
---
- At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state.

Fix:
---
- Update the sorting configuration to use payment_state instead of state,
  ensuring that invoices are sorted correctly according to their payment
  status on the portal.

[1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52

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

Forward-Port-Of: odoo/odoo#262976

## [FIX] planning_field_service: avoid division by 0

Before this commit, when the shift is created during the weekend, the
allocated_percentage will be 0 percent because the resource assigned is
not supposed to work at that day and so a division by zero occured in
the onchange of break_time field in planning.slot model.

This commit checks if allocated_percentage is not equal to 0 before
computing the new allocated hours when the user alters break_time field
on a planning.slot.

## [FIX] planning_field_service: don't start test with onboarding tour with demo

Before this commit, the planning_field_service_tour tour does not work
when there is demo data because the tour will select the first slot in
the gantt view which will be an open shift instead of a shift assigned
to the current user because of that, the sign in button is not displayed
as expected.

This commit makes sure the test running the planning_field_service_tour
tour is skipped when demo data are installed.

runbot-error-242483

#### Description of the issue/feature this PR addresses:
The "Stock Account: Inventory Valuation Closing" cron is meant to post valuation journal entries for companies configured with periodic inventory valuation. Due to a faulty domain in ResCompany._cron_post_stock_valuation, monthly companies are never processed, and on the last day of the month daily companies are also skipped. As a result, no inventory valuation journal entries are ever generated by this cron for periodic-valuation companies.

#### Current behavior before PR:
The cron's domain requires inventory_period = 'daily', which excludes monthly companies on every non-last day of the month. On the last day of the month, an extra AND clause is added requiring inventory_period = 'monthly'. Combined with the existing 'daily' clause, this produces a contradiction (period = 'daily' AND period = 'monthly') that matches no records, so daily companies are dropped on that day as well. Net effect: monthly companies are never processed, and daily companies are skipped on month-end.

#### Desired behavior after PR is merged:
On a non-last day of the month, the cron processes companies with inventory_period = 'daily'. On the last day of the month, the cron processes both 'daily' and 'monthly' companies, so monthly valuation entries are posted at month-end without dropping daily companies.

opw-6115649

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

Forward-Port-Of: odoo/odoo#264782
Forward-Port-Of: odoo/odoo#264298

**Steps to reproduce:**
* Install *Türkiye - Nilvera* (`l10n_tr_nilvera`) module.
* Log in as *admin user*.
* Create a *partner* for the company.
  * Set *country* as Turkey.
  * Configure required *taxes*.
* Create a *demo user*.
* Grant the demo user *Accounting admin access*.
* Log in with the *demo user*.
* Navigate to *Contacts* → open the *Turkey company partner*.
* Navigate to *Nilvera Status* (via Invoicing/Accounting tab) click on *Verify*.

**Observed behavior:**
* A *company access error* is raised during partner verification.

**Cause:**
* The field *l10n_tr_nilvera_api_key* is restricted with `groups='base.group_system'`, requiring full system admin rights.
* Users with *module-level admin access* (e.g., Accounting) do not have sufficient rights, causing the access error.

**Fix:**
* Use `sudo()` on `env.company` to bypass the restrictive group access.
* This allows users with appropriate *functional admin rights* to perform verification without granting full system privileges.

Ticket [link](https://www.odoo.com/odoo/project.task/6106907)
opw-6106907

Forward-Port-Of: odoo/odoo#262668

**Steps to reproduce:**
- Install Sales app
- Create a Sales Order
- Click on the 'Send by Email' action
- Add an attachment and send it
- Open the chatter to create a log note
- Attachment is attached to the new message
- It disappears on refresh

**Issue:**
Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`.

Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers.

But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`.

**Fix:**
Restrict the attachment save to the full composer using context.

[1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027
[2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3

opw-5164504

Forward-Port-Of: odoo/odoo#266994
Forward-Port-Of: odoo/odoo#265736

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.

Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212



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

Forward-Port-Of: odoo/odoo#264154
Forward-Port-Of: odoo/odoo#256636

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

Forward-Port-Of: odoo/enterprise#117112
Forward-Port-Of: odoo/enterprise#112482

The Inventory Valuation report at a past date rebuilds historical value by tracing stock moves. Two product.value lookups run on the hot path and both hit unindexed columns:

- stock.move._get_manual_value() searches product.value by move_id for every traced move;
- product.product._get_last_product_value() searches product.value by product_id.

product.value declares neither column with an index, so each lookup performs a sequential scan of the whole table. This is harmless on small tables but degrades sharply as product.value grows (one row is written per manual standard-price/move revaluation).

On a database where product.value held ~9.6M rows, the per-move move_id lookup seq-scans the entire table only to return nothing (no row carries a move_id), repeated for every traced move, so the historical report never completes.

Index product_id (dense) and move_id (btree_not_null, since it is null for every manual revaluation row). Each lookup then becomes an index scan.

Measured on a ~9.6M-row product.value, historical valuation report, single date:

| product.value lookup        | without index             | with index         |
| --------------------------- | ------------------------- | ------------------ |
| by product_id (DISTINCT ON) | ~0.56s (1.7 GB seq scan)  | index scan         |
| by move_id, per traced move | full seq scan, returns 0  | index scan         |
| report (~3.1M moves traced) | never completes (>20 min) | completes (~3 min) |

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

Forward-Port-Of: odoo/odoo#266790

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#266875
Forward-Port-Of: odoo/odoo#251993