Wednesday, April 23, 2025
28 changes · 18.0
Resolved issues and error corrections
The Tags filter in the website shop sidebar now behaves like the other filters, allowing shoppers to collapse or expand it. Its spacing was also adjusted for a more consistent and polished shopping page layout.
Original PR description
<b>Steps to reproduce:</b> 1. Go to website > Shop > Scroll to tags filter (If tags aren't visible in the sidebar, go to Sales > Configuration > Product Tags > create tags) 2. Notice that Tags filter cannot be collapsed unlike other filters 3. Observe that margins and spacing don't match other filter components <b>Issue:</b> The "Tags" filter on the website shop sidebar lacked a collapsible header, unlike other filters such as "Price Range". This caused UI inconsistency. Additionally, the margin and spacing did not align visually with other filter components. <b>Solution:</b> Applied Bootstrap collapse classes to the Tags filter to enable accordion-style toggling. Adjusted margin and structure to match the layout of other sidebar filters for visual consistency. opw-4702463
This update adjusts an internal web test so it remains reliable with newer Chrome versions. It does not change the user experience, but helps keep automated quality checks stable and trustworthy.
Original PR description
Since Chrome 135, the "Keep scrollTop when loading records with load more" unit test fails with a scrolling value way higher than expected. In practice, the scroll in the test goes down to the "Load more" button after it has been clicked instead of keeping scroll to the same value as before the loading of the "more" items. Weirdly, it doesn't look to be an actual issue when performed by the user, but only in the test suite. This commit works around that issue by using `element.click()` followed by waiting for an animation frame instead of using `contains().click()`, because... well, the two helpers behave slightly differently. 🤷
This fix improves how website mega menus appear when using vertical navigation layouts such as sidebars or hamburger menus. It prevents menu items from overlapping, making navigation cleaner and easier for visitors to use.
Original PR description
Steps to Reproduce : 1. Add a Mega Menu through Menu Editor 2. Switch the header template to Sidebar 3. Once done --> Open the mega menu; it will overlap with one another. Issue: Vertically aligned navbars like the sidebar and hamburger navbar, have styling issues with the mega menu. The mega menu is designed according to the full width of the screen, which leads to not look good mega menu when opened in a limited-spaced navbar. Fix: This commit adds the style particularly to vertical navbars, such that the styling of the mega menu is proper even in these navbars. Task: 4684074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
This fixes an intermittent automated test failure by adding wait steps before interacting with the PDF signing area. The change helps keep Belgian payroll contract tests reliable without changing the user-facing payroll workflow.
Original PR description
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the
setTimeout(() => this.initializeIframe(), 1);
interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.
I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...
https://runbot.odoo.com/odoo/error/181583Updating pivot settings in spreadsheets no longer removes the sorting users applied to pivot values. This preserves the expected spreadsheet view after changes such as adjusting filters or domains, reducing repeated manual work.
Original PR description
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934
The Luxembourg payroll module no longer tries to load missing setup files during its scheduled payroll data update. This prevents an error when administrators run the update action, improving reliability without changing payroll behavior.
Original PR description
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action.
**Steps to produce:**
- Install `l10n_lu_hr_payroll` module.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.
`ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'`
Here, `_get_data_files_to_update` method at [1] attempts to load the `hr_salary_rule_data.xml` and `hr_gratification_rule_data.xml` files, which are not present in the codebase.
[1] - https://github.com/odoo/enterprise/blob/809fda39b439edf6259ade445e396e722c1bb53a/l10n_lu_hr_payroll/models/hr_payslip.py#L219-L220
This commit ensures the removal of invalid file references to prevent errors when executing the scheduled action.
Sentry - 6316151728This update adjusts a Helpdesk portal test so it waits for the final expected result instead of ending while background page content may still be loading. This reduces false test failures and helps keep Helpdesk releases more stable without changing customer-facing functionality.
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748
Miscellaneous changes
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for
Original PR description
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for searching by Name. Task - 4574162 Forward-Port-Of: odoo/odoo#198461
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties
Original PR description
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties values again. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3#diff-89ec9296feb48614f91829b8b732dca614359831967fa65a2126d6fe68c84450 Forward-Port-Of: odoo/odoo#206975 Forward-Port-Of: odoo/odoo#206824
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and r
Original PR description
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206841
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR
Original PR description
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204626 Forward-Port-Of: odoo/odoo#176765
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier
Original PR description
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier than expected. Reason: The check_in date was incorrect because it was using UTC instead of the employee's local time zone. Fix: Converted check_in to the employee's local time zone before extracting the date. issue:https://github.com/odoo/odoo/issues/169592 task-4320477 Forward-Port-Of: odoo/odoo#206713 Forward-Port-Of: odoo/odoo#192434
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#205940
Original PR description
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#205940
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206811
Original PR description
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206811
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206409
Original PR description
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206409 Forward-Port-Of: odoo/odoo#187233
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10 units of P1 - Confirm the MO - Split the MO into two: - This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002” - For the first MO (WH-MO-001): - Set Quantity Produced to 1. - Validate it and choose to create a backorder. Problem: - The b
Original PR description
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10…
Steps to reproduce the issue:
- Create a storable product “P1”
- Create a Bill of Materials:
- Finished product: 1 unit of P1
- Components:
- 1 unit of C1
- Create a manufacturing order to produce 10 units of P1
- Confirm the MO
- Split the MO into two:
- This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002”
- For the first MO (WH-MO-001):
- Set Quantity Produced to 1.
- Validate it and choose to create a backorder.
Problem:
- The backorder is incorrectly named “WH-MO-001-003” instead of the expected WH-MO-003.
- Additionally, the original MO is renamed “WH-MO-001-001”, which is unexpected.
- However, if you perform the same steps on the second MO (WH-MO-002), the backorder is correctly named “WH-MO-003”, and the original name remains unchanged.
Root cause:
- When the original MO is first split, each resulting MO receives a backorder sequence:
- First split MO (WH-MO-001): backorder_sequence = 1
- Second split MO (WH-MO-002): backorder_sequence = 2
- When creating a backorder from an MO with backorder_sequence = 1, the following logic is triggered:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1844
- Since the condition if backorder_sequence > 1 is false for WH-MO-001:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1782
- So the name + seq_back is added:
https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1784
opw-4686959
Forward-Port-Of: odoo/odoo#205760In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
Original PR description
In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
Original PR description
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
Original PR description
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Original PR description
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
Original PR description
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Original PR description
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Original PR description
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Original PR description
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
Original PR description
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr
Original PR description
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26 but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0 https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48 ### Fix: If we have a fsm_task we can fallback on its order_id if order_id is false. opw-4712922 Forward-Port-Of: odoo/enterprise#83396