Tuesday, May 13, 2025
27 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: 162144Miscellaneous changes
requires: https://github.com/odoo/enterprise/pull/84124 --- In the control panel, any middle element (whether it's the search bar or control_panel_actions) tends to drop below the rest of the content under the `lg` breakpoint due to missing spacing. Under `md`, these elements collapse into dropdowns or toggle buttons as expected. Prior to this commit, there was an issue with the spacing applied between `md` and `lg`. This was either caused by the `mt-md-0` class on the search bar or the
Original PR description
requires: https://github.com/odoo/enterprise/pull/84124 --- In the control panel, any middle element (whether it's the search bar or control_panel_actions) tends to drop below the rest of the content…
requires: https://github.com/odoo/enterprise/pull/84124 --- In the control panel, any middle element (whether it's the search bar or control_panel_actions) tends to drop below the rest of the content under the `lg` breakpoint due to missing spacing. Under `md`, these elements collapse into dropdowns or toggle buttons as expected. Prior to this commit, there was an issue with the spacing applied between `md` and `lg`. This was either caused by the `mt-md-0` class on the search bar or the specific breakpoint use of `gap-lg-3` To resolve the spacing issue between `md` and `lg`, we now apply the correct gap (by adding a `gap-2` alongside the `gap-lg-3`) on the control panel’s main div, and remove unwanted margin/padding classes. | | Before (between md and lg) | After (between md and lg) | |--------|--------|--------| | w/ searchbar |  |  | | w/ actions |  |  | task-4568501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207461
Before this commit, for the layouts "Wavy" and "Bubble", when they're applied when printing Draft Invoices, the grey box (with id=informations) has no data and appears as a weird gray line. This commit hides this grey box by adding to it an outer `t-if` condition. task-4670747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209514
Original PR description
Before this commit, for the layouts "Wavy" and "Bubble", when they're applied when printing Draft Invoices, the grey box (with id=informations) has no data and appears as a weird gray line. This commit hides this grey box by adding to it an outer `t-if` condition. task-4670747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209514
Steps to reproduce the issue: - Start a new database without installing any module - Log in - Go to Settings - Invite a new user => A traceback occurs due to the `email_normalized` field being accessed on `res.users`. This field is defined in the `mail` module, but `base_setup` does not depend on it. This commit adds a check to ensure that the `email_normalized` field exists before attempting to access it, preventing the traceback. opw-4784587 Forward-Port-Of: odoo/odoo#209310
Original PR description
Steps to reproduce the issue: - Start a new database without installing any module - Log in - Go to Settings - Invite a new user => A traceback occurs due to the `email_normalized` field being accessed on `res.users`. This field is defined in the `mail` module, but `base_setup` does not depend on it. This commit adds a check to ensure that the `email_normalized` field exists before attempting to access it, preventing the traceback. opw-4784587 Forward-Port-Of: odoo/odoo#209310
Versions -------- - saas-17.4+ Steps ----- 1. Create a Azure storage container with a hyphen in its name; 2. connect it to your database; 3. go to a contact; 4. click "Send message"; 5. upload an attachment. Issue ----- Server Error pop-up. In the logger, you get: > `TypeError: UserError.__init__() takes 2 positional arguments but 3 were given` Cause ----- 1. The `ValidationError` string is badly formatted. 2. The regex to verify Azure Blob Storage URLs doesn't allow hy
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Create a Azure storage container with a hyphen in its name; 2. connect it to your database; 3. go to a contact; 4. click "Send message"; 5. upload an attachment. Issue ----- Server Error pop-up. In the logger, you get: > `TypeError: UserError.__init__() takes 2 positional arguments but 3 were given` Cause ----- 1. The `ValidationError` string is badly formatted. 2. The regex to verify Azure Blob Storage URLs doesn't allow hyphens in the container name. Solution -------- 1. As the `ValidationError` is only shown in the logger, format it as an f-string. 2. Update the regex to the constraints imposed by Azure[^1]. [^1]: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftstorage opw-4770160 Forward-Port-Of: odoo/odoo#209127
Description of the issue/feature this PR addresses: Incomplete migration to Odoo 18.0 regarding tree_view_ref/list_view_ref --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207025
Original PR description
Description of the issue/feature this PR addresses: Incomplete migration to Odoo 18.0 regarding tree_view_ref/list_view_ref --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207025
Before this commit, clearing lines in the sanitize data cache used a forward iteration, which caused some lines to be skipped due to index shifting when deleting items. This could result in only half of the lines being removed and potentially lead to errors. After this commit, order lines are deleted using a backward iteration, ensuring that all lines are properly removed without skipping any. opw-4770945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
Before this commit, clearing lines in the sanitize data cache used a forward iteration, which caused some lines to be skipped due to index shifting when deleting items. This could result in only half of the lines being removed and potentially lead to errors. After this commit, order lines are deleted using a backward iteration, ensuring that all lines are properly removed without skipping any. opw-4770945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208391
Before this commit, the can_be_merged_with method did not work correctly because an incorrect argument was passed to floatIsZero. As a result, orderlines with different prices could be merged together, leading to inaccurate order information. opw-4778629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209014
Original PR description
Before this commit, the can_be_merged_with method did not work correctly because an incorrect argument was passed to floatIsZero. As a result, orderlines with different prices could be merged together, leading to inaccurate order information. opw-4778629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209014
To reproduce: - Enable Stripe payment provider, and disable "Allow Saving Payment Methods" - Create a subscription and 'Sent' it - Click on "Preview" and try to paid using payment method provided by Stripe. An error is raised: ``` The provided setup_future_usage (null) does not match the expected setup_future_usage (off_session). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements. ``` This commit ensure we only request for token
Original PR description
To reproduce: - Enable Stripe payment provider, and disable "Allow Saving Payment Methods" - Create a subscription and 'Sent' it - Click on "Preview" and try to paid using payment method provided by Stripe. An error is raised: ``` The provided setup_future_usage (null) does not match the expected setup_future_usage (off_session). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements. ``` This commit ensure we only request for tokenization if it's required and both the provider and the payment method support it. opw-4605528 opw-4723230 Forward-Port-Of: odoo/odoo#206231
- Fix issue in `pos_self_order` module where the displayed product price was wrong when a product had variants (with creation "Instantly") and with an extra price. - The price displayed in the product card was the price of the first variant instead of the price of the product template (since we have not yet chosen a variant). opw: 4755565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208995
Original PR description
- Fix issue in `pos_self_order` module where the displayed product price was wrong when a product had variants (with creation "Instantly") and with an extra price. - The price displayed in the product card was the price of the first variant instead of the price of the product template (since we have not yet chosen a variant). opw: 4755565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208995
Before this commit, products that were not available for self-ordering were still loaded into the PoS and displayed as "Out of stock." This could cause confusion for users. After this commit, unavailable products are no longer loaded or displayed in the PoS, ensuring that only available products are shown to customers. opw-4764785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208537
Original PR description
Before this commit, products that were not available for self-ordering were still loaded into the PoS and displayed as "Out of stock." This could cause confusion for users. After this commit, unavailable products are no longer loaded or displayed in the PoS, ensuring that only available products are shown to customers. opw-4764785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208537
Before this commit, if the POS blackbox module was installed, the sale details report would display total price in price included because of an override. In this commit, we add the config id to the method computing this price so that the blackbox module can override this computation only if the config is a blackbox one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205559
Original PR description
Before this commit, if the POS blackbox module was installed, the sale details report would display total price in price included because of an override. In this commit, we add the config id to the method computing this price so that the blackbox module can override this computation only if the config is a blackbox one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205559
to reproduce: =========== step 1 : change language to arab step 2 : go to dashboard app using mobile Problem: ======= overlapped text in the Dashboard module we forced direction to ltr on all languages in web and we didn't add this change in the mobile part Solution: ======= force ltr direction even on rtl languages in the mobile part opw-4586743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
to reproduce:
===========
step 1 : change language to arab
step 2 : go to dashboard app using mobile
Problem:
=======
overlapped text in the Dashboard module
we forced direction to ltr on all languages in web and we didn't add this change in the mobile part
Solution:
=======
force ltr direction even on rtl languages in the mobile part
opw-4586743
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#208977Steps to reproduce: ------------------------ - Install POS & setup kitchen printer. - Open session and make an order with instant creation mode attribute product. - Cancel the order. Issue: ------- - In the cancel KOT the attribute name wasn't visible. Cause: --------- - Wrong value passed for display name just simple name was passed instead of display name containing the attribute. FIX: ------ - Corrected the value passed for the display name. Task: 4720599 Forward-Port-O
Original PR description
Steps to reproduce: ------------------------ - Install POS & setup kitchen printer. - Open session and make an order with instant creation mode attribute product. - Cancel the order. Issue: ------- - In the cancel KOT the attribute name wasn't visible. Cause: --------- - Wrong value passed for display name just simple name was passed instead of display name containing the attribute. FIX: ------ - Corrected the value passed for the display name. Task: 4720599 Forward-Port-Of: odoo/odoo#207167
Use `time.process_time_ns` which is not influenced by other processes running on the machine. This allows to have consistent timing and less non-deterministic results. We also switch to the ns version, so that division per record does not loose too much precision for small values. We may need to fallback to `perf_counter_ns` on some systems where the precision is too low. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#2
Original PR description
Use `time.process_time_ns` which is not influenced by other processes running on the machine. This allows to have consistent timing and less non-deterministic results. We also switch to the ns version, so that division per record does not loose too much precision for small values. We may need to fallback to `perf_counter_ns` on some systems where the precision is too low. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207958
requires: https://github.com/odoo/odoo/pull/207461 --- This commit removes an obsolete padding on .o_control_panel_actions class in the `documents` module. The layout issue it was compensating for has now been properly addressed in the `web` module by applying the correct gap-* classes correctly on the control panel’s main div. task-4568501 Forward-Port-Of: odoo/enterprise#84124
Original PR description
requires: https://github.com/odoo/odoo/pull/207461 --- This commit removes an obsolete padding on .o_control_panel_actions class in the `documents` module. The layout issue it was compensating for has now been properly addressed in the `web` module by applying the correct gap-* classes correctly on the control panel’s main div. task-4568501 Forward-Port-Of: odoo/enterprise#84124
### Before this PR - Go on point of sale (with pos_discount installed) - Click on Action - Click on Discount - Write a discount percentage - Click OK - Validate POS An error appear because the negative price should be a printRecItemAdjustment with type 3 ### After this PR the right printRecitemAdjustiment is sent to printer Forward-Port-Of: odoo/enterprise#80951
Original PR description
### Before this PR - Go on point of sale (with pos_discount installed) - Click on Action - Click on Discount - Write a discount percentage - Click OK - Validate POS An error appear because the negative price should be a printRecItemAdjustment with type 3 ### After this PR the right printRecitemAdjustiment is sent to printer Forward-Port-Of: odoo/enterprise#80951
Steps: - install `web_studio` and `documents_spreadsheet` - open documents - open studio on the spreadsheet kanban view (the default one) - change sort by field to "created on" field - error This commit replaces encodeURIComponent with window.encodeURIComponent, because owl won't try to evaluate this variable via the context. And so the fix ```js get renderingContext() { const context = super.renderingContext; context.encodeURIComponent = encodeURIComponent;
Original PR description
Steps:
- install `web_studio` and `documents_spreadsheet`
- open documents
- open studio on the spreadsheet kanban view (the default one)
- change sort by field to "created on" field
- error
This commit replaces encodeURIComponent with window.encodeURIComponent,
because owl won't try to evaluate this variable via the context.
And so the fix
```js
get renderingContext() {
const context = super.renderingContext;
context.encodeURIComponent = encodeURIComponent;
...
}
```
In `DocumentsKanbanRecord` is no longer necessary.
The error occurred because `encodeURIComponent` was not found in the context object.
The reason this fix doesn't work with studio is the view is defined as
```xml
<kanban js_class="documents_kanban"/>
```
and studio does not load view js classes.
And since the fix is in `documents_kanban`, it's not taken into account. opw-4744886
Forward-Port-Of: odoo/enterprise#84411### Steps to reproduce: - Create an employee with flexible schedule with 8 hours per day - Navigate to Attendance app -> Gantt View - Check the progress bar for the flexible employee - Notice the progress bar will show X/11 ### Cause: This is happening as when calculating the maximum value for the employee's working hours we are adding a day to the date range https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/hr_attendance_gantt/models/hr_attendance.py#L
Original PR description
### Steps to reproduce: - Create an employee with flexible schedule with 8 hours per day - Navigate to Attendance app -> Gantt View - Check the progress bar for the flexible employee - Notice the progress bar will show X/11 ### Cause: This is happening as when calculating the maximum value for the employee's working hours we are adding a day to the date range https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/hr_attendance_gantt/models/hr_attendance.py#L47 ### Fix: We don't need to add this extra day as already the difference between the start and stop is relfecting the correct number of days opw-4680513 Forward-Port-Of: odoo/enterprise#84250
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also
Original PR description
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also means that it wasn't possible to share more than one request document. Task-4718126 Forward-Port-Of: odoo/enterprise#83222
**Issue:** A traceback error is raised when the assignee of a Field Service task has no calendar **Steps to reproduce:** - Make sure admin (Michel Admin) has no calendar in the Employee module - Field Service > New - Create a new task with Michel Admin as assignee and click save without choosing Planned Date and leave Allocated Hours at 0 - Choose Planned Date then click save again A traceback error is raised opw-4672980 Forward-Port-Of: odoo/enterprise#83839
Original PR description
**Issue:** A traceback error is raised when the assignee of a Field Service task has no calendar **Steps to reproduce:** - Make sure admin (Michel Admin) has no calendar in the Employee module - Field Service > New - Create a new task with Michel Admin as assignee and click save without choosing Planned Date and leave Allocated Hours at 0 - Choose Planned Date then click save again A traceback error is raised opw-4672980 Forward-Port-Of: odoo/enterprise#83839
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly. Forward-Port-Of: odoo/ente
Original PR description
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly. Forward-Port-Of: odoo/enterprise#83228
Steps to reproduce the bug: - Create a quality point with the following settings: - Measure on: Operation - Picking Type: Manufacturing - Product Category: "All" - Create a storable product “P1”: - Product Category: "All" - BoM: - components: - 1 unit of P1 - Create a manufacturing order to produce one unit of P1 - Confirm it Problem: The manufacturing order is confirmed, but the corresponding quality check is not created. This issue occurs when a quality
Original PR description
Steps to reproduce the bug: - Create a quality point with the following settings: - Measure on: Operation - Picking Type: Manufacturing - Product Category: "All" - Create a storable product “P1”: -…
Steps to reproduce the bug:
- Create a quality point with the following settings:
- Measure on: Operation
- Picking Type: Manufacturing
- Product Category: "All"
- Create a storable product “P1”:
- Product Category: "All"
- BoM: - components: - 1 unit of P1
- Create a manufacturing order to produce one unit of P1
- Confirm it
Problem:
The manufacturing order is confirmed, but the corresponding quality check is not created.
This issue occurs when a quality point is configured with "Measure on:
Operation". In that case, the quality check should be created for
manufacturing orders here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L49-L51
However, an empty record is passed for the product parameter.
As a result, the domain defined here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L19-L21
is evaluated with both product and category set to False, which
prevents the created quality point from being matched and thus no
quality check is created.
https://github.com/odoo/enterprise/blob/6ee3472937118e758399a9577251efad8c4c1195/quality_control/models/quality.py#L175-L177
opw-4762914
Forward-Port-Of: odoo/enterprise#85042
Forward-Port-Of: odoo/enterprise#84683Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113
Original PR description
Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113