Tuesday, May 13, 2025
4 changes · saas-18.1
Resolved issues and error corrections
This fixes an error that could occur when users created a product directly while adding a sales order line from a task or helpdesk ticket. The system now fills in the company currency automatically, allowing the product creation flow to complete reliably.
Original PR description
Steps to Reproduce: - Install sale_timesheet/ industry_fsm_sale/ helpdesk_sale_timesheet. - Create a task or ticket and open it. - Add a customer and create Sale Order line on the fly. - Create product on the fly click "Create and Edit" Issue: A traceback occurs when creating the product on the fly from SOL. Root Cause: When the `sale_timesheet` module is installed, the `currency_id` is not included in the default values during on-the-fly product creation. This causes a missing `currency_id`, leading to a singleton error during `tax_string` computation in the `account` module. Solution: Override the `default_get` method in the `product.product` model to assign the company’s `currency_id` if missing. This ensures the field is always set during creation, preventing the traceback. task-4668797
This fix makes HR avatar-related automated tests wait properly before checking that chat windows appear. It reduces random test failures, helping the development and release process stay more stable without changing user-facing behavior.
Original PR description
There were some errors in the tests because we asserted Chat windows were present without waiting for them (except for the one tick). This produced indeterminism which are now fixed runbot-error-162715 runbot-error-163000 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
Changing the unit of measure on a repair order now works without causing an error message. This helps users complete repair orders smoothly when multiple units of measure are enabled.
Original PR description
Steps to reproduce:
- Enable "Units of Measure" in Inventory settings
- Create a repair order
- Select a product
- Change its UoM
Problem:
A traceback is triggered:
```
Uncaught Promise > Can not evaluate python expression:
([('id', 'in', allowed_uom_ids)]) Error: Name 'allowed_uom_ids' is not defined
Occured on localhost:8076 on 2025-05-07 20:02:29 GMT
EvalError: Can not evaluate python expression: ([('id', 'in', allowed_uom_ids)])
Error: Name 'allowed_uom_ids' is not defined
```
The problem is that the field is "readonly=False" in the view, but by
default it's "readonly=True" in Python side.
As a result, the ORM considers the field as read-only and does not
trigger the computation of "allowed_uom_id". When the domain is later
applied in Python, it causes a traceback due to the missing computed
value.
Solution:
Explicitly set readonly=False in the Python field definition.
opw-4773270This fixes an internal subscription test that could fail depending on the day of the month. The test now uses a more realistic payment amount, helping keep subscription billing validation stable without changing customer-facing behavior.
Original PR description
Before this commit, the test_automatic_invoice_token test would fail with the following traceback: FAIL: TestSubscriptionController.test_automatic_invoice_token Traceback (most recent call last):…
Before this commit, the test_automatic_invoice_token test would fail
with the following traceback:
FAIL: TestSubscriptionController.test_automatic_invoice_token
Traceback (most recent call last):
File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 157, in test_automatic_invoice_token
subscription = self._portal_payment_controller_flow()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 235, in _portal_payment_controller_flow
self.assertEqual(subscription.invoice_ids.sorted('id').mapped('state'), ['posted'])
AssertionError: Lists differ: ['posted', 'posted'] != ['posted']
First list contains 1 additional elements.
First extra element 1:
'posted'
- ['posted', 'posted']
+ ['posted']
The issue was detected when the test was running on the last day of the
month.
When we were not on the last day of the month, in the controller /my/subscriptions/<int:order_id>/transaction
invoice_to_pay was None because there was only once invoice already paid.
As a result, amount_to_invoice was 0.0 in this code:
amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
a tx with an amount equal to 0 would be created in the controller and
in payment_transaction.py, during the postprocess, a "partially paid tx" would be found as the amount would not match (2.3 and 0.0).
We prefer to fix the test by making sure an amount is set in the parameters of the controller. It will make the flow more coherent and realistic.
\# Explanation
When /my/subscriptions/<int:order_id>/transaction was called the second
time in the test, no amount kwarg was provided. As a result the
following line would be called in the controller:
amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
invoice_to_pay is always None and therefore the amount_to_invoice is
equal to order_sudo.amount_to_invoice
When we look,at _compute_amount_to_invoice, we have:
is_invoice_due = (
not order.last_invoice_date
or (order.next_invoice_date <= today and order.last_invoice_date <= today)
)
if not is_invoice_due:
line.amount_to_invoice = 0.0
continue
We will compare when the code run on the 30th of march or on the 31th of
march.
\## 30th of March
next invoice date is 2025-04-30
start date is 2025-03-30
last_invoice_date is 2025-03-30
next_invoice_date <= today is False
last_invoice_date <= today is True
is_invoice_due = (
not order.last_invoice_date
or (order.next_invoice_date <= today and order.last_invoice_date <= today)
)
Therefore is_invoice_due is False and we enter the condition and set the amount_to_invoice equal to 0.0
\## 31th of March
next invoice date is 2025-04-30
start date is 2025-03-31
last_invoice_date is False
next_invoice_date <= today is False (same)
last_invoice_date <= today is False because last_invoice_date is not set
Therefore, is_invoice_due is True and we set amount_to_invoice to the recurring total of the SO.
The issue is occuring because next invoice date is 2025-04-30 in both situations !
2025-03-30 + relativedelta(months=1) is equal to 2025-03-31 + relativedelta(months=1)
In the definition of last_invoice_date, we compare the next invoice date - billing_period to today:
last_date = order.next_invoice_date and order.plan_id.billing_period and order.next_invoice_date - order.plan_id.billing_period
\# When we start the 30th of March:
\# last_date = 30th of april - 1 month = 30th of march
\# When we start the 31th of March:
\# last_date keep the same value because the next_invoice_date is the
same.
start_date = order.start_date or fields.Date.today()
if order.state == 'sale' and last_date and last_date >= start_date:
order.last_invoice_date = last_date <-- 30th of March >= 30th of March (today when we start on the 30th
else:
order.last_invoice_date = False <-- 30th of March is not larger than 31th of March (today when we start on the 31th)
runbot error: 162144