### Current behavior:
When a Studio custom One2many field has an invalid relation field (inverse) name, accessing `registry.field_inverses` raises KeyError. On 19.0 this also crashes error-page rendering, leaving the server unusable after closing Studio. On 18.0, it doesn't crash the server.

### Expected behavior:
An invalid inverse name must not crash the registry or error handler; the server should stay responsive so the user can fix the field.

### Steps to reproduce:
1. Install sales, project with demo data
2. Create a sale order, use Studio to add a new "Lines" field (e.g. test line)
3. In the sale order, add a product that has Create on Order field (e.g. plumbing services from the demo data) > Confirm
4. Click on the smart button to go to project/task
5. Switch to Studio again, add a related field in the task, point that to Sales Order > test line
6. Activate debug mode, click on More for test line (task)
7. In properties, turn off Read only. Important here: add an invalid key for Relation Field (e.g. 'hehe')
8. Error popup shows key error. Try to close and exit out of Studio mode > Server crashes with 500 Internal Server Error

### Cause of the issue:
- When a custom One2many field has an invalid `inverse_name` (set via Studio developer mode), `One2many.setup_inverses` accessed `registry[comodel]._fields[inverse_name]` without checking existence
- Building the cached `registry.field_inverses` property then raises an uncaught KeyError and bricks the server with 500 Internal Server Error

### Fix:
- When a custom One2many field has an invalid inverse_name (set via Studio developer mode One2many.setup_inverses accessed registry[comodel]._fields[inverse_name] without checking existence
- Building the cached registry.field_inverse property then raises an uncaught KeyError and bricks the server with 500 Internal Server Error

opw-6479178

Forward-Port-Of: odoo/odoo#287589

Currently, the `_track_prepare` function doesn't add a fallback lang context, however the `_track_finalize` function does. This was in the refactor to saas-19.3 / mail mixin. When writing to a tracked translatable field, this can result in a tracking message being added to the chatter when the active user is Odoobot, e.g. running a **scheduled action**.

If Odoobot's language is non-english, then the fallback language of `_track_finalize` will be different than the no-context language of `_track_prepare` (which defaults to english), and in the chatter we see messages created repeatedly like:

english translation -> odoo bot language translation.

This fix makes the `_track_prepare` method also use the same fallback language as the `_track_finalize` method, so that the values are compared correctly in the same language and no accidental chatter records are made.

```
Steps to Reproduce on Newdb:
1. Make sure 'Automation Rules: check and execute' scheduled action is active.
2. Install l10n_fr, contacts.
3. Set the language on the res.partner record for Odoobot to French.
4. Create a new Automation Rule on Contact, Based on date field 'Created On', with 0 Hours delay. Give its name a French translation different from its English translation.
5. Make a new contact.
6. Run the scheduled action 'Automation Rules: check and execute'.
7. Observe in the Automation Rule in the chatter:

English translation → French Translation (Nom de la règle d'automatisation)
```

opw-6563805, opw-6567533

<img width="1964" height="1290" alt="2026-09-23_13-33" src="https://github.com/user-attachments/assets/8f9e3af0-2f99-4ccd-aa1a-0d586636cff7" />
<img width="1105" height="669" alt="2026-09-23_13-33_1" src="https://github.com/user-attachments/assets/e4b24de5-0147-4842-953f-d687d3178943" />

Steps to reproduce
1. In Inventory Settings, enable Lots & Serial Numbers and Expiration Dates.
2. Create a storable product tracked by lot with Expiration Date enabled.
3. Create and confirm a dropship of it, then open the move's Detailed Operations.
4. The pre-filled line works: typing a batch and an expiration date creates exactly that lot at validation.
5. To split the quantity, click "Add a line": it opens the "Pick From" popup, and choosing "Create" there creates the lot and attaches it to the line.
6. On that line, edit "Lot/Serial Number" and "Expiration Date", then Validate.

-> Expected: the values entered on the line are used.
-> Actual: they are ignored; the lot created through "Pick From" is delivered with its own expiration date, the name and date typed on the line have no effect.

Issue
---
On a create-lots-only non-incoming operation like `Dropship`, `show_quant` is derived from `picking_code` alone, so the "Pick From" quant picker is shown even though the operation only
creates lots. Adding a line goes through "Pick From", which creates the lot and attaches its `lot_id` to the move line; from then on the line's `lot_name` and `expiration_date` stay
editable but do nothing, since a set `lot_id` is used as-is at validation and the `expiration_date` is recomputed from the lot, so anything typed there is silently dropped. Such an
operation has no existing stock to pick from, so `show_quant` is now gated on the lot settings too: "Pick From" is hidden and the line's `lot_name` and `expiration_date` become the only
inputs, created into the lot at validation like receipts already do.
https://github.com/odoo/odoo/blob/68dcb950df83d70ff2aea0e05c96cc9b57c1a8a9/addons/stock/models/stock_move.py#L646-L647

opw-6530563

Forward-Port-Of: odoo/odoo#290402
Forward-Port-Of: odoo/odoo#287474

Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department.

### **Steps to reproduce**
1) Install helpdesk_timesheet with demo data
2) Go to Timesheet > Reporting > Ticket Analysis
3) Set group by to Employee
4) Click on any graph bar or pivot cell

