Daily updates from Odoo
Tuesday, November 14, 2023
9 changes · 17.0
Resolved issues and error corrections
This fix prevents users from accidentally reducing quantities of service products that have already been marked as delivered in Field Service Management tasks. When a service product is added to a task, its quantity is now locked at the delivered amount, preventing inconsistent behavior and error messages when users try to decrease it.
Original PR description
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products…
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products should not be decreasable - Cause: Service product with the *qty_delivered_method* set as 'manual' are considered as directly delivered so their quantities shouldn't be decreasable once you added quantity. This logic is applied in the __inverse_fsm_quantity_ method in industry_fsm_sale module - Fix: adding a min_quantity key in the catalog _sale_product_catalog_update_sale_order_line_info_ method return dictionary, the value is setted as the sol.qty_delivered. Once this value has been fetched, the kanban_record will include it in the productCatalogData.minimumQuantityOnProduct I'm open to discussion to implement this in the sale_stock module but i don't think the quantity delivered are updated as soon as the quantity is added to the sale order anywhere else than in the industry_fsm_stock module. Also added a small improvement, if the product is already at the delivered/minimum quantity, inputing a quantity below the delivered/minimum one will reload the record to set the quantity to the delivered/minimum. Task-3553140 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves issues with spreadsheet version history when spreadsheets are created from templates. Previously, users would encounter errors when trying to view version history, and the system would lose track of revision information due to mismatches between template data and regular spreadsheet data. The fix ensures that spreadsheet data is properly converted and synchronized when created from templates, and that revision history is correctly maintained and cleaned up.
Original PR description
Task: 3575942
This fix restores proper translations for Belgian accounting reports in Dutch, French, and German languages. The translations were not being applied correctly due to annotation issues that occurred during the review process. This ensures users in Belgium can now see the accounting reports in their preferred language.
Original PR description
After merging the new Belgian accounting reports in 17.0, it seems the translations were not having the right annotions (due to a renaming during the review process) and were thus not applied. Original commit: https://github.com/odoo/enterprise/commit/c76133635bc1542765937116f02bbbd390599106 This commit fixes that such that the Belgian reports are properly translated again in NL, FR and DE. no-task-id
This update fixes an issue where incoming invoices for Chilean operations were not applying the correct default tax. The system now properly adds the default purchase tax when processing incoming emails with invoices, and prioritizes it in the tax sequence to ensure it's applied first.
Original PR description
Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651
This fix resolves an issue where subsidiary companies could not access parent company accounts when performing bank reconciliation. Users working with subsidiary branches can now properly select accounts from the parent company in the reconciliation widget, enabling complete financial operations across the company structure.
Original PR description
When having a sub company selected, the accounts from the parent company.ies are not accessible in the reconciliation widget. Steps: - Have a company with one branch (X and X.1) - Create a bank statement line in X.1 - In the manual operations tab of reco widget, try to select another account -> no accounts available opw-3518443 Forward-Port-Of: odoo/enterprise#48368
This update fixes a bug in the Planning module where recurring shifts created on the last day of a month were incorrectly scheduled for earlier dates in subsequent months. For example, a shift starting on January 31st would appear on February 29th instead of the last day of February. The fix ensures all recurring shift occurrences maintain their original day-of-month position, improving scheduling accuracy and reliability.
Original PR description
Steps: In planning, create a shift with date: 31/1/2020 and recurrence each month for 5 months. Expected: For all shifts, the date should be the last day of the month. Issue: From February on, each shift's date is the 29th. Cause: We calculate the next date by adding the recurrence delta to the previous one. In this case: `31/1/2020 + 1 month = 29/2/2020; 29/2/2020 + 1 month = 29/3/2020; etc.` Fix: Calculate the nth next date by adding the recurrence delta, multiplied by n, to the first date. In this case: `31/1/2020 + 1 month = 29/2/2020; 31/1/2020 + 2 month = 31/3/2020; etc.` task-3449851 Forward-Port-Of: odoo/enterprise#50503 Forward-Port-Of: odoo/enterprise#44965
This fix resolves a discrepancy in how helpdesk ticket open hours were being calculated across different reports. The system was using different date references (assignment date vs. close date) in different places, causing the same ticket to show different hours open depending on which report you viewed. This update ensures consistent calculations across all helpdesk reports by using the creation date to close date method, which aligns with Odoo's official documentation.
Original PR description
`_compute_open_hours`() is not defined the same way as the SQL one. `_compute_open_hours` uses `close_date` and SQL view uses `assign_date`. https://www.odoo.com/documentation/16.0/applications/services/helpdesk/overview/reports.html uses difference between create date and close date so we'll use that one. _steps to reproduce:_ - create a helpdesk ticket and close it - compare helpdesk.ticket and helpdesk.ticket.report.analysis _before this commit:_ hours open are different on the two models _after this commit:_ hours open are the same on the two models opw-3562355 Forward-Port-Of: odoo/enterprise#49956
This fix ensures that paused subscriptions are now displayed when viewing a customer's subscription list. Previously, paused subscriptions were hidden from the customer's page, making it difficult to track all subscription statuses. Now customers and support teams can see the complete subscription history including paused ones.
Original PR description
[FIX] sale_subscription : Paused subscription is not visible in contact's page Steps to reproduce: 1- Install Subscriptions and Contacts modules 2- Pause a subscription that is 'In progress' 3- Go to the customer's page and click on the subscription smart button Current behavior before PR: The paused subscription is not shown in the list of subscriptions under a contact Desired behavior after PR is merged: The subscription list for each contact will now show the paused subscription too opw-3571647 Forward-Port-Of: odoo/enterprise#50514 Forward-Port-Of: odoo/enterprise#49732
Fixed an issue in the Barcode app where scanning a tracked product component would create a duplicate line instead of selecting the existing one when no lot number was assigned yet. This fix allows users to properly assign lot numbers to tracked components without manual intervention, improving the efficiency of barcode-based receiving workflows.
Original PR description
When a move line is for a tracked product, if its `qty_done` is equal or greater than its `product_uom_qty`, the line will not be selected when the product will be scanned. It's annoying when this line has no lot yet. How to reproduce: - Create a product with a BoM kit and at least one tracked component (both product should have a barcode of course); - In the Barcode App, create a new receipt; - Scan the product kit and validate -> Before the validation, the kit is decomposed and a line for each component should be created; - Scan the tracked component -> Instead of selecting the existing line, a new one is created. That means the user is not able to set the lot for this line without select it manually. To fix that, the line will be selected even if it has enough `qty_done` only if the product is tracked and there is no lot/serial number. Forward-Port-Of: odoo/enterprise#49608 Forward-Port-Of: odoo/enterprise#49163