Wednesday, October 23, 2024
8 changes · 17.0
Resolved issues and error corrections
This update ensures that the country setting is correctly applied within account reporting filters. Previously, a constraint was added that required the country ID to be set when using the 'country' availability condition. This change prioritizes setting the country before the availability condition, ensuring accurate reporting results.
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643
This update fixes an issue where a distracting notification appeared when adding tags to the sign document. It also addressed a problem with the field size increasing with multiple tags, now maintaining a consistent size. This enhancement provides a cleaner and more user-friendly experience for signing documents.
Original PR description
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151
This update fixes a confusing error message related to timesheet lock dates. Previously, the message used a fixed date format, causing confusion for users with different language settings. Now, the message dynamically adapts to the user's preferred date format, ensuring clarity and consistency.
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#70405
This update resolves an issue where users would receive a technical error instead of a clear message when creating a Sendcloud shipment without selecting a pickup point. The fix ensures a user-friendly error message is displayed, guiding users to select a pickup location for their shipment.
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362
This update significantly speeds up the process of retrieving related documents for large projects. By using a more efficient database query, the system now processes document lookups 2.45 times faster, particularly when dealing with projects containing a massive number of tasks. This improves overall performance and responsiveness.
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72468
This update resolves an issue where location scans weren't being properly recognized during internal transfers when a product was manually added instead of scanned. The fix ensures that the system correctly identifies and utilizes the scanned location, improving the accuracy of internal transfer processes. This enhancement streamlines operations and reduces potential errors.
Original PR description
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header…
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header propose to scan a product - Do not scan the product by click on `+ ADD PRODUCT` - Add 1 unit of your favorite product > The header propose to scan a product or a destination location - Scan the location you had set #### > The location scan is ignored ### Cause of the issue: During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions: https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination. opw-4201489
This update enhances the account synchronization process by allowing users to reauthorize only the specific accounts needed for their journals. Previously, the system incorrectly triggered full reauthorizations, leading to inefficiencies. This fix ensures accurate and streamlined transaction updates.
Original PR description
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399
This update corrects typographical mistakes found in the planning module, specifically fixing errors in field labels and text strings related to task assignments. These corrections improve the accuracy and professionalism of the user interface.
Original PR description
**Before this commit:** The `date_assign` field string contained a minor typographical error in the `project.task` **Group By**. **After this commit:** The typographical error in the 'Group by' has been corrected. Additional issues related to 'assignment' in the codebase were also addressed by fixing the `date_assign` field string. community: https://github.com/odoo/odoo/pull/183760