If one of the Payroll Structure Types has the Scheduled Pay field unset,
opening the Payroll dashboard raises a traceback.

Steps to reproduce the error:
- Install ``hr_payroll`` module
- Go to Payroll > Configuration > Settings > Set Payroll Closing Date > Save
- Go to Payroll > Configuration > Structure Types > Create a new Structure Type > Unset Scheduled Pay
- Open Dashboard

Traceback:
```py
AttributeError: 'bool' object has no attribute 'title'
```

https://github.com/odoo/enterprise/blob/9a3ea83a432f42f62076a50fca6bc771a2de96bf/hr_payroll/models/hr_payroll_warning.py#L413-L419
The dashboard collects the scheduled pay values from all structure types and
later calls ``schedule.title()`` to build the labels. When a Structure Type has
no Scheduled Pay configured, so ``schedule`` becomes ``False``, leading to the traceback.

``_get_schedule_pay`` method can return False at [1],
So, It will generate the traceback from below line also. https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L401

Solution:
Added a fallback value when default scheduled pay is False.

[1]: https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L149-L154

sentry-7583037488

Forward-Port-Of: odoo/enterprise#125836
Forward-Port-Of: odoo/enterprise#122492

[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations
**Issue**
Adding a step in a manufacturing order with two operations that are too similar
could lead to a traceback when proposing an improvement from the Shop Floor.

**Steps to reproduce**
- Install the Product Lifecycle Management app.
- Create a BOM for any product with two operations that:
	- Have the same name and work center
	- Have no variant
- Create and confirm a Manufacturing Order for that product.
- Open the Shop Floor view.
- Click the gear icon -> Update Instructions -> Improvement Suggestion -> Add a Step -> Propose a Change.
-> A traceback occurs

**Cause**
When adding a step:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L10
It tries to find the corresponding operation in the ECO's new BoM.
This relies on `_get_sync_values()`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_plm/models/mrp_routing.py#L9-L13
Because two operations share the same name, work center, and no variant, both match the filter:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L39
This results in a singleton error when accessing `operation.id`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L42

opw-6241880

Forward-Port-Of: odoo/enterprise#123673
Forward-Port-Of: odoo/enterprise#119404

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

Currently, an error occurs when a user creates a Google Reserve Merchant record.

**Steps to Reproduce:**
 - Install the `appointment_google_reserve` module.
 - Go to `Appointments` > `Configuration` > `Google Booking`.
 - Click `New` to create a record.

`AttributeError: 'website' object has no attribute 'homepage_url'`

After this [recent commit], as part of the context-based website resolution refactoring, the 
`default_website` record is now available even without the `website` module because it is 
created in `base` [1]. When a user creates a Google Reserve Merchant record, it attempts 
to set the default URL using the default website from `base`. However, it then tries to access 
the `homepage_url` field, which is defined in the `website` module [2]. Since the `website` 
module is not installed, this raises the error [3].

This commit ensures that before accessing `homepage_url`, it first checks whether the 
`homepage_url` field exists when creating the merchant record, since this field depends 
on the `website` module.

[recent commit]: https://github.com/odoo/odoo/commit/ae81b6f6074632d1a609387e53f97a61ee6c95f4

[1]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/odoo/addons/base/data/website.xml#L5-L9

[2]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/addons/website/models/website.py#L168

[3]- https://github.com/odoo/enterprise/blob/01b0cf4e2f2e2c63c02c3429d029c90639de1322/appointment_google_reserve/models/google_reserve_merchant.py#L21-L22

Task-6395376
sentry-7630852653

Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: not enough values to unpack (expected 1, got 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
    response = serve_db(request)
               ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
    registry = Registry(request.db)
               ^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
    return cls.new(db_name)
           ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
    cr.rollback()
  File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
    with rollbacking:
  File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
    self.restore_state()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
    self.reset()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
    self._reset_registry_change()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
    registry._setup_models__(cr)
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
    env.invalidate_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
    self.flush_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
    self._recompute_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
    field.recompute(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
    func(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
    seller_buyer_details = ewaybill._get_seller_buyer_details()
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
    return move._get_l10n_in_seller_buyer_party()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
    self.ensure_one()
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback

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

Forward-Port-Of: odoo/odoo#276216

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/odoo#277440

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

The bugfix introduced in https://github.com/odoo/odoo/commit/01d11a770f89c391f7c6a2c46a3d770d10afb428 made it so that "personal" outgoing mail servers are blocked/ignored from being used in email marketing as dedicated servers.

In doing so, it missed the fact that while in *Email Marketing > Settings*, the "Dedicated Server" picker now correctly ignores personal OMS entries, the selection widget for `mail_server_id` in `view_mail_mass_mailing_form` still let's you manually select a OMS with an owner set. As there is not warning or an explicit error, this can lead to accidental miss configurations on an email marketing campaign, where the selected OMS will be actually ignored by the backend.

To align the changes introduced by the bugfix, we add a search domain to the selection field, so that only OMS with `('owner_user_id', '=', False)` will be presented as a choice.

OPW-6388562

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

Forward-Port-Of: odoo/odoo#278918
Forward-Port-Of: odoo/odoo#278595

Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: not enough values to unpack (expected 1, got 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
    response = serve_db(request)
               ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
    registry = Registry(request.db)
               ^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
    return cls.new(db_name)
           ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
    cr.rollback()
  File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
    with rollbacking:
  File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
    self.restore_state()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
    self.reset()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
    self._reset_registry_change()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
    registry._setup_models__(cr)
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
    env.invalidate_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
    self.flush_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
    self._recompute_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
    field.recompute(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
    func(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
    seller_buyer_details = ewaybill._get_seller_buyer_details()
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
    return move._get_l10n_in_seller_buyer_party()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
    self.ensure_one()
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback

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

Forward-Port-Of: odoo/odoo#276216

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/odoo#277440

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

Forward-Port-Of: odoo/odoo#279033
Forward-Port-Of: odoo/odoo#270008

Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: not enough values to unpack (expected 1, got 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
    response = serve_db(request)
               ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
    registry = Registry(request.db)
               ^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
    return cls.new(db_name)
           ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
    cr.rollback()
  File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
    with rollbacking:
  File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
    self.restore_state()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
    self.reset()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
    self._reset_registry_change()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
    registry._setup_models__(cr)
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
    env.invalidate_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
    self.flush_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
    self._recompute_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
    field.recompute(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
    func(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
    seller_buyer_details = ewaybill._get_seller_buyer_details()
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
    return move._get_l10n_in_seller_buyer_party()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
    self.ensure_one()
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback

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

Forward-Port-Of: odoo/odoo#276216

Currently, an error occurs when installing the hr_holidays_attendance module.

**Steps to Reproduce:**
 - Install the `hr_attendance` module without demo data.
 - Go to `Attendance` > `Configuration` > `Overtime Rulesets` and open the `Default Ruleset` record.
 - Delete its `linked overtime rules`.
 - Install the `hr_holidays_attendance` module.
 
 **Error:**
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo18/community/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml:7, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
            <field name="compensable_as_leave" eval="True"/>
        </record>
```
This error occurs when the user deletes all overtime rules and then installs the hr_holidays_attendance 
module. During installation, the module attempts to update the deleted overtime rule records, 
which raises an error [1].

This commit uses forcecreate="0" to skip updating records if the corresponding overtime 
rules do not exist.

[1]- https://github.com/odoo/odoo/blob/da0a83761f38ee4a2940015b6c8f7190c310a4a0/addons/hr_holidays_attendance/data/hr_holidays_attendance_data.xml#L7-L12

sentry-7372074675

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

Forward-Port-Of: odoo/odoo#277656

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `mrp` module
- Go to the setting enable `Lots & Serial Numbers` and `Storage Locations`
- Create a storable product tracked by Lots
- Configure a Putaway Rule for the product so it is stored in a
  sub-location
- Create a Bill of Materials for the product with at least one
  component
- Create and confirm a Manufacturing Order
- Increase the production quantity (e.g. using the "Change Production
  Quantity" wizard)
- Click **Generate Lot/Serial Number**
- Click **Produce All**

Issue:
------
Completing the Manufacturing Order raises:

    Invalid Operation
    You need to supply a Lot/Serial Number for product:
    - Product

even though a single lot should be sufficient for a lot-tracked
product.

Cause:
------
When the production quantity is increased, `change_prod_qty()` updates
the finished move's demanded quantity and re-reserves it through
`_update_finished_moves()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L77

which calls `_action_assign()` on the finished move:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/wizard/change_production_qty.py#L49

Since finished moves originate from the production location, they
bypass the normal reservation flow:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2070

`_action_assign()` then tries to reuse the move's existing move line,
but the lookup requires `location_dest_id` to still match the move's
generic destination:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2092-L2106

That existing line's `location_dest_id` was already redirected to the
putaway sub-location by the previous `_apply_putaway_strategy()` call
(at MO confirmation), so the lookup no longer matches and a second,
distinct move line is created and appended instead of the first one
being reused:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L2170

Later, clicking **Generate Lot/Serial Number** creates a single lot and
stores it on the production order's `lot_producing_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1602

When **Produce All** is clicked, which trigger `button_mark_done()`  it calls
`_post_inventory()`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L2227

which assigns that lot to the finished move through `move.lot_ids`:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/mrp/models/mrp_production.py#L1925

Since `lot_ids` is declared with `inverse='_set_lot_ids'`, this write
triggers that inverse method:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L192

The current implementation of `_set_lot_ids()` only assigns the lot to
a single available move line, regardless of tracking type:

https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/stock_move.py#L656-L668

Since only one lot is ever generated for a lot-tracked product, only
the first finished move line receives a `lot_id`. The second move line
created after increasing the production quantity is left without one.

When `button_mark_done()` validates the finished move lines, it
detects that one of them still has no lot assigned and raises the
"Invalid Operation" error, even though a single lot is valid for the
entire production of a lot-tracked product.

Fix:
----
`action_generate_serial` produces a single lot for the whole production.
In `_post_inventory()`, right after the generated lot is set on
the finished move, propagate it to any remaining lot-less move lines
of a **lot**-tracked finished move.

---

opw-6366060

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

Forward-Port-Of: odoo/odoo#275000

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

Issue:
In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date)

Steps to reproduce:
1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered)
2) Pick any "As of" date
3) Open any row
4) Click breadcrumb to return to the accrual list
5) Observe the "As of" date has been reset to today's date
To generate some data you could:
create a PO, then upload the bill, validate the receipt, then you'll find it in bills received

Cause:
`AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16

Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65

Solution:
- Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation.
- Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path.
- In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore.

opw-6232263


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

Forward-Port-Of: odoo/enterprise#118669

With pos_hr enabled, the cash in/out popup uses the cashier's `work_contact_id` as partner for the `account.bank.statement.line`. When that partner is archived or not part of the limited partner loading, the relation cannot be resolved in the frontend and the statement line is created with `partner_id = False`.

Deleting such a cash move then crashes in `delete_cash_in_out`:

    File ".../point_of_sale/models/pos_session.py", line 1877, in delete_cash_in_out
        action = cashier_name + ': ' + str(amount)
    TypeError: unsupported operand type(s) for +: 'bool' and 'str'

Steps to reproduce:
- Enable "Multi Employees per Session" (pos_hr) on a PoS config
- Archive the work contact of an employee, or make sure it is not included in the limited partner loading
- Open a session, log in as that employee and register a cash in/out
- As a manager, delete the cash move from the cash move list => Traceback, the cash move cannot be deleted

opw-6389830

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

Forward-Port-Of: odoo/odoo#276598

The `bus_monitoring_service` test "connection considered as lost after failed reconnect attempt" fails about half of the time.

Since [1], the reconnect delay in tests is much smaller. The retry therefore fires while the mock socket is still in the closing state.

`_start` detects that socket and triggers the close event manually to keep the lifecycle consistent. In other cases, the error event will schedule a reconnect but in this case it will never arrive.

The worker is then left with no socket, no listeners and no pending timeout: it never reconnects.

Schedule the reconnection when handling a manually triggered close, since no error event will follow to do it.

[1]: https://github.com/odoo/odoo/pull/278075

runbot-944578

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#278892
Forward-Port-Of: odoo/odoo#278779

When generating the Sales Report or Session Report with a large number of orders (1000+), the report computation could take several minutes or fail entirely with cursor closed errors. This was mainly caused by multiple inefficient ORM patterns, such as repeated searches inside nested loops and unnecessary recordset instantiations.

This commit optimizes the report generation logic by:
- Avoiding repeated searches inside loops (e.g. account payments per session)
- Using `_search` instead of `search` where only record ids are required
- Grouping and caching session-related records (payments, moves, cash moves)
- Reducing redundant ORM calls and Python-level iterations
- Preserving the exact report output structure and values

The returned data remains unchanged; only record ordering may differ due to optimized iteration and grouping.

As a result, report generation time is significantly reduced and the report can be generated reliably even with very large order counts.

task-5452734

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

Forward-Port-Of: odoo/odoo#241828

**Steps to reproduce:**
- Install the `l10n_pl_reports` module and switch to a `PL Company`.
- Create and confirm a vendor bill with a `Bill Reference` and `Taxes`.
- Navigate to Accounting > Reporting > Tax Report and select `This Month`.
- From the dropdown, click `JPK` > `Export XML`.
- Open the generated XML file and observe the `DowodZakupu` field.

**Observation:**
`DowodZakupu` contains the vendor `Bill Number` even 
when a `Bill Reference` is set.

**Root Cause:**
At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) 
instead of using the `Bill reference`(`ref`) when available.

**Fix:**
This commit ensures `DowodZakupu` contains the `Bill Reference`
when it is available in JPK exports.

**Reference:**
https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41)

[1]:
https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208

opw-6299827

Forward-Port-Of: odoo/enterprise#126113
Forward-Port-Of: odoo/enterprise#121117

**Steps to reproduce:**
- Install the `l10n_pl_reports` module and switch to a `PL Company`.
- Create and confirm a vendor bill with a `Bill Reference` and `Taxes`.
- Navigate to Accounting > Reporting > Tax Report and select `This Month`.
- From the dropdown, click `JPK` > `Export XML`.
- Open the generated XML file and observe the `DowodZakupu` field.

**Observation:**
`DowodZakupu` contains the vendor `Bill Number` even 
when a `Bill Reference` is set.

**Root Cause:**
At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) 
instead of using the `Bill reference`(`ref`) when available.

**Fix:**
This commit ensures `DowodZakupu` contains the `Bill Reference`
when it is available in JPK exports.

**Reference:**
https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41)

[1]:
https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208

opw-6299827

Forward-Port-Of: odoo/enterprise#126113
Forward-Port-Of: odoo/enterprise#121117

Steps to reproduce:
- Configure a preparation display on a POS config with a product category
- Place an order and leave it in a non-final stage
- Keep the session open past midnight

Issue:
The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen.

_compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted.

opw-6414302

Forward-Port-Of: odoo/enterprise#125984

Steps to reproduce the bug:
- Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery' in that case)
- Run TestSaleMRPAngloSaxonValuation.test_sale_mrp_kit_bom_cogs (sale_mrp) or TestAngloSaxonValuation.test_anglo_saxon_cogs_partial_down_payment_credit_note (sale_stock)

Problem:
These tests create their products without setting invoice_policy explicitly, relying on the field's implicit default. l10n_ke_edi_oscu_stock's _compute_invoice_policy (https://github.com/odoo/enterprise/blob/4e459417dac809caafea34aa2e487fc3c1f0ce1a/l10n_ke_edi_oscu_stock/models/product.py#L16-L21) forces invoice_policy to 'delivery' for any storable product whose company_id is not set, which is the case for products created in these test fixtures.

Once invoice_policy becomes 'delivery', invoiced quantities are driven by qty_delivered instead of the ordered quantity, which the affected tests never account for (some deliver an arbitrary quantity instead of the exact BoM demand, others never validate a delivery at all), causing wrong COGS amounts or wrongly invoiced quantities as soon as such a localization is installed alongside these modules.

Solution:
Pin invoice_policy to 'order' explicitly wherever these test fixtures create their products, so the test outcome no longer depends on which other modules happen to be installed.

runbot-243633

Forward-Port-Of: odoo/odoo#278346

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

Steps to reproduce:
-------------------
1. Install Timesheets.
2. Create a new employee with a fully fixed working schedule (40h/week).
3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours).
4. Observe the overtime indicator for the employee (it shows 32 hrs)
   (Click the left arrow to display it).
5. Change the timesheet encoding unit to "Days / Half-Days".
6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days).
7. Install a language other than English (e.g. French).
8. Return to Timesheets and observe the overtime indicator again.

Issue:
--------
The remaining time value changes unexpectedly and displays 32 hours instead of 4 days.

Cause:
---------
In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`.

Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead.
https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169

Solution:
-----------
Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values.


see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82

opw-6279133

Forward-Port-Of: odoo/enterprise#125909
Forward-Port-Of: odoo/enterprise#120595

Step to reproduce:
- install pos_restaurant with demo
- start a restaurant pos, in a other tab, open the kitchen display app
- notice the `in progress` count to be X in kanban view
- from pos, send a order to kitchen 
- in other tab, notice the `in progress` count of to be X+1
- close the pos, when asked, cancel the order

Observation:
- notice, in preparation display, `in progress` stays same, but as we cancelled 
the order, `in progress` should be updated from X+1 to X

Cause:
- the count comes from computed field, `order_count` which considers
`orderline.product_quantity > 0` for counting it as `in progress`
https://github.com/odoo/enterprise/blob/2027db92c8b2b2c90983fc663b2e4c5c4ca1e83f/pos_preparation_display/models/preparation_display.py#L184-L187
- `orderline.product_quantity` is unaffected by cancelling the order

Fix:
- after a order is cancelled the linked orderline's `product_cancelled` is 
updated, so a difference of `product_quantity` and `product_cancelled` tell us 
whether a order is in `in progress` or not

opw-6414253

Step To Reproduce:

* Install the French Localization and Accounting modules.
* Create and confirm two vendor bills with 20% tax, one dated in the previous month and one in the current month.
* Switch the database language to French (Français).
* Confirm the previous month's tax return closing entry.
* Confirm the current month's tax return closing entry, enter a refund request, and submit it.
* Notice that the generated refund request journal entry contains incorrect debit/credit lines.

Reason:
The refund request journal entry is generated incorrectly when the database language is set to French because the implementation expects the account labels in French. As a result, the label comparison fails, causing incorrect journal entry lines to be generated. The issue does not occur when the database language is set to English.

Solution:
Apply the required translation fix in the French  file so that the expected account labels are correctly resolved during tax return submission. This is a temporary workaround until the underlying issue is addressed.

Note:
The current implementation relies on matching translated account labels((https://github.com/odoo/enterprise/blob/18.0/l10n_fr_reports/wizard/l10n_fr_send_vat_report.py#L438)), which is not an ideal approach. I discussed this with the R&D team, and they confirmed that implementing a proper fix requires a deeper understanding of the complete flow and will take more time. Therefore, this PR provides a temporary translation-based workaround to resolve the customer's issue.

opw-6402308

Currently, when a quotation is created from a repair order generated from a helpdesk ticket, 
the salesperson is not set on the quotation even if the customer has a salesperson assigned.

**Steps to Reproduce:**

 - Install `helpdesk_repair`.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams`.
 - Open a team recod and enable `Repairs`.
 - Create a `contact/customer` with a `salesperson` assigned.
 - Go to `Helpdesk`, create a ticket for that `customer`, and select the `helpdesk team` 
   configured above.
 - Click `Repair`, then click `Create Quotation`.
 - Open the quotation and check the `Salesperson` field in the `Other Info` tab.

**Current behavior:**
The Salesperson field on the quotation remains empty.

**Expected behavior:**
The Salesperson field on the quotation should inherit the salesperson assigned to the 
selected customer/contact.

**Cause of the issue:**
When a repair order is created from a helpdesk ticket, default_user_id [1] is passed in the context . 
This value is propagated when creating the repair order [2] . Later, when creating the quotation from 
the repair order [3], the same context is reused.
Because default_user_id is already present in the context, it overrides the precomputation of user_id 
from the customer. As a result, user_id is initialized with an empty value and remains unset.

**Fix:**
This commit ensures that default_user_id is removed from the context before creating the 
sale order. Without a default value for user_id, the field is correctly precomputed from the 
selected customer, and the salesperson is properly assigned.
[1]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L52

[2]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L36-L40

[3]: https://github.com/odoo/odoo/blob/29328b8fccff833c14de317b51f3b4e5a8c40f75/addons/repair/models/repair.py#L357

opw-6344939

The JsonFormatter has two bugs

- the ignore list is not working as expected
- in 18.0-18.4 the 'test' key is broken

This commit add tests to ensure those behavior works as expected

While on it, also adds a `additional_record_keys` parameter to allow to specifically add keys to the default list, without having to override the whole list, and add additional default keys (exc_info and test)

The previous `ignored_record_keys` default value was possible to remove by calling `JSONFormatter(ignore_record_keys=[])`

The purpose was to be able to easily include all keys and ignore the default ingnore list, but this makes the additional blacklisting of a few keys more tedious, and the general usage and implementation more complex

`JSONFormatter(ignore_record_keys=[*JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS, 'other key'])`

To simplify the logic, **this is not the case anymore**, so to include all keys something like this would be needed

`JSONFormatter(additional_record_keys=JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS)`

Or an hardcoded list.