Tuesday, July 23, 2024
14 changes · master
Enhancements to existing features
This change updates an internal test to match expected system behavior after a stored field now performs an additional lookup. It helps keep automated checks accurate without changing user-facing document or accounting workflows.
Original PR description
Test need to be adapted because a new stored field requires to do a search
Features or functions removed from Odoo
An unused helper function was removed from the signing template popover component. This is a minor cleanup that reduces code clutter without changing how users create or manage signatures.
Original PR description
Removed a unused function parseInteger in SignItemCustomPopover component task-3975796
Code cleanup and technical improvements
This update restructures how related data is prepared for several communication-related features, including Knowledge, VoIP, and WhatsApp. It supports future improvements while keeping current user-facing behavior largely unchanged.
Original PR description
\* = knowledge, voip, whatsapp And adapted the most simple cases. Part of task-3605717 https://github.com/odoo/odoo/pull/172863
Miscellaneous changes
When stock is not installed, the override of _fsm_ensure_sale_order in industry_fsm_stock doesn't auto-confirm sale order, so the test `test_qty_to_invoice_from_fsm` failed because the `qty_to_invoice` was set to 0 if the order was not confirmed. With this PR, the order is confirmed in the test flow if stock is not installed. opw-[4061485](https://www.odoo.com/web#id=4061485&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#67116
Original PR description
When stock is not installed, the override of _fsm_ensure_sale_order in industry_fsm_stock doesn't auto-confirm sale order, so the test `test_qty_to_invoice_from_fsm` failed because the `qty_to_invoice` was set to 0 if the order was not confirmed. With this PR, the order is confirmed in the test flow if stock is not installed. opw-[4061485](https://www.odoo.com/web#id=4061485&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#67116
This update prepares Odoo’s guided test tours for a simpler way to identify content inside pop-up windows. It reduces internal complexity and helps keep future maintenance of automated user flows more consistent, with no expected direct impact on end users.
Original PR description
In order to simplify the structure of a tour step, it was decided to remove the "in_modal" key. The purpose of this key is to search for the trigger in a modal element. But actually you just need to add ".modal" to the selector. This functionality therefore really has little added value. That's why we're removing it. In this commit, we prepare the ground to be able to remove this functionality by adding .modal to the selectors and forcing the fact of not looking in a modal (in_modal: false) otherwise that would be duplicative. task~3974087 https://github.com/odoo/odoo/pull/173861
This change updates internal automated tours so visibility checks are handled consistently without a separate allowInvisible setting. It reduces maintenance complexity for test scenarios across accounting, knowledge, payroll, studio, and website studio areas, with no expected direct impact for end users.
Original PR description
In this commit, we remove the allowInvisible key from the structure of a tour step. By default, each trigger in a step must be visible. If we play with a pseudo selector :visible (or :not(:visible)) then tour_compiler does not check if the element is visible (canContinue) in the DOM and the trigger only returns what is targeted. Example: trigger: ".my_element" => Must be visible trigger: ".my_element:visible" => Must be visible. But the tour_compiler doesn't check anything. The verification is done using the pseudo selector trigger: ".my_element:not(:visible)" => Should NOT be visible using the pseudo selector task~3974087 https://github.com/odoo/odoo/pull/172085
The automated tour testing helper now saves field edits more consistently by triggering the expected follow-up events immediately. This reduces confusion for developers maintaining business workflows and makes test scenarios easier to write and keep reliable across multiple Odoo apps.
Original PR description
Before this commit, in rounds, the edit() helper does not directly trigger blur events and changes after modifying the value of a field (input or textarea). This was a desired behavior but which implies that it is then necessary to add another event which then triggers the blur & change events, for example: - && press Enter - && press Tab - && click body - && click .where_you_want However, this causes confusion because it is not what is expected by users of the API. In this commit, to simplify the API, we trigger the blur and change events directly in the edit() helper. task~3922501 https://github.com/odoo/odoo/pull/166466
Steps: - Install l10n_nl_reports - Open GL for the year 2024 - Export XAF -> Period numbers are displayed from 401 to 412, instead of 01 to 12 in the exported file opw-3999985 Forward-Port-Of: odoo/enterprise#67127 Forward-Port-Of: odoo/enterprise#67098
Original PR description
Steps: - Install l10n_nl_reports - Open GL for the year 2024 - Export XAF -> Period numbers are displayed from 401 to 412, instead of 01 to 12 in the exported file opw-3999985 Forward-Port-Of: odoo/enterprise#67127 Forward-Port-Of: odoo/enterprise#67098
## Pull Request HOOT (PRHOOT) - part 20 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 20 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 20 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Community: https://github.com/odoo/odoo/pull/173332 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#67055 Forward-Port-Of: odoo/enterprise#66895
Moved iot.box view technical information to "Technical Information" tab. Task: 4033301 Forward-Port-Of: odoo/enterprise#66306
Original PR description
Moved iot.box view technical information to "Technical Information" tab. Task: 4033301 Forward-Port-Of: odoo/enterprise#66306
Only a few templates are fetched when the user tries to sync all the templates from the `WhatsApp Business Account` form view. Problem: The API request used to fetch all templates incorporates pagination. In the current scenario, the next URL to the subsequent page is included in the response, but we are not using it. Also, the limit parameter is not utilized in our API request to restrict the number of templates on a single page. Consequently, by default, 25 templates are received on the
Original PR description
Only a few templates are fetched when the user tries to sync all the templates from the `WhatsApp Business Account` form view. Problem: The API request used to fetch all templates incorporates pagination. In the current scenario, the next URL to the subsequent page is included in the response, but we are not using it. Also, the limit parameter is not utilized in our API request to restrict the number of templates on a single page. Consequently, by default, 25 templates are received on the first page. As a result, only templates received on the first page are being created or updated(i.e. 25). Solution: The limit to fetch 200 templates on a single page is added to obtain 200 templates in the first request. However, if there are more than 200 templates, the remaining ones will be fetched from the next page. This process will continue in a loop until all templates are received. Task-3903321 Forward-Port-Of: odoo/enterprise#62460
`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast', 'project_timesheet_forecast_sale'}` Before this Commit: The Graph view was not adaptable to the use of widgets, leading to issues with the representation of time. Specifically, hours were shown as float values in the graph view. For example, 5 hours and 30 minutes were displayed as 5.50 instead of the more intuitive hh:mm format. Although widgets like "float_time" or "timesheet_uom" were available to format these
Original PR description
`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast', 'project_timesheet_forecast_sale'}` Before this Commit: The Graph view was not adaptable to the use of widgets, leading to…
`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast',
'project_timesheet_forecast_sale'}`
Before this Commit:
The Graph view was not adaptable to the use of widgets, leading to issues with
the representation of time. Specifically, hours were shown as float values in
the graph view. For example, 5 hours and 30 minutes were displayed as 5.50
instead of the more intuitive hh:mm format. Although widgets like "float_time"
or "timesheet_uom" were available to format these values, they were ineffective
in the Graph view due to the architecture parser's limitations. This caused
confusion for users trying to interpret the time accurately.
After this Commit:
The Graph view is now adaptable to the use of widgets. This means that when a widget is applied to format a field's value, the value will be displayed in the specified format. For example, hours can now be shown in the hh:mm format instead of as a float.
Widget `timesheet_uom` is used at places where the module is related/depended
on `hr_timesheet` otherwise `float_time`.
This improvement also ensures that the formatted values are reflected in the Y-axis (Ticks/Intervals) of the Graph view, enhancing the user's ability to interpret the data accurately.
Community PR: https://github.com/odoo/odoo/pull/164280
Task-3861721
Forward-Port-Of: odoo/enterprise#67064
Forward-Port-Of: odoo/enterprise#66050Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the pack
Original PR description
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add…
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the package needs to be splitted, the target_weight is not being converted whereas the total_weight is.(check link at the bottom for details) Also in shipping rate request for sendcloud `max_weight` was sent in kilograms with `unit` being 'gram'. After this commit: `max_weight` is converted into grams before adding to the shipping rate request. split shipping code: https://github.com/odoo/enterprise/blob/d3b39fe78bc0ae366d32e80e325e89d2a4bb353c/delivery_sendcloud/models/sendcloud_service.py#L160-L162 opw-4035569 Forward-Port-Of: odoo/enterprise#66594
Previously, creating a new spreadsheet triggered two notifications: one shown manually using the notification service and another from the action response. This PR fixes the issue by removing the notification displayed via the notification service. Since PR [1], calling `action_open_new_spreadsheet` sends a notification in the response with all the necessary data. Therefore, we don't have to manually display the notification using the notification service. [1] https://github.com/odoo/en
Original PR description
Previously, creating a new spreadsheet triggered two notifications: one shown manually using the notification service and another from the action response. This PR fixes the issue by removing the notification displayed via the notification service. Since PR [1], calling `action_open_new_spreadsheet` sends a notification in the response with all the necessary data. Therefore, we don't have to manually display the notification using the notification service. [1] https://github.com/odoo/enterprise/pull/65397 Task: 4039997 Forward-Port-Of: odoo/enterprise#66922