Friday, December 15, 2023
16 changes · 17.0
Resolved issues and error corrections
This update addresses a significant delay in account synchronization, which previously could take up to 20 minutes. The change introduces a new process that fetches and displays the first 100 transactions manually, then uses a background cron job to asynchronously check for more transactions, significantly reducing import times.
Original PR description
Cron_trigger on saas can take up to 15-20min to start as there is only one thread responsible for waking up cron for thousands of databases. Hence the async fetch we did in v17 is not really good in practice (clicking on manual fetch and triggering a cron_trigger might take 20 mins and import 0 transactions). Now we will, on manual import, fetch the first 100 transactions (by date), process them and show them to the user. Then, a cron will asyncronously check if other transactions have to be imported. task-3613030
This fix resolves a system error that occurred when manufacturing orders with tracked components had their stock movements merged. When moves were consolidated, orphaned quality checks remained in the system, causing calculation errors. The fix automatically removes quality checks when their associated stock movements are deleted, preventing the error and ensuring smooth manufacturing operations.
Original PR description
Steps to reproduce the bug: - Create a storable product “C1” tracked by lot - Create a storable product “P1” with BoM: - Quantity: 3 - component: - 1 unit of C1 - in another line 2 units of C1 -…
Steps to reproduce the bug:
- Create a storable product “C1” tracked by lot
- Create a storable product “P1” with BoM:
- Quantity: 3
- component:
- 1 unit of C1
- in another line 2 units of C1
- Create a Mo and use the P1 BoM
- Confirm the MO
- Two quality check of “Register consumed materials” type is created because C1 is tracked
- Try to add one line of C1 with 3 units
- The 3 “stock.move” is merged into the first move
- Try to set the qty producing of P1 to 2
Problem:
A traceback is triggered in `_float_check_precision`:
“assert precision_rounding is None or precision_rounding > 0,\ AssertionError: precision_rounding must be positive, got 0.0”
When the moves are merged into the first one, the other moves are cancelled but their quality checks persist.
So when we change the qty producing, we start the workorder and the component quantity is updated: https://github.com/odoo/enterprise/blob/1d99f3005f96672fd863541d50e5f81229365c32/mrp_workorder/models/mrp_workorder.py#L100-L102
So, we access the move, but since the move was removed, the rounding value is set to 0. Consequently, when float_round is called, an error is raised:
https://github.com/odoo/enterprise/blob/1a6abc731071f39e22693f0c1d54889e3ffdc5ff/mrp_workorder/models/quality.py#L441
https://github.com/odoo/enterprise/blob/1a6abc731071f39e22693f0c1d54889e3ffdc5ff/mrp_workorder/models/quality.py#L445
opw-3484016
Forward-Port-Of: odoo/enterprise#50772
Forward-Port-Of: odoo/enterprise#50688This fix resolves an error that occurred when trying to view status updates for closed subscription-based projects with analytical accounts. Users can now successfully click the update button on closed invoiced subscriptions without encountering system errors, improving the reliability of project management workflows.
Original PR description
invoiced subscription Steps to reproduce: - Enable Analytical Account - Create a billable project with the Analytical Account selected - Make an SO of a subscription, with the AA selected - Invoice - Close the subscription - Go to the project and click on the update Issues: Traceback is shown opw-3566915 Forward-Port-Of: odoo/enterprise#51888
This update modernizes the financial report structure for three localization modules (Pakistan, Portugal, and Sweden) to use the latest report formatting introduced in version 15.1. The reports are being converted to use a more efficient XML structure that simplifies how report lines are organized and displayed, improving maintainability and consistency across all localization modules.
Original PR description
xx = pk,pt,se Problem --------- In 15.1, the financial reports where upgraded to a new version where we can directly indent children line inside parents. Some reports are missing that upgrade. Objective --------- Those reports should be converted. Solution --------- Apply the new formatting of the report in the XML definition using the children_ids and line_ids tags. Remove the parent_id and financial_report_id that are now unnecessary. Target is 16.0 because a refactoring of account reports occurred in 16.0. The only version that will miss the upgrade is saas-15.2. task-3508362 Forward-Port-Of: odoo/enterprise#52506
A bug in the accounting reports module prevented users from clicking certain report actions. The issue occurred when a new column feature was added but one method call wasn't updated to include the required parameter. This fix adds default values to the parameters, ensuring all report actions work correctly.
Original PR description
When doing the fw-port of adding a 'Not Started' column [1] to version 17.0 [2], we added the possibility to audit that column as well. However in doing so, adding a new parameter `filter_not_started` to the `_get_domain` method, we forgot to adapt one method call to include that paramater, causing clicking the caret action in the report to fail. In order to fix the issue and simplify things, the parameters `filter_already_generated` and `filter_not_started` get a default value of `False` now, and the method calls are adapted accordingly. _Bug reported by RIGR_ [1] 563404395c96650b871e293509af77acc811a7ff [2] b3eaaa55b4550f1fefbd6dd472d9e8b8c4d21384
This update fixes the Norwegian Balance Sheet report to ensure it balances correctly by adding missing earnings lines and properly categorizing year-end transfer accounts. The Balance Sheet now accurately reflects Previous Year Earnings and Current Year Earnings under Equity, while transfer accounts that handle year-end account closures are correctly moved from the Profit and Loss report to the Balance Sheet where they belong.
Original PR description
The Balance Sheet was missing report lines specifically for Previous Year Earnings and Current Year Earnings. This commit creates two new report lines under Equity to represent them. In addition, the transfer accounts 88 and 89 that are for setting the Income / Expense accounts to zero at year end are now referenced in the Balance Sheet rather than in the Profit and Loss. They should not affect the Profit and Loss since they should normally only be used in the FY closing entry. Finally, account 835 Tax Cost was not referenced in the Profit and Loss, so we added it. This ensures that the Balance Sheet is balanced, according to the test in https://github.com/odoo/enterprise/pull/36838. taskid: 3060790 Forward-Port-Of: odoo/enterprise#52157
This fix corrects how subscription renewal payments are handled when customers make partial payments. Previously, a payment token was saved even when only a partial payment was received, causing the system to incorrectly charge the full amount later. Now the token is only saved when the subscription is fully paid, preventing duplicate or incorrect charges.
Original PR description
Before this commit, when a payment link was used to partially pay a renewal subscription in order to confirm it, a token was set at the confirmation of the renewal. The consequence of this is that we receive a partial payment and then the remaining amount. We want to save the token only if the subscription is fully paid. After this commit, when confirming a renewal subscription, the token is only saved if the sum of partial payments equal the total amount of the subscription. This way the invoice cron won't charge the total amount on the token. Ticket-id: 3499685 Forward-Port-Of: odoo/enterprise#52634 Forward-Port-Of: odoo/enterprise#52554
Fixed an issue where the browser's back button required two clicks instead of one when navigating between applications from the home menu. The fix ensures that navigation state changes are processed together, creating a single browser history entry instead of two, allowing users to navigate back to their previous application with a single back button click.
Original PR description
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id and the second to apply the action associated with the menu. These two pushStates are not in the same setTimeout, which causes two changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
Forward-Port-Of: odoo/enterprise#52683This fix corrects a data upgrade problem in the Austrian accounting reports module where removed field entries were not being properly cleared from the database during updates. This was causing errors when viewing profit and loss reports and duplicate expressions appearing in balance sheet configurations. The fix ensures that when fields are removed from the system configuration, they are properly cleaned up rather than left behind as orphaned data.
Original PR description
In PR #47198 some field entries were removed from some expression records in the XML. This leads to problem with upgrade since only "positive changes" (values that occur in the XML) are written to…
In PR #47198 some field entries were removed from some expression records in the XML.
This leads to problem with upgrade since only "positive changes" (values that occur in the XML) are written to the DB. Values that are absent are not set to False or to their default. This was corrected in this commit.
A somewhat special case are the 'domain_formula' fields; they create expressions. Setting their value to False explictly unlinks the associated expressions.
Reproduce (leftover subformula causing traceback in P&L)
1. Check out commit fc8a6c8344f95b20947188f341b16a648cdd1433 (last commit before PR #47198)
2. Start and install l10n_at_reports
4. Check out commit before this commit
5. Start with -u l10n_at_reports
6. AT profit & loss
7. Traceback
Reproduce (for domain_formula)
1. Check out commit fc8a6c8344f95b20947188f341b16a648cdd1433 (last commit before PR #47198)
2. Start and install l10n_at_reports
3. Check Accounting -> Configuration -> Accounting Reports
-> Bilanzdarstellung nach § 224 UGB (AT)
-> 4. sonstige Forderungen und Vermögensgegenstände
4. Check out commit before this commit
5. Start with -u l10n_at_reports
6. Check again: Accounting -> Configuration -> Accounting Reports
-> Bilanzdarstellung nach § 224 UGB (AT)
-> 4. sonstige Forderungen und Vermögensgegenstände
There are 2 expressions now but there should be just 1 (the one from step 3 should be gone now)
Forward-Port-Of: odoo/enterprise#52709This update fixes issues that occurred when users tried to audit financial report cells with no data. Previously, the system would display confusing "undefined" text and crash when attempting to audit certain manual values. The fix ensures the audit feature gracefully handles empty cells without errors or misleading messages.
Original PR description
Currently, if one tries to audit a cell that has no lines to audit two things can break: - auditaction.help is displayed even if it's undefined, resulting in `undefined` text being displayed - certain manual values traceback because fetchone returns None and we trying to access the contents of it This commit fixes it by: - extending external domain with record_ids only if we get some when fetching - only showing no content help if there is one While external domain for auditing could be fixed back to 16.0, it doesn't seem to be necessary: we start allowing auditing cells with no lines only from saas-16.4 and we have the first report with various formats of external values in 17.0.
This fix removes an artificial limit that was preventing the shop floor from displaying more than 80 manufacturing orders. Now all confirmed manufacturing orders will be visible in the shop floor view, allowing production teams to see their complete workload without missing orders.
Original PR description
**To reproduce:** - Create and confirm 81 MOs - Open the shop floor **Current behavior:** 80 MOs shown due to a limit on the amount fetched from the backend. **Expected behavior after this PR is merged:** 81 MOs shown as the limit is increased to a maximal amount. opw-3605494 Forward-Port-Of: odoo/enterprise#52777
This fix corrects an issue where off-balance accounts were being incorrectly included in account predictions during invoice and bill imports. By excluding these accounts from predictions, the system now properly validates accounts without triggering errors, ensuring smoother invoice processing.
Original PR description
Currently, off balance accounts are included in the prediction, even though they should be excluded to avoid errors in `_check_off_balance` when importing an invoice/bill. opw-3628030 Forward-Port-Of: odoo/enterprise#52747 Forward-Port-Of: odoo/enterprise#52704
Projects with associated documents were incorrectly displayed in green in the task portal list view when grouped by project, creating confusion about project status. This fix removes the unnecessary green highlighting so projects are displayed with appropriate visual indicators based on their actual status rather than document presence.
Original PR description
Steps to reproduce: -------- - Open task portal list view - Group by project - projects for which there are documents is displayed in green Issue: ------- - In the tasks portal list view, projects with associated documents are displayed in green when tasks are grouped by project. This causes confusion, as the green highlighting implies a need for further attention, even when the projects are not in a critical state. Cause: ------ - The current code logic for highlighting projects in green is solely based on their grouping. Solution: ---- - This commit modifies the list view logic. Projects with documents will no longer be displayed in green. task-3545942 Forward-Port-Of: odoo/enterprise#52502 Forward-Port-Of: odoo/enterprise#52227
Fixed a technical error that occurred when users tried to restore a deleted article from the trash in the Knowledge editor. Previously, clicking "Restore from Trash" would cause the application to crash. Now the article is properly restored and the editor view refreshes to show the updated article without the deletion warning.
Original PR description
When the user clicks on the option "Restore from Trash" option from the "more options" panel of the Knowledge editor, the system calls the `action_unarchive_article` action and execute the action…
When the user clicks on the option "Restore from Trash" option from the "more options" panel of the Knowledge editor, the system calls the `action_unarchive_article` action and execute the action returned. Currently the action `action_unarchive_article` does not return any action, causing the action service to receive `undefined` and subsequently trigger an error. This commit will address this issue by reloading the view instead of executing the action returned by `action_unarchive_article`. Steps to reproduce the issue: 1. Open an article in the editor 2. Click on "Delete" button from the "more options" menu 3. Click on "Open the Trash" 4. Click on the article you deleted 5. Click on "Restore from Trash" from the "more options" menu => TypeError: `action` is undefined TO BE: The editor is expected to reload the record and update the view. Additionally, the banner warning users about the imminent deletion of the article should be removed upon restoration. task-3619503 Forward-Port-Of: odoo/enterprise#51856
A bug in the Belgian POS blackbox module was preventing users from being created properly due to an error in the logging process. This fix resolves the issue so that user creation now works as expected.
Original PR description
When attempting to create a user using the pos_blackbox_be module, an error arises due to an issue in the log creation process. This commit ensures that the creation process is now functioning correctly.
Fixed an issue where opening the Shop Floor from a work order would fail because the system wasn't properly selecting the correct work center. The fix ensures that when users open the Shop Floor, the work center associated with their current work order is automatically selected, preventing errors and improving workflow efficiency.
Original PR description
Opening the Shop Floor from a workorder failed because the workcenter list may be empty (local storage not initialised) or not containing the workorder's workcenter. This commit ensures the workcenter related to the active workorder is selected at the shop floor opening