### **Error:**
`ValueError: Invalid field helpdesk.ticket.employee_id in condition ('employee_id', '=', 1)`

Root Cause:
The `helpdesk.ticket.report.analysis` model includes specific fields such as `employee_id`, `department_id`, and `employee_parent_id` (see [1]) that are defined for reporting purposes but do not exist on the `helpdesk.ticket` model. When a user clicks a data point to view related tickets, the reporting view passes the current domain directly to the ticket list view. Because `helpdesk.ticket` lacks these fields, the ORM fails to validate the domain, resulting in a server error.

[1]- https://github.com/odoo/enterprise/blob/8d16b647431985dd7c216ae39eea6ca050e04b46/helpdesk_timesheet/report/helpdesk_ticket_report_analysis.py#L15-L17

### **Fix:**
This commit introduces a mixin to intercept the openView call. The mixin maps reporting-specific fields to valid relational paths on the ticket model `(for example, employee_id is transformed into user_id.employee_id)`. This ensures that the domain generated from the report model is compatible with the target ticket model.

**opw-5931273**

Forward-Port-Of: odoo/enterprise#113088
Forward-Port-Of: odoo/enterprise#108503

Issue:
Currency rate for payment is recomputed up to 6 digit. However, it may differ from the official one stored in db up to 4 digits. Which creates differencies between invoice and payment rate made at the same date.

Steps to reproduce:
- In MX company,
- Enable USD,
- Set currency rate for today to 1 USD = 17.4455 MXN
- Create a PPD invoice (due date > 40 days) in USD
- Add a line with
	- qty: 1,
	- unit_price: 3.488
	- tax: 16% (default tax)
- Send it to CFDI
- Create payment
- On the invoice Form click on "Update Payment"

Current behavior:
- In the CFDI sheet, Payment and Invoice XML files will have different currency rates

Expected behavior:
- In the CFDI sheet, Payment and Invoice XML files will have the same currency rate

Cause:
PACs require having the payment `amount` to be equal to `currency_amount * currency_rate`. For huge amout it may happen that using the 6 digits rounding of currency rate to compute the amount won't fall exactly on the two digit precision for the amount and payment would be refused. Therefore, for all payment, we recompute a 6 digits precision `currency_rate` from `amount` and `currency_amount` then using it to compute the final amount. However, Banxico (Mexican central Bank) publish rates with a 4 digit precision. Recomputing the currency rate up to 6 digits may slightly change it from the 4 digit precision official currency rate.

opw-6411530

Forward-Port-Of: odoo/enterprise#132659
Forward-Port-Of: odoo/enterprise#129700

When having a Kiosk config with a preparation printer and kiosk have multiple language we have the following issue:

- Change language (use a different than default Kiosk lang)
- Create order, add lines
- Pay the order
- Confirmation page → Print preparation ticket in customer language
- Click close → Trigger a page reload (reset to Kiosk default lang) and   print a second preparation ticket in default Kiosk lang
- Then we have to click again "Close" on the confirmation page a second time

→ Two preparation tickets printed & we have to close the confirmation page 2 times

After the fix:
A ticket is rendered in the language loaded with the page, so the confirmation page only prints it when the kiosk is already in its own language Otherwise it stores the order access token, restores the language and loads the default root: the next page prints the ticket, once, in the kiosk language

task-id: https://www.odoo.com/odoo/project/1737/tasks/6559206



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

Issue:
----------------------------------------
The domain of the field `hr_responsible_id` isn't computed. Also it should contain `hr_holidays.group_hr_holidays_user`.

Cause:
----------------------------------------
The domain of the field is returned by `_get_hr_responsible_domain()` as a string which is not supported.

https://github.com/odoo/odoo/blob/2ea452d03aa0cbfe360c539fb3b29a7b89aa7297/odoo/orm/fields_relational.py#L112-L123

`validated()` returns `None` so the domain is left empty.

Solution:
----------------------------------------
Return a list instead of a string.

Also, override the field in `hr_holidays` and and the condition on `hr_holidays.group_hr_holidays_user`.

Note:
----------------------------------------
This [commit](https://github.com/odoo/odoo/commit/ff50687bad2939db882e75ae20f28e6155fa2191) did the same thing in saas-19.4 but added a useless field in `hr.employee` because it did not catch the error of the string being wrong.

opw-6545508

Forward-Port-Of: odoo/odoo#289243