This fixes unstable automated tests in the messaging area by making test checks wait for expected actions instead of relying on timing shortcuts. The change helps reduce false test failures and improves confidence in release validation without changing business functionality.

Several tests are non deterministic because they are using
`assert.verifySteps` at the wrong moment. Helpers such as
`afterNextRender`, `nextTick`, `Deferred` are used but those are
either not reliable or cumbersome to setup.

This PR introduces an asynchronous API on top of
`assert.step`/`assert.verifyStep`. This will wait until steps are
executed or until the timeout is reached.

fixes runbot-52660,54471,52794

This fix prevents an occasional error when retrieving product records through XML-RPC by safely handling missing field definition information. It helps integrations and automated processes that read product data continue running instead of failing unexpectedly.

Sometimes definition_record can be None.
This checks that definition_record is not None before calling it on record

Description of the issue/feature this PR addresses:
#146835
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

From the first of January, Ticketbai becomes required in the region of Batuz (Bizkaia). And we were missing a piece where also the vendor bills need to be sent, similar to SII (but different) For that, they use an LROE structure, which we also used for sending customer invoices, but with the regular Ticketbai XML in there (encoded in base64). For vendor bills, it is however not the regular Ticketbai XML and the chaining and signature are also not needed, but the enveloping structure is

From the first of January, Ticketbai becomes required in the region of Batuz (Bizkaia).

And we were missing a piece where also the vendor bills need to be sent, similar to SII (but different)

For that, they use an LROE structure, which we also used for sending customer invoices, but with the regular Ticketbai XML in there (encoded in base64).

For vendor bills, it is however not the regular Ticketbai XML and the chaining and signature are also not needed, but the enveloping structure is built in the same way.

So, we activate Ticketbai by default on vendor bill journals, but it will only be sending when the agency is Batuz.

Thanks to Moduon and Landoo for the extra push.

opw-3628750

closes odoo/odoo#146625

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

In website_sale, there is a setting to prevent the sale of zero priced products. It works fine but triggers also on order of free events, free event booths and free courses. This is unwanted behavior and a check has been added to still allow those three product types to be sold for 0. Task-3388254 Forward-Port-Of: odoo/odoo#126824

In website_sale, there is a setting to prevent the sale of zero priced products. It works fine but triggers also on order of free events, free event booths and free courses.

This is unwanted behavior and a check has been added to still allow those three product types to be sold for 0.

Task-3388254

Forward-Port-Of: odoo/odoo#126824

**Steps to reproduce the bug:** - Create a storable product “P1”: - Tracked by: SN - BoM: - product qty: 1 - Component: consumable product qty:1 - Create a MO to produce 12 unit of P1 - Update the qty of the consumable product to 31 - Confirm the MO - Click on “Mass produce” **Problem:** An user error is triggered: “It is not possible to unreserve more products of Consu than you have in stock” The product is a consumable, we should not update its reser

**Steps to reproduce the bug:**
- Create a storable product “P1”:
    - Tracked by: SN
    - BoM:
        - product qty: 1
        - Component: consumable product qty:1

- Create a MO to produce 12 unit of P1
- Update the qty of the consumable product to 31 
- Confirm the MO
- Click on “Mass produce”

**Problem:**
An user error is triggered:
“It is not possible to unreserve more products of Consu than you have in stock”

The product is a consumable, we should not update its reserved quantity.

opw-3620437

Forward-Port-Of: odoo/odoo#147361
Forward-Port-Of: odoo/odoo#145951

Before this commit, the value displayed on the dashboard for an allocation was the value computed as "virtual_remaining_leaves". However, this value is computed to take into account the remaining time before the allocation expiration date. Reproduce the issue: - have a given time off type without allocation - create for any employee an allocation on that time off type - have an end date for that allocation so that the remaining time before the end of the allocation is inferior to the num

Before this commit, the value displayed on the dashboard for an allocation was the value computed as "virtual_remaining_leaves". However, this value is computed to take into account the remaining time before the allocation expiration date.

