Wednesday, July 24, 2024
18 changes · 17.0
Enhancements to existing features
Shop Floor can now check whether a workorder has operation notes without loading and processing the full note each time. This reduces unnecessary work in the background and should improve responsiveness when viewing workorders.
Original PR description
This commit adds a new non-stored compute field 'has_operation_note' to the mrp.workorder model so we can avoid unnecessarily fetching the 'operation_note' field. This change is required to improve the performance of Shop Floor as we don't want to fetch and sanitize the operation note for every workorder yet we still have to know if there is one to display the relevant button. See the Enterprise commit for a detailed explanation of the issue: odoo/enterprise@55179d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents users from creating fiscal years on child companies, ensuring fiscal year management is centralized at the parent company level. This improves data consistency and prevents configuration errors in multi-company setups.
Original PR description
Description of the issue this commit addresses: We do not want the user to be able to create fiscal years on child companies. --- Desired behavior after this commit is merged: A new check in fiscal years raises an error when the user tries to create a fiscal year from a child company. --- no task-feedback Forward-Port-Of: odoo/enterprise#67121
This update includes two important fixes to the accounting system: first, it resolves an issue where writing changes to assets across multiple companies now works correctly, and second, it prevents users from accidentally creating fiscal years on child company branches, which should only be managed at the parent company level. These changes improve data integrity and prevent configuration errors.
Resolved issues and error corrections
This update brings the spreadsheet component to its latest maintenance version and fixes issues that could affect day-to-day spreadsheet use. Conditional formatting errors are now handled more safely, and the grid no longer incorrectly shows cell A1 as hovered by default.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/679a547bc [REL] 17.0.32 Task: 0 https://github.com/odoo/o-spreadsheet/commit/e455ac085 [FIX] CF: Ignore errors thrown during CF evaluation Task: 4036921 https://github.com/odoo/o-spreadsheet/commit/e40406548 [FIX] grid_overlay: A1 is hovered by default Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Scanning a package type in the Barcode app now correctly fills it into the package wizard. This makes the shipping weight field visible again, allowing connected IoT scales to provide package weights during delivery preparation.
Original PR description
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight…
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale. Steps to reproduce: 1. Enable packaging configuration. 2. Create a sales order and confirm it; this will generate a delivery. 3. Find that delivery in the ‘Barcode’ app. 4. Add/scan the product. 5. Scan the package type. Current behavior before PR: Following the above steps, when the package type is scanned using the barcode, the scanned package type is not populated in the opened package wizard. Consequently, the shipping weight field is not visible, preventing the retrieval of the weight from the IoT scale. Please refer to the screen recording before the PR: https://github.com/user-attachments/assets/e4764005-6758-4f80-a189-e27e8897f853 Desired behavior after PR is merged: After merging this PR, when the package type is scanned using the barcode, the scanned package type will be correctly populated in the opened wizard. As a result, the shipping weight will be visible, and it will be able to retrieve the scale weight from IoT. Please refer to the screen recording after the PR: https://github.com/user-attachments/assets/f408ee60-2495-48a5-96ea-3ced502c85dc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now creates separate down payment lines for each distinct tax combination when importing a sales order. This keeps tax calculations aligned with the Sales app and prevents incorrect invoice amounts, including negative untaxed totals on full down payments.
Original PR description
When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up…
When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice. Steps to reproduce: ------------------- * Create 2 taxes, A and B with 5% and 10% * Create 2 products, A and B. Assign the 2 taxes to the products * Create a sale order with the 2 products * Open the sale order in PoS and make a downpayment for it > Observation: There is only one downpayment line when it should have 2. Why the fix: ------------ If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value. opw-3999047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how Odoo detects printers and serial devices on Raspberry Pi 5 setups. It prevents extra, unintended devices from appearing in device lists, making IoT hardware selection more reliable for users.
Original PR description
Fixed printer and serial devices detection: both listing more devices than expected. Task: 3947355
WhatsApp no longer accepts captions sent together with audio messages, so this update changes the message flow to send audio first. Any typed text remains in the composer and can be sent after the audio, helping avoid failed WhatsApp audio messages.
Original PR description
Whatsapp API doesn't allow to send captions with audio anymore, therefore we should modify the way we handle captions. After this commit audio will be sent first while text message will stay in a composer, it will only be sent after the audio is sent. task-4007616 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
This change restores the previous handling of the project analytic plan setting so it is not overwritten incorrectly. It helps prevent issues with timesheet accounting data being linked to the wrong automatically generated field.
Original PR description
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817
This fix improves how Sendcloud reads house numbers from customer street addresses. Delivery labels should now better reflect addresses with slashes, dashes, spaces, or letters, reducing the risk of shipping errors.
Original PR description
### Main Issue: When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house…
### Main Issue:
When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect.
It is due to a limited regex when trying to extract the house number from the 'street' field of the partner.
### Main change:
Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats.
### Before:
- Regex Pattern: `([1-9]+\w*)`
- Explanation: This pattern captures one or more digits (not starting with zero) followed by any number of word characters (letters, digits, or underscores).
### After:
- Regex Pattern: `(\d+[-\/]?\d* ?[a-zA-Z]?\d*)(?![a-zA-Z])`
- Explanation: This improved pattern captures a broader range of house number formats, including those with dashes, slashes, spaces, and letters.
### Examples of the Differences:
"Friedrichstr. 13/1"
Before: '13'
After: '13/1'
"Rue du pont 11 A"
Before: '11'
After: '11 A'
"Place Albert 1er 15B"
Before: '1er'
After: '15B'
"123-456 Main Street"
Before: '123'
After: '123-456'
"789 C Oak Avenue"
Before: '789'
After: '789 C'
[opw-4042552](https://www.odoo.com/odoo/project/49/tasks/4042552)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