Daily updates from Odoo
Tuesday, August 13, 2024
6 changes · 17.0
Resolved issues and error corrections
This update fixes the "Add to Dashboard" dialog in the Spreadsheet Dashboard Documents feature by removing an unnecessary external link button. The change simplifies the dialog interface, making it cleaner and more focused on the primary action of adding content to dashboards.
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2)
Fixed a bug in the Indian localization asset module where depreciation validation checks were only running when assets were first created, not when they were updated later. Now these important validation checks will run both at creation and whenever assets are modified, ensuring data integrity throughout the asset lifecycle.
Original PR description
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619
This fix resolves an issue where confirming multiple purchase orders created through the approval workflow would fail with a validation error. The problem occurred because a temporary naming context was being incorrectly carried over when creating shipments, causing duplicate names. The fix ensures this context is properly cleared so shipments receive unique names as expected.
Original PR description
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with…
Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.
Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.
Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154
As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.
Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.
opw-3990816
Forward-Port-Of: odoo/enterprise#66504When users duplicate a rental order, the rental line information was not being preserved, causing the duplicated order to lose its rental status. This fix ensures that rental line details are properly copied when an order is duplicated, so users can confirm the duplicated rental order with all rental information intact.
Original PR description
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of the method being called from the Rental app. Steps to Reproduce on Runbot: 1. Install Rental app 2. View the rental orders in list view 3. Select a rental order with a status and duplicate 4. Observe that duped rental order has no rental_status when you confirm it opw-4055493
This fix prevents the Documents app from crashing when users switch between companies and try to access folders they don't have permission to view. Previously, the app would display an error and require a page refresh. Now it automatically redirects to the default "All Folders" view when a folder becomes inaccessible due to company switching, providing a seamless user experience.
Original PR description
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same…
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url. Steps to reproduce: 1. Install Documents. 2. Have atleast 2 companies. 3. Create a new folder that belongs to the current company. 4. While having this folder selected, change to the 2nd company. Solution: The issue is triggered within the load funcion for the DocumentsSearchModel, since we get the folderId that's in the url, and we also get the list of the folder we have access to, we could filter out if the current folder we are trying to access is within this list before calling toggleCategoryValue, and If it's not we could just call it on `folderId = false;` as default (which is the "All" section of folders). This way we avoid calling `category.values.get(...)` later on for undefined (we don't have access to this folder). opw-3971935
This fix corrects an issue where debit amounts were showing as zero in accounting reports when using analytics grouping. The problem was caused by inverted debit signs in the report calculation logic. Users will now see accurate debit figures that match balance amounts when filtering by debit values in analytics-enabled reports.
Original PR description
To reproduce the issue, on a fresh db with nothing else: 1) Create a new accounting report from srcatch, so that: - it has 2 columns - it has 1 line, with two expressions: - the expression going in…
To reproduce the issue, on a fresh db with nothing else:
1) Create a new accounting report from srcatch, so that:
- it has 2 columns
- it has 1 line, with two expressions:
- the expression going in column 1 is a domain, doing [('debit', '>', 0)]
- the expression going in column 2 is also a domain, doing [('balance', '>', 0)]
- it has analytics groupby enabled
2) Create a vendor bill, with only 1 line of 100€. Assign it an analytic distribution of 100% into some analytic account.
3) Open your report, activate the analytic groupby on the analytic account used in point 2).
====> The column considering the balance shows 100€, while the one considering the debit shows 0. This is wrong; both columns should show 100€.
This is due to the fact the sign of the debit is inverted in the SQL shadowing of the move lines made to handle analytics in the report engine. Instead of 100, it sees -100 here, which does not match the domain.
Forward-Port-Of: odoo/enterprise#67018