Reproduce the issue:

- have a given time off type without allocation
- create for any employee an allocation on that time off type
- have an end date for that allocation so that the remaining time before the end of the allocation is inferior to the number of days given
- go on that employee's time off dashboard

Current result:
The given value for that time off type is the time remaining before the end of the allocation.
Additionnaly, in the popover, the leaves requested value is wrong.

What's expected:
We should see the remaining time off of the employee regardless of when the allocation ends.
The requested leaves amount should be correctly computed.

Fix:
What's displayed is now the max leaves minus the virtual taken leaves, so that the virtual remaining leaves is left unmodified for other usages. The requested leaves amount is now computed as virtual_leaves_taken - leaves_taken.

task-3650007

Forward-Port-Of: odoo/odoo#147103

Previous PR odoo/odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_track

Previous PR odoo/odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view.

Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active)

Steps to reproduce:
- create +save a receipt with a tracked product
- click on the burger button to open the detailed operations of the tracked product
- add 2 move lines + Confirm

Expected behavior:
the move lines save

Actual behavior:
JS traceback due to trying to sort on a field that isn't present in the view




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

Forward-Port-Of: odoo/odoo#147025
Forward-Port-Of: odoo/odoo#146963

The `calendar notification` tests patch the `setTimeout` function. This sometimes leads to infinite recursion when the `multi_tab` service has enough time to initialize: this service make use of `setTimeout` to call the `heartbeat` method repeatedly. Moreover, patching the `setTimeout` method is not a good idea since it makes this method synchronous which totally changes the flow that is tested. This PR fixes this issue by using the `contains` helper instead: this method will wait for t

The `calendar notification` tests patch the `setTimeout` function.
This sometimes leads to infinite recursion when the `multi_tab`
service has enough time to initialize: this service make use of
`setTimeout` to call the `heartbeat` method repeatedly. Moreover,
patching the `setTimeout` method is not a good idea since it makes
this method synchronous which totally changes the flow that is tested.

This PR fixes this issue by using the `contains` helper instead: this
method will wait for the element to be inserted in the DOM and perform
the assertion afterwards.

Forward-Port-Of: odoo/odoo#147462
Forward-Port-Of: odoo/odoo#147275

When `orderpoint.qty_multiple` is decimal, then `remainder` may be wrong. The applied formula is: `qty_to_order % qty_multiple = remainder` Examples: 510 % 10 = 0 51% 1 = 0 5.1 % 0.1 = 0.09999999999999937 which is rounded to 0.1 > 0 0.51 % 0.01 = 0.009999999999999998 which is rounded to 0.01 > 0 This PR fixes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146858 Forward-Port-Of: odoo/odoo#145062

When `orderpoint.qty_multiple` is decimal, then `remainder` may be wrong. The applied formula is: `qty_to_order % qty_multiple = remainder`

Examples:
510 % 10 = 0
51% 1 = 0
5.1 % 0.1 = 0.09999999999999937 which is rounded to 0.1 > 0
0.51 % 0.01 = 0.009999999999999998 which is rounded to 0.01 > 0

This PR fixes it.



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

Forward-Port-Of: odoo/odoo#146858
Forward-Port-Of: odoo/odoo#145062

This error occurs because the user has deleted the default email template so that it will not get the `default_mail_template_id`. Steps to produce : - Install the `Invoicing` module. - Go to Settings > Technical > Email > Email Templates. - Delete the `Invoice: Sending` email template. - Open any existing invoice (not a draft one) - Click on `Send & Print` button > Error will be generated. See traceback : ``` AttributeError: 'NoneType' object has no attribute 'id' File "odoo/http

This error occurs because the user has deleted the default email template so that it will not get the `default_mail_template_id`.

Steps to produce :
- Install the `Invoicing` module.
- Go to Settings > Technical > Email > Email Templates.
- Delete the `Invoice: Sending` email template.
- Open any existing invoice (not a draft one)
- Click on `Send & Print` button > Error will be generated.

See traceback :
```
AttributeError: 'NoneType' object has no attribute 'id'
  File "odoo/http.py", line 2134, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1710, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1737, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1938, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 717, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 461, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 448, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/account/models/account_move.py", line 3985, in action_invoice_sent
    report_action = self.action_send_and_print()
  File "addons/account/models/account_move.py", line 3975, in action_send_and_print
    'default_mail_template_id': template.id,
