Wednesday, July 24, 2024
8 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where updating assets across multiple companies would not work correctly. The system previously assumed all assets being updated belonged to the same company. This update ensures that businesses managing assets across multiple company entities can now update them without errors.
Original PR description
Currently it is assumed that all assets we write on belong to the same company. (Any exceptions to this are probably rare in practice.) This commit ensures that writing on assets with different companies works correctly. (no task) Forward-Port-Of: odoo/enterprise#65795
This update fixes a technical error that prevented users from using the Comparison filter in the Intrastat report. When comparing intrastat data across different dates, the system was generating an invalid database query. The fix adds proper formatting to the query structure and also removes duplicate lines that appeared when using the comparison feature, ensuring accurate reporting.
Original PR description
Steps to reproduce - Display the intrastat report with at least one line - Create a european company - Install intrastat - Create and post an invoice to partner from another european country - Open the intrastat report - Deactivate the "Grouped" filter in the Options - Activate the Comparison filter (with any other date) => Traceback stating that the query has syntax error Cause of the issue: Missing parentheses between the different sections of the UNION ALL statement. task-4017165 Forward-Port-Of: odoo/enterprise#65720
This update fixes two display problems in the timesheet grid: mobile views now properly align when grouping by multiple fields, and the system prevents users from entering numbers larger than 6 digits to avoid overlapping cells. These fixes improve the user experience when working with timesheets on mobile devices and prevent data entry errors.
Original PR description
task-3373525
Portal users can now edit the customer field when adding new subtasks in the task form. Previously, the customer column was incorrectly hidden when creating new subtasks, even though it became editable after saving. This fix removes an unnecessary condition that was preventing field visibility during initial creation.
Original PR description
Steps: Login as portal, and to to a task form, page sub-tasks. Make Customer column visible. Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The field is invisible if `allow_billable` and `is_fsm` are False. A child task inherits both from its parent, but this one hasn't been created yet. Solution: In this case, the condition is not needed. If we create the child and he has both fields to False, it means its parent too. Yet the `partner_id` column is invisible if it is the case. So the solution is simple: remove the condition. related: https://github.com/odoo/odoo/pull/174323 task-3713729
This fix resolves an issue where starting a timer on a helpdesk ticket would create a new time entry without properly linking it back to the original ticket. Users will now see their timer correctly associated with the ticket they're working on, ensuring accurate time tracking for helpdesk tasks.
Original PR description
Steps: - Install helpdesk_timesheet - In Kanban View > Start the timer of a ticket Issue: - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But for the tickets , if we start a timer, the ticket_id is not set in the timer header with in the new ticket. Cause: - Due to the condition given in the `action_start_new_timesheet_timer`, there is no helpdesk_ticket_id mentioned in that function. Fix: - By extending the `_get_new_timesheet_timer_vals` to the helpdesk_timesheet module to gave helpdesk_ticket_id the issue will be solved. task-3970176
This fix resolves an issue where cancelling UPS shipments with multiple labels would fail with a "Shipment not found" error. The system was incorrectly sending all tracking references instead of just the first one when requesting cancellation from UPS. Now it correctly sends only the first package's tracking reference, allowing multi-label shipments to be cancelled successfully.
Original PR description
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as ShipmentIdentificationNumber in cancel request. Reference ups documentation: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment Methods > Shipment Methods > Void Shipment opw-3974794 Forward-Port-Of: odoo/enterprise#67158
This fix resolves an issue where the Profit and Loss report would display no data when users applied both analytic accounting and horizontal product grouping filters simultaneously. The problem occurred because analytic data filtering was losing important transaction details needed for product-level reporting. The fix ensures that when analytic data is applied, it retains all necessary transaction information from the original invoices so both filtering options work together correctly.
Original PR description
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example…
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the analytic groupby, it creates a shadowing of the move lines based on the analytic lines. This shadowing loses most of the data of the move lines, which can therefore no longer be of use to create more advanced filters. Proposed solution: When doing the shadowing, if the account.analytic.line does not have the column present in the account.move.line, then takes the value of the related move line, instead of setting the value to NULL as it was done before. opw-4048157 Forward-Port-Of: odoo/enterprise#66980
This fix resolves an issue where users would see "Record does not exist or has been deleted" errors when accessing the History channel after deduplication rules are removed or modules are uninstalled. The system now properly cleans up associated messages when deduplication records are deleted, preventing broken references.
Original PR description
Steps to reproduce: ------------------- - Install `data_merge` and `CRM` module - Go to CRM and create 2 opportunities with same name - Activate debug mode and go to `Scheduled Actions` - Run `Data Merge: Find Duplicate Records` action - Go to Discuss and click on `History` channel Issue: ------ Error: `Record does not exist or has been deleted.`. Cause: ------ When uninstalling a module that have a model that is used as `res_model_id` in a `Deduplication Model`, we do not remove message the message linked to the record deleted. Therefore, when opening history channel, we try to access messages linked to records that might have been deleted. Solution: --------- When removing `Deduplication Model`, also remove the messages linked to the record. opw-3906945 Forward-Port-Of: odoo/enterprise#64906