_(updates on July-17th and July-28th for points 2. and 3. in `hr_expense`)_

# Introduction
**1\.** A fix to `hr_org_chart` was initially proposed.
I think it is mergeable because it fixes the user-experience properly like expected in Odoo standard.

Other commits are suggested to `hr_expense`.
They were designed to allow more flexibility in the management of `hr_employee.company_id` (in multi-company context) and allow not to duplicate the `hr.employee` of each companies of the `res.users`.
**2\.** The [FIX] silences a multi-company access error when searching for Expense validators => it seems safe
**3\.** The [IMP] largely allow more flexibility for a "Expense: Team Approver" when creating expenses on behalf of its subordinates

# 1. in hr_org_chart [FIX]
Prevents multi-company error when recursively searching for ancestors.

<img width="1035" height="789" alt="image" src="https://github.com/user-attachments/assets/d5517f79-7efc-4223-ae77-0af8b25a3d1e" />

### Issue description

In a multi-company environment, when one of the `hr_employee.company_id` of a hierarchy is not in the allowed companies of a Manager's `res_users.company_ids`, this Manager can view `hr.employee` in the list view but cannot open their forms.

This happens when:
- `hr_org_chart` module is installed
- the Org Chart is displayed on the 1st page of the `hr.employee` form, like when the HR settings "Skills Management" is disabled (in `res.settings`) => thus the whole form becomes inaccessible from the manager

When a `hr.employee` form is opened, a multi-company access error is thrown to him, even if the `company_id` of the opened `hr.employee` is in the user's `res_users.company_ids`, because of the hierarchy's `company_id`.
It should be expected that the part of the Org Chart which is not allowed to be seen would just be hidden. 