```

This issue is coming because here
https://github.com/odoo/odoo/blob/77d40f4e843d9f10bde93309087306117a538899/addons/account/models/account_move.py#L3869
it attempts to access the template id. In our case, since the template no longer
exists, it cannot retrieve the template id. 
before this commit https://github.com/odoo/odoo/commit/955091e707df1206ccda8314f1f182e2a37a8362
in previous version it sets the value if there is no default template id see 
https://github.com/odoo/odoo/blob/eb8e2e98a429881f15b65b95fae41d2080b9bb24/addons/account/models/account_move.py#L3698

After this commit, if it cannot find the template, it will return a false value.
Sentry-4508631049

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

Forward-Port-Of: odoo/odoo#137001

Steps to produce ======================== - Activate QR code in pos config - Open session - Make an order for a certain partner (do not invoice) - At receipt, scan the QR code - Sign in as a normal user (like admin) bug - Invoice is created for admin and not the partner in the order After this commit ======================== The partner of the created invoice will be the partner of the POS order. task - 3497301 Forward-Port-Of: odoo/odoo#135843

Steps to produce
========================
- Activate QR code in pos config
- Open session
- Make an order for a certain partner (do not invoice)
- At receipt, scan the QR code
- Sign in as a normal user (like admin) bug - Invoice is created for admin and not the partner in the order

After this commit
========================
The partner of the created invoice will be the partner of the POS order.

task - 3497301

Forward-Port-Of: odoo/odoo#135843

Steps to reproduce: - Activate debug mode - Install `Purchase` module - Set user timezone to `Europe/Brussels` - Create a purchase order and add an order line - Set `Receipt Date` to any date in the future with time 01:00:00 - Confirm the purchase order - Click on "Confirm Receipt Date" button - Check message in the chatter Issue: The receipt date is the day before the one set in the purchase order. (Same issue when sending reminder by mail) Cause: `d

Steps to reproduce:

  - Activate debug mode
  - Install `Purchase` module
  - Set user timezone to `Europe/Brussels`
  - Create a purchase order and add an order line
  - Set `Receipt Date` to any date in the future with time 01:00:00
  - Confirm the purchase order
  - Click on "Confirm Receipt Date" button
  - Check message in the chatter

Issue:

  The receipt date is the day before the one set in the purchase order.
  (Same issue when sending reminder by mail)

Cause:

  `date_planned` is stored in UTC in the database and used as it is in
  the message.

Solution:

  Convert `date_planned` to the order timezone before sending the
  message.

opw-3503928

Forward-Port-Of: odoo/odoo#147317
Forward-Port-Of: odoo/odoo#147013

When the OCR isn't able to detect a value for a field, we shouldn't try to fill it in. For most fields, it wasn't much of an issue, but in the case of the currency, it was very problematic as we're using the `ilike` operator with an empty string, it matches any string ! Anytime the OCR wasn't able to detect the currency, it could set any currency in the expense. Forward-Port-Of: odoo/enterprise#53323 Forward-Port-Of: odoo/enterprise#53092

When the OCR isn't able to detect a value for a field, we shouldn't try to fill it in.
For most fields, it wasn't much of an issue, but in the case of the currency, it was very problematic as we're using the `ilike` operator with an empty string, it matches any string !
Anytime the OCR wasn't able to detect the currency, it could set any currency in the expense.

Forward-Port-Of: odoo/enterprise#53323
Forward-Port-Of: odoo/enterprise#53092