Tuesday, May 13, 2025
28 changes · saas-18.2
Resolved issues and error corrections
This fixes intermittent failures in HR avatar-related automated tests by ensuring chat windows are properly awaited before checks run. The change improves confidence in test results and helps reduce false build failures 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
Expense users now see a clear, friendly message when the required expense account configuration is missing or belongs to the wrong company. This helps staff and administrators understand what needs to be fixed instead of being blocked by a confusing technical error.
Original PR description
The aim of this commit is to give an user friendly message when there is a lack of configuration. Context: Odoo IN didn't set up their expense account and end user faced a very unfriendly (some even says mean!) traceback. They then selected Odoo SA as main company and ended with another meanier traceback as an account from Odoo SA was selected for an expense of Odoo IN. Before this commit: End users could face an unfriendly traceback in case of lack of configuration. After this commit: End users will face a friendly userError in case of a lack of configuration. opw-4699717
Miscellaneous changes
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
Before this commit, when validating an order containing a product tracked by lot, the lot information would appear twice on the receipt. opw-4509159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199485 Forward-Port-Of: odoo/odoo#198209
Original PR description
Before this commit, when validating an order containing a product tracked by lot, the lot information would appear twice on the receipt. opw-4509159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199485 Forward-Port-Of: odoo/odoo#198209
Before this commit, it was possible to export paid orders from the debug window, but importing them was not possible. This commit allows importing orders, making the export/import flow complete and usable for debugging or data transfer purposes. opw-4688082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204622
Original PR description
Before this commit, it was possible to export paid orders from the debug window, but importing them was not possible. This commit allows importing orders, making the export/import flow complete and usable for debugging or data transfer purposes. opw-4688082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204622
**Current behavior before PR:** Steps to reproduce: - Create a link in button primary format. - Select the label of the link either double clicking on the text. - Try to remove link from toolbar. - Notice that the link is not removed properly. This issue happens because if there is an adjacent `feff` character before or after selected text node of link and it is not traversed in selection then `splitAroundUntil` ends up creating an adjacent empty link. If link is in button format the
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a link in button primary format. - Select the label of the link either double clicking on the text. - Try to remove link from toolbar. - Notice that the link is not removed properly. This issue happens because if there is an adjacent `feff` character before or after selected text node of link and it is not traversed in selection then `splitAroundUntil` ends up creating an adjacent empty link. If link is in button format then empty links are visible. **Desired behavior after PR is merged:** Link should be removed entirely. task-4622487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207333 Forward-Port-Of: odoo/odoo#200530
Issue: - When the system date is set to a Sunday, the `test_preset_timing` tour fails. - The failure occurs because no time slots are selectable, due to the absence of Sunday attendance records. Fix: - included Sunday as well when creating attendance in the `resource_calendar`. Forward-Port-Of: odoo/odoo#209422
Original PR description
Issue: - When the system date is set to a Sunday, the `test_preset_timing` tour fails. - The failure occurs because no time slots are selectable, due to the absence of Sunday attendance records. Fix: - included Sunday as well when creating attendance in the `resource_calendar`. Forward-Port-Of: odoo/odoo#209422
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
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#209154
Forward-Port-Of: odoo/odoo#208977Before this commit, draft orders were incorrectly synced to the server in non-restaurant PoS, causing several issues. This commit ensures that draft orders are only synced when the POS is in restaurant mode, preventing unintended behavior. opw-4624604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206635 Forward-Port-Of: odoo/odoo#200211
Original PR description
Before this commit, draft orders were incorrectly synced to the server in non-restaurant PoS, causing several issues. This commit ensures that draft orders are only synced when the POS is in restaurant mode, preventing unintended behavior. opw-4624604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206635 Forward-Port-Of: odoo/odoo#200211
Prior to this fix, the product configurator did not display the on-hand quantities of product variants as shown on the product page, when an attribute’s variant creation was set to 'never'. Steps to reproduce: 1. Create a product with variants. 2. Add multiple attributes and values. 3. Set the variant creation to 'never' for one attribute. 4. Add stock for the product and make it available in POS. 5. Open POS, select the product, and switch between variants. The quantity displayed was
Original PR description
Prior to this fix, the product configurator did not display the on-hand quantities of product variants as shown on the product page, when an attribute’s variant creation was set to 'never'. Steps to reproduce: 1. Create a product with variants. 2. Add multiple attributes and values. 3. Set the variant creation to 'never' for one attribute. 4. Add stock for the product and make it available in POS. 5. Open POS, select the product, and switch between variants. The quantity displayed was only for one variant. This commit ensures that the correct on-hand quantity is shown for each selected variant in POS. opw-4685882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207137 Forward-Port-Of: odoo/odoo#206263
Before this commit, non-manager cashiers were unable to modify product prices even when price control was not enabled, which was not the intended behavior. Additionally, when `pos_hr` was not installed, the `get_cashier` method returned the user object with a `role` attribute. However, when `pos_hr` was installed, the returned cashier used `_role`, leading to inconsistencies and broken functionality depending on the module's presence. opw-4726098 --- I confirm I have signed the CLA and
Original PR description
Before this commit, non-manager cashiers were unable to modify product prices even when price control was not enabled, which was not the intended behavior. Additionally, when `pos_hr` was not installed, the `get_cashier` method returned the user object with a `role` attribute. However, when `pos_hr` was installed, the returned cashier used `_role`, leading to inconsistencies and broken functionality depending on the module's presence. opw-4726098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207114 Forward-Port-Of: odoo/odoo#206650
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
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-4773270
Forward-Port-Of: odoo/odoo#208937## Description I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records. Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products). Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This c
Original PR description
## Description I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records. Currently, my company has around 20 million…
## Description
I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records.
Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products).
Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This computed field is always triggered during incoming stock transactions when calculating the average cost or fixing rounding errors.
## Proposal
To improve performance, I propose implementing a Parallel Index-Only Scan. This method is effective for grouping large datasets while retrieving only fixed columns, optimizing query execution.
## Benchmark
| Before | After | Speedup |
|--------|--------|--------|
| 1.1 s| 97.8 ms | 11x|
### Before
```
Finalize GroupAggregate (cost=1000.56..397852.39 rows=538 width=80) (actual time=1040.355..1114.694 rows=1 loops=1)
Group Key: product_id
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Gather (cost=1000.56..397825.49 rows=1076 width=80) (actual time=1039.900..1114.679 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Partial GroupAggregate (cost=0.56..396717.89 rows=538 width=80) (actual time=1036.758..1036.759 rows=1 loops=3)
Group Key: product_id
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Parallel Index Scan using stock_valuation_layer_index on stock_valuation_layer
(cost=0.56..392927.16 rows=302613 width=20) (actual time=0.608..975.431 rows=247487 loops=3)
Index Cond: ((product_id = 140) AND (company_id = 1))
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
Planning:
Buffers: shared hit=9 dirtied=1
Planning Time: 0.139 ms
Execution Time: 1114.732 ms
```
### After
```
Finalize GroupAggregate (cost=1000.56..21876.83 rows=538 width=80) (actual time=91.888..97.719 rows=1 loops=1)
Group Key: product_id
Buffers: shared hit=12889 read=7121
-> Gather (cost=1000.56..21849.93 rows=1076 width=80) (actual time=91.636..97.704 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=12889 read=7121
-> Partial GroupAggregate (cost=0.56..20742.33 rows=538 width=80) (actual time=87.579..87.580 rows=1 loops=3)
Group Key: product_id
Buffers: shared hit=12889 read=7121
-> Parallel Index Only Scan using idx_svl_company_product on stock_valuation_layer
(cost=0.56..16951.60 rows=302613 width=20) (actual time=0.044..46.642 rows=247487 loops=3)
Index Cond: ((company_id = 1) AND (product_id = 140))
Heap Fetches: 9188
Buffers: shared hit=12889 read=7121
Planning Time: 0.107 ms
Execution Time: 97.751 ms
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207311
Forward-Port-Of: odoo/odoo#203038Steps 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
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
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 Forward-Port-Of: odoo/odoo#209614
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 Forward-Port-Of: odoo/odoo#209614
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750
Original PR description
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750594 Forward-Port-Of: odoo/odoo#209497
### 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#83452 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#83452 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
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750
Original PR description
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750594 Forward-Port-Of: odoo/enterprise#85303
Beofre this commit: Products with both positive and negative sales order lines in SO can result it total quantity = 0 when calcuating average cost. Causing division by zero error. After this commit: Added a check to prevent division if total quantity of product is zero. Negative order lines are usually used for return of product, it is not included in shipping request. opw-4655713 Forward-Port-Of: odoo/enterprise#84201 Forward-Port-Of: odoo/enterprise#83500
Original PR description
Beofre this commit: Products with both positive and negative sales order lines in SO can result it total quantity = 0 when calcuating average cost. Causing division by zero error. After this commit: Added a check to prevent division if total quantity of product is zero. Negative order lines are usually used for return of product, it is not included in shipping request. opw-4655713 Forward-Port-Of: odoo/enterprise#84201 Forward-Port-Of: odoo/enterprise#83500
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:** When a task with an allocated time > 0.0 but no timesheets is created in a shared project (with edit rights), the portal user incorrectly sees 0.0 as the allocated time. **Steps to reproduce:** - Ensure the sale_timesheet module is installed. - Create a new project. - Create a task with allocated time and no timesheets. - Share the project with a portal user (edit permission). In the portal user's kanban view, the allocated time of the task is displayed as 0.0 instead o
Original PR description
**issue:** When a task with an allocated time > 0.0 but no timesheets is created in a shared project (with edit rights), the portal user incorrectly sees 0.0 as the allocated time. **Steps to reproduce:** - Ensure the sale_timesheet module is installed. - Create a new project. - Create a task with allocated time and no timesheets. - Share the project with a portal user (edit permission). In the portal user's kanban view, the allocated time of the task is displayed as 0.0 instead of the correct allocated time. opw-4582705 Forward-Port-Of: odoo/enterprise#82171
**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
This commit fixes the issue brought by the forward-port PR https://github.com/odoo/enterprise/pull/83866 The field `uom_po_id` used has been removed in version 18.1 and replaced by `uom_id`. task-4751991 Forward-Port-Of: odoo/enterprise#84102
Original PR description
This commit fixes the issue brought by the forward-port PR https://github.com/odoo/enterprise/pull/83866 The field `uom_po_id` used has been removed in version 18.1 and replaced by `uom_id`. task-4751991 Forward-Port-Of: odoo/enterprise#84102
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
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