### Steps to reproduce
Data setup:
- Employee "A" in company A
- Manager "M" in company A, manager of "Employee A"
- Manager of manager "MM" in company A, manager of "Manager M"
- And now, in company B (let's say a Holding), the "Director" is manager of "Manager MM"
- "Manager M" is only given access access to Company A
- the module "hr_org_chart" is installed

Actions:
- Login with Manager M
- Browse to Employees list and try and open the form of "Employee A" (up to tab _"Professional information"_, if it is not the 1st of the notebook)

### Proposed fix

This PR re-uses the already existing method `_check_employee` which contains all the logic to solve the issue. Maybe the call to this method was forgotten?
This PR simply call this method when finding an ancestor, in the controller of `hr_org_chart`. This fix is thus very limited to the call to the public method `hr_org_chart.get_org_chart()` made by the Org Chart widget.

### Desired behavior after PR is merged

The part of the Org Chart not allowed to be seen by "Manager M" is hidden.


# 2. hr_expense [FIX]

<img width="541" height="415" alt="image" src="https://github.com/user-attachments/assets/d594815b-2b77-4088-878b-9b192b64d6a3" />

### Issue description
As an employee, I click on the button "View Report" on my expense.
I get a multi-company access error, preventing me to view and edit my expense report.
This is because the manager of the department I belong is in a company I'm not allowed to see.

This can also happen just when opening my Expense (instead of Expense Report).

### Current behavior before this PR
The employee is blocked to continue editing its Expense or to submit it to a Report.

### Current behavior after this PR
The employee can edit and submit its Expense no matter the `company_id` of its hierarchy.
Technically: the `can_approve` field on the expense sheet uses a localized `.sudo()` method to bypass multi-company limits when searching if the current user is a validator.



# 3. hr_expense [IMP]

<img width="1028" height="549" alt="image" src="https://github.com/user-attachments/assets/1096c0d4-d025-46a9-8559-6bab5de71577" />

### Improvement summary
In multi-company environment, allow a "Expense: Team Approver" to create Expenses for its subordinates (`hr_expense.employee_id`) **no matter the `hr_employee.company_id` of its subordinates**.
The domain of `hr_expense.employee_id` keeps the security of `check_company=True` => thus the Manager only sees `hr.employee` having their `company_id` in the manager's allowed companies (`res_users.company_ids`).

### Current behavior before this PR
Context: a 8-companies environment where the `hr.employee` of each hierarchy chains are splitted in many different companies, like:
- top-level (admin board): 1 company
- middle management: approx. 2 companies
- down level: the other companies
The "down level" have `hr.employee` but no `res.users`. The "middle management" have `res.users` and must create the Expenses of their "down level" subordinates on their behalf.

Issue: as a manager, as per Odoo proposal, I need to have a `hr.employee` in the same company of my subordinates to be able to create Expense of their behalf.
However, this is very inconvenient because as a Manager, I can have employees in various companies. And my own manager it not in the same company than me, so the same issue applies recursively.

### Behavior after this PR is merged
The domain of the field `expense_id.employee_id` is more permissive. As a Manager, it allows me to select the Employee I manage in my active company, no matter if I have or not myself a `hr.employee` in this company.

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

Forward-Port-Of: odoo/odoo#286293
Forward-Port-Of: odoo/odoo#266261

## Issue Before This Commit:
The forecasted report icon stays green instead of red for an
out-of-stock product (forecast issue) on a sale order line
when sale_stock_renting is installed. 

## Steps to Reproduce:
 - Install `sale_stock_renting`,
 - Create a new sale order,
 - Add an out-of-stock product to the sale order,
 - Observe the forecasted report icon on the sale order line,
    The icon appears green.

## Cause of the Issue:
As part of the Owl 3 migration in PR [#270478](https://github.com/odoo/odoo/pull/270478), `calcData` was
changed from a regular object to a computed value:
`this.calcData = {}` was replaced with
`calcData = computed(() => this.initCalcData())`.
    
The corresponding template usage was not updated and continued to
access `calcData` as a property instead of calling the computed
value. As a result, `this.calcData.forecasted_issue` evaluated to
`undefined`, preventing the `text-danger` class from being applied
when there was a forecast issue.

## With This Commit:
The template now invokes `this.calcData()` correctly, allowing
`forecasted_issue` to be evaluated and ensuring that the forecasted
report icon turns red when the product is unavailable.

Issue:
A user following a task in a private project can be allowed to read the task without having access to its parent project. If the task contains a legacy or desynchronized attachment without a related document, opening the task can nevertheless raise an AccessError while loading the chatter.

Steps to reproduce:
- Create a follower only private project and a task in that project
- Add an internal user as a follower of the task but not of the project
- Leave a task attachment without its expected documents.document link
- Open the task as that follower

Cause:

When computing the attachment's linked document, `_exclude_documents_mixin()` calls `_check_create_documents()` on the linked business record with the requesting user's permissions. That eligibility hook may consult protected records such as the task's private project, even though it is only used to classify the attachment. https://github.com/odoo/enterprise/blob/656469d08453a823979153200cddd3688f815468/documents/models/ir_attachment.py#L41-L53

Solution:
Evaluate only the document creation eligibility hook with elevated rights. This keeps chatter metadata independent from access to the hook's related configuration while leaving attachment access, document lookup, and explicit document creation checks under the requesting user's permissions.

opw-6479654

Forward-Port-Of: odoo/enterprise#128929

Problem:
Interrupted uploads or malformed email payloads can create 0-byte binary `ir.attachment` records where the `checksum` is `False`. Accessing the computed `image_src` field on these records triggers a `TypeError: 'bool' object is not subscriptable` when attempting to slice `attachment.checksum[:8]`. This crashes the Media Dialog and Chatter.

Purpose:
Add a fallback boolean guard to `attachment.checksum` inside `_compute_image_src` so that empty attachments evaluate safely to a string ('0') instead of raising a traceback, allowing the UI to render gracefully.

Steps to Reproduce on Runbot:
1. Go to Settings > Technical > Database Structure > Attachments.
2. Create a new record: Name: `test.png`, Type: `File` (Binary), File Content: [leave empty], Is public document: Checked.
3. Open any record with a Chatter (e.g., Contact or CRM Lead) and click "Insert Image" to open the Media Dialog.
4. The system attempts to evaluate `image_src` and throws the `TypeError`.

Notes:
A test (`test_compute_image_src_empty_checksum`) was added to `test_ir_attachment.py`

opw-6482674

Forward-Port-Of: odoo/odoo#287953
Forward-Port-Of: odoo/odoo#287444

Version-19.5

Steps to reproduce:
- As Administrator, go to Sign > Templates and create a template.
- Add a custom field (e.g. 'B-day'), uncheck 'Shared' and set 'Used by' to a group the sender/signer does not belong to (e.g. an HR group).
- Place the field on the document and save.
- Share the template via its 'Authorized Groups' field (not 'Authorized Users') with a group the sending user belongs to.
- Log in as that user, open the template, click "Sign now", assign a signer and sign now.

Issue:
`_check_send_ready()` and `_populate_constant_items()` read `item.type_id.item_type` without `sudo()`. A custom field type restricted to a specific group is unreadable by users who only have template access via "Authorized Groups", so creating a SR through 'Sign Now' raised an AccessError despite full access to the template.

Fix:
Read the field type through `sudo()` in both methods, since checking its technical type/name is an internal check and shouldn't be gated by the field 'Used by' restriction, which only controls who can pick that field type while building templates.

Taskid-6574543

Problem:
The bookings calendar of an appointment type opens on the week of the most
distant booking instead of the next one, even when a booking exists later the
same day.

Cause:
`action_calendar_meetings` sets the landing date from `appointments[0].start`,
where `appointments` is `self.meeting_ids.filtered_domain(domain)`.
`calendar.event` is ordered on `start desc` and a one2many is read in the order
of its comodel, so the first record is the furthest booking rather than the
next one. The original `search([...], order='start')` was replaced by the
one2many in 14b5caccc325 (odoo/enterprise#23191).

Solution:
Sort the filtered bookings on `start` in `action_calendar_meetings`. That
method is the only place the initial date is built, and
`action_calendar_event_view_request` reuses it for the gantt start date, so
both entry points are covered. `calendar.event` keeps its `start desc` order,
which the booking list views rely on.

Steps to reproduce:
- Go to Appointments.
- Open the appointment type "Schedule a Demo" and click Appointments.
- Click New, set the date to later today, save and go back.
- Click New, set the date to one year from now, save and go back.
- Go back to Appointments, reopen "Schedule a Demo" and click Appointments.
- Switch to the calendar view.
- Observe that the calendar opens on the week of the booking one year from now.

Ticket [link](https://www.odoo.com/odoo/project.task/6480029)

opw-6480029

Forward-Port-Of: odoo/enterprise#130385
Forward-Port-Of: odoo/enterprise#129000

Before this commit, receiving a very long message in a channel scrolled at the bottom could move the message list to the end of that message instead of to its beginning. Every message received afterwards then kept the list at the end. The test "should scroll to bottom on receiving new message if the list is initially scrolled to bottom (asc order)" fails on runbot with:

    10. [toBeGreaterThan] expected value to be strictly greater
    > Minimum: 20762
    > Received: 5190.500

This happens because `applyScroll` also runs outside of a patch, on a resize of the message list or on a loaded image, i.e. while a received message is in the store and not rendered yet. Such a run finds no element for the message, scrolls to the bottom of the list, and records the message as the newest one the scroll was applied on. The patch that renders the message then finds no newer message, and keeps the list at the bottom.

This commit fixes the issue by keeping the newest message `applyScroll` recorded when the first newer message has no element yet, so that the patch that renders the message applies the scroll.

Note that the added test delays the registration of the message element, as a resize cannot be timed between the store update and the patch.

https://runbot.odoo.com/odoo/error/946929

Forward-Port-Of: odoo/odoo#287985
Forward-Port-Of: odoo/odoo#286759

Issue:
A customer who signs a quotation can delete the chatter entry containing the generated signed PDF. For quotations awaiting a wire transfer, this can remove the only retrievable snapshot of the signed quotation before the order is confirmed.

Steps to reproduce:
- Create a quotation requiring an online signature and payment.
- Sign it from the customer portal and select wire transfer.
- Delete the "Order signed by ..." entry from the portal communication history.

Cause:
The signing endpoint posts the generated PDF as a regular customer authored comment. Portal chatter allows customers to update their own comments, and deleting one clears its attachments, so the signed PDF is physically removed.

https://github.com/odoo/odoo/blob/e479111294b11058038defc31505cc81ac1f1821/addons/sale/controllers/portal.py#L348-L358

Solution:
Classify the signed document entry as an automated comment. This keeps it visible and attributed to the customer while ensuring that both the portal interface and backend message rules treat its content and attachment as immutable. Regular customer comments keep their existing behavior.

opw-6466029

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

Forward-Port-Of: odoo/odoo#287478
Forward-Port-Of: odoo/odoo#283595

**Steps to reproduce:**
- Install Website app
- Go to Settings
- Enable `Cookies Bar` and `Block tracking 3rd-party services`
- Try to install Forum app (`website_forum`)
- `RPC_ERROR: Odoo Server Error`

**Issue:**
During `_render_template`, `RuntimeError: request not bound` is raised due to `self.env['ir.http']._is_allowed_cookie('optional')` in `_should_remove_third_party_trackers` depending on `request`, which is not available (unbound `<LocalProxy>`).

This was introduced by [1] where the value is recomputed instead of relying on the context.

In previous versions, the flow was not triggered as `website_id` was not in the context of `_post_processing_att`,
but it was added by [2].

Before [2] `_prepare_frontend_environment` was being restricted to calls made with `request` set (in < 19.4
versions), but now the context is always set so it triggers `_should_remove_third_party_trackers` check.

Also post 19.4 we have [3] which now sets the editable variable to `true` when `translatable` is `True` and
`edit_translations` is not present in the context. This changes the branding mode from `inherit_branding_auto`
to `inherit_branding`, which short-circuits `_post_processing_att` and prevents the problematic behavior.

**Fix:**
Use the context `cookies_allowed` value that is computed in `website.py` by `_render_template`.

[1] https://github.com/odoo/odoo/commit/0c1799f81bc70a35c8dc429c7425d3c8109ea75a
[2] https://github.com/odoo/odoo/commit/b4d852a250801921ab899eff805ab078c98c374f
[3] https://github.com/odoo/odoo/commit/05c2fb1f364ca61adc65c2b87d020885f8184a9a

opw-6477558

Forward-Port-Of: odoo/odoo#283133

*: account, project, sale, sale_project

Fields stacked in a single cell with the <column> tag were never styled when required or invalid: o_required_modifier and o_invalid_cell were only computed for columns of type "field", so a required sub-field showed no underline and, left empty, stayed unhighlighted while still blocking the save. Mark the wrapper of the sub-field rather than the whole cell, as a column group cell may display several fields of which only one is required or invalid.

Readonly modifiers (o_readonly_modifier and text-muted) were not computed for the fields stacked in a single cell with the <column> tag, so a readonly sub-field was rendered as an editable one. Compute them on each sub-field
wrapper, as a column group cell may display several fields of which only one is readonly. The keyboard navigation looked for that class on the first child of the cell, which never matched a stacked cell. As a result, Tab could land on a readonly sub-field holding a tabable element, e.g. the link of a readonly many2one. Skip a stacked cell when all of its sub-fields are readonly, and otherwise ignore the readonly ones when picking the element to focus. For consistency sake, isCellReadonly is renamed into isFieldReadonly in consequence to these changes.

task-6564093

#### Issue:
Opening the MRP planning view could raise a traceback when a maintenance
request had a `schedule_end` but no `schedule_date`.

`TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'`

#### Steps to reproduce:
1. Install maintenance, mrp, and mrp_maintenance.
2. Create a work center.
3. Create a maintenance request linked to that work center.
4. set a `Scheduled end` and Leave `Scheduled Date` empty.
5. Go to MRP > Planning > Work Orders.

#### Cause:
`maintenance.request` stores `schedule_end` as a writable field, but no
constraint enforces that `schedule_date` and `schedule_end` must be set
together.

Later, `mrp_maintenance` in `_get_maintenances_intervals` fetches maintenance
intervals for the gantt view without filtering null bounds. If a request has
`(schedule_date, schedule_end)` = `(False, datetime)`, that interval is passed
to `Intervals(...)`, which crashes when comparing `None` with a `datetime`.

#### Fix:
Add a constraint on `maintenance.request` to require `schedule_date` and `schedule_end`
to either both be set or both be empty. Also filter out incomplete intervals in the MRP
maintenance gantt query in this enterprise PR: https://github.com/odoo/enterprise/pull/117710

opw-6225772

enterprise PR: https://github.com/odoo/enterprise/pull/117710

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

Forward-Port-Of: odoo/odoo#276633
Forward-Port-Of: odoo/odoo#265208

Steps to reproduce:
===================
1. Go to the payment providers and set "Pay on Site" to disabled.
2. Go to Apps, clear the filter, look up "website_sale_collect" and upgrade it. This also happens on its own, as upgrading any custom module that depends on it upgrades it too.
3. Go back to the payment providers.

=> "Pay on Site" is enabled again, and published as well from 19.0 on. Customers are offered it at checkout and place orders that are never paid, without the merchant ever enabling anything.

Root cause:
===========
`data/payment_provider_data.xml` is loaded in update mode because it carries no `noupdate`, and it hardcodes the state of the provider:

    <field name="state">enabled</field>

So every upgrade of the module writes that value back over whatever the merchant configured. Every other provider ships its data with `noupdate="1"` and leaves the state alone, this module is the exception.

The file has been loaded this way since the module was added:

- [1] created the module with an updatable provider record.

Fix:
====
Load the file with `noupdate="1"`. The record is still created, enabled, when the module is installed, it is simply not written again on later upgrades. The flag is read from the file rather than from the `ir.model.data` row, so databases where the provider already exists are covered on their next upgrade, no data migration needed.

[1]: 087c48c4ed2e
opw-6528110

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

Forward-Port-Of: odoo/odoo#286913

Go to Manufacturing > Planning > Workorders > Planning > list view. Sample data are displayed. Remove a filter such that real records match the domain. Tracebacks are displayed because we call `get_duration` on records that don't exist.

The `useRecordObserver` of MrpTimerField subscribes the callback to the `useSampleModel` flag and to the `record`. When the filter is removed, the model is reloaded and, atomically, both the flag and the root and updated on the model. As the flag is toggled, the callback is executed. However, the props of the MrpTimerField aren't updated yet, so the `record` used in the callback is still the old, sample, one.

One could argue that there's a design flaw in the model as at some point, a `record` could contain sample data while it's model states that we're not in sample mode (`record.model.useSampleModel` is false). That's true and that's something we'll change in the future, but in master.

We fix this issue with an easier patch, which consists in accessing the `useSampleModel` flag with `untrack`, i.e. to not subscribe to that flag's changes, as in that case, the component will be destroyed anyway.

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#288015

**Steps to reproduce:**

- Install PoS and Purchase
- Make 2 companies, A and B
- On product "Office Lamp" that is accessed by both companies, put Partner A in the vendor tab for company B
- Company A should have a Partner A and Partner B in this tab
- In the stock, set a replenishment for company A, with Partner A on Office Lamp
- Go to company B and open the PoS
- Try to buy Office Lamp while requesting an invoice
- An access error appears

**Why the fix:**

When requesting an invoice in the PoS, we try to create the stock picking. Doing so will trigger the replenishment rules linked to the product to be recomputed.

Those are executed when we **flush_all()**, processing Company A's replenishments as sudo(), meaning all of Company A's **seller_id** are fetched and cached. This means the product's **seller_ids** now contains Company A's **seller_id**, even though we are currently in Company B.

While trying to get the product's code, we iterate over **product.seller_ids**, but we do not have access to every record in that product.
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/product/models/product_product.py#L337-L343

As we don't have access to those, we get an access error when we stumble upon it.

To avoid those errors, we now filter the sellers to only have the ones compatible with our current Company in the given product we are currently buying.

Another solution would be to do **product.invalidate_recordset(['seller_ids'])** before looping over it, but feels more like a band-aid than the current fix IMO.

We could also write **self.lines.product_id.mapped('code')** in **_create_order_picking(self)** to have the solution be in PoS directly, but the error might arise from somewhere else at some point, and this just hides the issue by adding the code to the cache so that we don't have to fetch it again later.

opw-6308182

Forward-Port-Of: odoo/odoo#286656
Forward-Port-Of: odoo/odoo#275354

According to LSS Art. 36, minimum wage workers are exempt from IMSS deductions. Previously, the system evaluated the period's total gross wage instead of the daily wage, which caused incorrect withholdings when a minimum wage employee received extra pay (like commissions). We now evaluate the `l10n_mx_daily_salary` directly to protect minimum wage workers while ensuring correct deductions for higher earners with unpaid leaves.

Since calculations rely on `schedule_days` retrieved from the schedule table, users commonly adjust these values (e.g., from 15 to 15.2, or 30 to 30.4). To prevent discrepancies caused by this practice, we now round the `schedule_days`.

Finally, this commit fixes the employment subsidy eligibility threshold. Previously, the limit was incorrectly reduced by unpaid absences. This caused a double-counting effect (since absences already lower the actual gross wage) and wrongly disqualified employees. The subsidy limit is now based strictly on the full payroll schedule length, while the ISR minimum wage exemption correctly continues to consider actual worked days.

target: 19.0
task-6370959

Forward-Port-Of: odoo/enterprise#130706
Forward-Port-Of: odoo/enterprise#125061

Issue:
- The salary configurator displays two 'Gross' lines for Indian payroll structures.
- The generic salary resume uses the `wage` code, while the Indian payroll defines a structure-specific 'Gross' resume using the 'GROSS' payslip rule. Both resumes were included in the salary configurator, resulting in duplicate 'Gross' entries.
- The 'Monthly Equivalent' total shown in the configurator was also affected, as it included the generic 'wage' amount on top of the actual payslip values.

Cause:
- The generic 'wage' resume was still included for the Indian payroll structure alongside the India-specific 'GROSS' payslip resume.
- The generic 'wage' resume also counts towards the 'Monthly Equivalent' total shown in the configurator, so removing only the duplicate line left this total incorrect.

Fix:
- Exclude the generic 'wage' resume from the salary configurator results when the selected structure is the Indian employee payroll structure.
- This keeps the India-specific 'Gross' resume based on the 'GROSS' payslip rule while preventing the generic contract wage from being displayed as a duplicate.
- Subtract the removed 'wage' amount from the 'Monthly Equivalent' total so it stays correct after the duplicate line is removed.

task-6511413

Forward-Port-Of: odoo/enterprise#129518

Opening a product creation form from the purchase catalog raises a 
traceback.

### Steps to Reproduce
1. Go to **Purchase > Orders** (or Requests for Quotation).
2. Open any order with a **Vendor** selected.
3. Click **Catalog** on the order lines table.
4. Search for any non-existent product to trigger the empty state.
5. Click **Create a product** from the no content helper.

### Traceback
```pytb
Traceback (most recent call last):
  File "odoo/addons/web/models/models.py", line 2232, in onchange
    defaults = self.default_get(missing_names)
  File "odoo/orm/models.py", line 1401, in default_get
    defaults[fname] = field.convert_to_write(value, self)
  File "odoo/orm/fields_relational.py", line 759, in convert_to_write
    if record != origin:
  File "odoo/orm/models.py", line 6117, in __eq__
    return self._name == other._name and set(self._ids) == set(other._ids)
TypeError: cannot use 'dict' as a set element (unhashable type: 'dict')
```

### Issue
The purchase catalog action helper (PR odoo/odoo#164131) sets the 
current vendor as default on the new product using:
```python
context = {'default_seller_ids': [{'partner_id': vendor_id}]}
```

In commit 188c81575130 (PR odoo/odoo#272499), a check was added to 
`convert_to_cache()` to optimize lists of record ids (`[1, 2, 3]`):
```python
elif isinstance(value, list) and value and not isinstance(value[0], (tuple, list)):
```

The PR assumed all relational commands are tuples or lists 
(like `(0, 0, vals)` or `[0, 0, vals]`), and that anything else must 
be an id. However, x2many command values can also be 
dictionaries (`[{'partner_id': vendor_id}]`), which the method 
explicitly supports further down (`elif isinstance(command, dict):`).

Because a dictionary is neither a tuple nor a list, the check mistakenly
treated `{'partner_id': vendor_id}` as a record id and placed it inside
`record._ids`. When the ORM subsequently compares records
(`record != origin`), it attempts to create a `set()` of the ids and
crashes because dictionaries cannot be hashed.


### Fix
Exclude `dict` from the check:
```python
elif isinstance(value, list) and value and not isinstance(value[0], (tuple, list, dict)):
```
This ensures lists of dictionaries fall through to `elif isinstance(command, dict):`
and are properly instantiated as new in-memory records.



Related: odoo/odoo#272499  
Related: odoo/odoo#164131

\* = point_of_sale, purchase_requisition

**Steps to reproduce:**
1. Install purchase app
2. Create a product, and in the purchase tab set a vendor and specify
product name/code (e.g., "VENDOR-CODE")
3. Create a purchase order, select that product and vendor
4. The PO line shows: "VENDOR-CODE\n[Product Description]"
5. Edit the description in the line and print the invoice

**Issue:**
Two related issues with product name/description handling in invoice and purchase
order lines:
1. **Vendor Product Name Issue:** When a purchase line has a vendor product name/code,
editing the description causes the original internal product name to be prepended,
resulting in: `[Product Name]\n[Vendor Code]\n[Description]`
2. **Translation Issue:** When a customer has a different language, editing the product
description causes the original product name to be prepended to the invoice line:
`[Original Name]\n[Translated Name]\n[Translated Description] [1]

**Why this happens:**
The widget (`ProductLabelSectionAndNoteField`) was using the `productName` (untranslated/base
name) to detect what to strip from the label, but in the two scenarios this didn't match:
- **Vendor flow:** `productName` = "Product A" but the label contains vendor code "VENDOR-CODE"
- **Translation flow:** `productName` = "Product A" (English) but the label contains "Produit A"
(French)

When neither matched, the truncation logic wouldn't work, and `parseLabel()` would later
prepend the original product name blindly.

**Expected behaviour:**
- Original product name should not be prepended in both scenarios

**The fix:**
1. Added computed field to `pos.order.line` since it uses the same widget and needs to have the
field dependency [2]
2. Added computed field to `purchase.requisition.line` since it uses the same widget and needs
to have the field dependency
3. Modified `ProductLabelSectionAndNoteField.parseLabel()` to:
   - Only concatenate product name when `translatedProductName == productName`
   (indicating same language/no vendor override) since it would have been truncated by `get label()`
   - Otherwise, return the value as-is (no concatenation needed since `get label()` didn't truncate)

This handles the flows:
- **Vendor flow:** `translated_product_name` contains vendor name/code (≠ productName) → no
concatenation
- **Translation flow:** `translated_product_name` differs from `productName` → no concatenation
- **Same language/no vendor:** `translated_product_name` == `productName` → concatenates → maintains
existing behavior

**Related:**
- [1] - #248401
- [2] - #254158

opw-6391501

Currently, an error occurs when the user sets the partner's country to Saudi Arabia.

**Steps to Reproduce:**
 - Install the `l10n_sa` module with demo data.
 - Switch to `My Saudi Arabia Company`.
 - Create a `partner` and click the `+` icon next to the VAT Number.
 - Select `Company ID`, set any `value`.
 - Set the partner's country to `Saudi Arabia`.

`KeyError: 'OTHER'`

After the [recent commit], OTHER is removed from vals [1] when at least one other EN identifier, 
excluding OTHER, is available. If a user selects OTHER (Company ID) as an additional identifier 
and then changes the partner's country to Saudi Arabia, the available additional identifier 
metadata is recomputed. With the [second commit], it checks whether the stored additional 
identifier is applicable to Saudi Arabia by looking up its metadata [2].
However, since OTHER was removed from the available additional identifier metadata because 
another EN identifier is available, directly accessing the metadata for OTHER raises a KeyError.

This commit ensures that the additional identifier is safely accessed in the metadata.

[recent commit]: https://github.com/odoo/odoo/commit/9087c2ddc1de3e9ef9431188a9b6dddbd6b58552

[second commit]: https://github.com/odoo/odoo/commit/fddf7653ba898f5db9d97ae3cd9f885c6c5c658a

[1]- https://github.com/odoo/odoo/blob/1d50ff71a1edf2c4226cb2f68cf3bbe4e39485f6/odoo/addons/base/models/res_partner.py#L1423-L1425

[2]- https://github.com/odoo/odoo/blob/1d50ff71a1edf2c4226cb2f68cf3bbe4e39485f6/addons/l10n_sa/models/res_partner.py#L17-L18

sentry-7717445803

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

Forward-Port-Of: odoo/odoo#287384

In [this commit][1] some steps were added to resolve non-deterministic errors. Just before `...clickOnEditAndWaitEditModeInTranslatedPage(),` three steps were added that switch the language back to parseltongue. This is most likely since the function call implies we are on a translated page. The choice for this function was most likely due to a race condition. As the language was switched to English recently, the edit button might not have time to have switched.

To recreate the race condition, remove the step added in this commit but leave the rest of the changes. Run the tour and it will hang up on the first step of `...clickOnEditAndWaitEditMode()` because the Edit button is still in "translation" mode.

This commit removes the redundant language change and adds an extra step to check the Edit button is in the correct "mode" before continuing.

[1]: https://github.com/odoo/odoo/commit/7f7cc9617381b1a2f61af0875e7b60ab0b7ab3a0

task-5951393

Forward-Port-Of: odoo/odoo#288035
Forward-Port-Of: odoo/odoo#286764

Currently, an error occurs when applying the inventory date in the Stock reporting view.

Steps to Reproduce:
 - Install the `stock` module with demo data.
 - Go to `Settings` > `Languages`, add `Arabic`, and switch to it.
 - Go to `Inventory` > `Reporting` > `Stock`.
 - In the `left-side panel`, enter an `Inventory at Date` and click `Apply`.

`ValueError: time data '٢٠٢٦-٠٩-٠٩ ٠٥:١٨:٠٠' does not match format '%Y-%m-%d %H:%M:%S'`

After the [recent commit] that added a date picker to the Stock report search panel, when 
user enters a date using Arabic numerals, the text is displayed from right to left [1]. This date 
is then added to the context [2]. When computing the quantities, the date value from the 
context [3] is passed to it, where it is converted to a datetime [4]. However, the conversion 
expects the date to use Latin numerals. Since the date is in Arabic numerals, this raises 
the error.

This commit ensures that the date is serialized using serializeDateTime [5], which also uses 
the UTC timezone and the Latin numbering system (latn) as expected by the system.

[recent commit]: https://github.com/odoo/odoo/commit/52bfa5b9bebbcb4f8042daa183edc39865036605

[1]- https://github.com/odoo/odoo/blob/7ef98548726f36856d78c745679b14b0165803ba/addons/stock/static/src/views/search/stock_report_search_panel.js#L39-L40

[2]: https://github.com/odoo/odoo/blob/7ef98548726f36856d78c745679b14b0165803ba/addons/stock/static/src/views/search/stock_report_search_model.js#L52-L53

[3]: https://github.com/odoo/odoo/blob/7ef98548726f36856d78c745679b14b0165803ba/addons/stock/models/product.py#L146

[4]- https://github.com/odoo/odoo/blob/7ef98548726f36856d78c745679b14b0165803ba/addons/stock/models/product.py#L162

[5]: https://github.com/odoo/odoo/blob/7ef98548726f36856d78c745679b14b0165803ba/addons/web/static/src/core/l10n/dates.js#L552-L560

sentry-7629069474

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

Forward-Port-Of: odoo/odoo#287181

Steps to reproduce
---
1. Set the warehouse to deliver in 3 steps.
2. Create a delivery pick not tied to a procurement group (not from a sale order) with a consumable product, and validate it.
3. On the pack transfer, put the goods in a package and validate.
4. Duplicate the pick, validate it, put its goods in a second package on the pack transfer, and validate.
5. Open the final delivery: both lines sit in the same package instead of one line per package.

Issue
---
The two picks share no procurement group, so their delivery moves merge onto a single move keyed by partner. Validating the second pack tops up that already partially reserved move: for a consumable, `_action_assign` builds its lines from `_get_available_move_lines`, which reports the availability of every upstream package without discounting what the move already reserved.

https://github.com/odoo/odoo/blob/05af9e6877fd0f044bb46c983fe7300eb1db9307/addons/stock/models/stock_move.py#L1907-L1909

The package already reserved on the first line is therefore offered again and reused, collapsing both lines onto one package. The reserved-product branch below already subtracts the move's own reservation before allocating; doing the same here leaves each package on its own line.

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

Forward-Port-Of: odoo/odoo#287935
Forward-Port-Of: odoo/odoo#284956

**TL;DR**
- in certain cases, Session is not updated on order shared on trusted pos

Steps to reproduce:

- Install pos_restaurant with demo data.
- Have two configs: Cloth Shop and Furniture Shop.
- Ensure both configs have their own individual payment method (e.g., CASH).
- In Cloth Shop, add Furniture Shop as a trusted PoS.
- In Cloth Shop, enable "Log in with Employee".
- Open Cloth Shop and Furniture Shop in separate browsers (different users).
- Refresh Cloth Shop once.
- In Cloth Shop, create and save an order.
- In Furniture Shop, open that order and try to pay with "CASH".

Observation:
* A validation error is raised: "The payment method selected is not allowed in the config of the POS session."
<img width="320" height="201" alt="image" src="https://github.com/user-attachments/assets/8ca80575-76bf-4ecf-a739-08b03d543ed6" />

- although we can pay the order by a shared payment method

Cause:
- Refreshing Cloth Shop triggers `notify_synchronisation` due to `setCashierUpdateSession` , which pushes Cloth Shop's `pos.session` record into Furniture Shop's IndexedDB (because Cloth Shop trusts Furniture Shop).
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/pos_hr/static/src/app/services/pos_store.js#L61-L63
- When Cloth Shop saves an order, sync also pushes a copy of that order into Furniture Shop, and passed through `processDynamicRecords`
- `processDynamicRecords` ensures that the Record created is in sync with server data,  as  Furniture Shop now has a local record of session of Cloth Shop, the record keeps `session_id` pointing to Cloth Shop's session, else it would have been left `undefined`
- from the `res` we get, we set the session_id on `pos.order `
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/utils/devices_synchronisation.js#L127-L139
- However with  pos_restaurant installed we get its orveride which stores the result of super() and only returns result early when there are no` pos.order ` records in dynamicRecords. When pos.order records are present (our case), the method proceeds with its own logic but never returns result (or its own output) at the end 

https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/pos_restaurant/static/src/app/utils/devices_synchronisation.js#L5-L9

- so the corrected data from the super call is silently dropped.
- we do not get a change to update the session id

- The order keeps Cloth Shop's session ID
- Furniture Shop's payment validation checks the order against its session's allowed payment methods, but since the session is still Cloth Shop's, the check fails for methods not shared between Cloth Shop and Furniture Shop (e.g., CASH).

Why this is hidden in other cases: 

- without pos_restaurant, or if Furniture Shop had no prior knowledge of Cloth Shop's session (we made is possible by `Log in with Employee` feature, session_id would stay `undefined` and later get correctly set toFurniture Shop's session in PosOrder.setup().
https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/models/pos_order.js#L27-L30

or from here

https://github.com/odoo/odoo/blob/6a3655c8efd2de68754ace38bd1ab5eb6499faca/addons/point_of_sale/static/src/app/utils/devices_synchronisation.js#L127-L139

-  Both safety nets happen to be bypassed here.

Fix:
* Tighten the early return condition so that data is only discarded when the current configuration is not a restaurant configuration.
* Also, A trusted PoS configuration cannot be a restaurant, so not returning later makes sense.

opw-6465228


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

Forward-Port-Of: odoo/odoo#287574
Forward-Port-Of: odoo/odoo#282962

Currently, an error occurs when the Payroll Update Data schedule action is run.

**Steps to Reproduce:**
 - Install the `l10n_ae_hr_payroll` module without demo data.
 - Create a new company with the country set to `United Arab Emirates`.
 - Switch to that company.
 - Go to `Payroll` > `Configuration` > `salary` > `Structures`.
 - Delete all salary structures related to the `United Arab Emirates`.
 - Go to `Scheduled Actions` and run `Payroll: Update Data`.

`ValueError: External ID not found in the system: l10n_ae_hr_payroll.uae_employee_payroll_structure.`

After this [recent commit], hr_rule_parameter_data and hr_salary_rule_data were added to 
_get_data_files_to_update. If the user deletes the salary structure and then updates the 
data files [1], an error is raised because the structure is missing.

This commit ensures that the salary structure data is updated before updating the salary 
rule data. It also ensures that the salary structure type data is updated beforehand, as the 
structure depends on it and the user can delete the structure type data.

[recent commit]: https://github.com/odoo/enterprise/commit/f3316e056da817ca31fecdc04e0f8df000f0f038

[1]- https://github.com/odoo/enterprise/blob/0a0b3a50a81df062ddee5c310ce06aaa4533a8a8/l10n_ae_hr_payroll/models/hr_payslip.py#L98-L105

sentry-7496380516

Forward-Port-Of: odoo/enterprise#130654