Daily updates from Odoo
Wednesday, October 16, 2024
7 changes · 17.0
Enhancements to existing features
The system now alerts users when deferred expense date ranges are abnormal (e.g., spanning an uneven number of months), which could result in incorrect deferral amounts. A warning banner and yellow highlighting help users identify and correct these date entry errors before creating deferrals.
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none
The Odoo Amazon connector has been enhanced to make it easier for businesses and developers to customize and build on top of the module. Hooks and tweaks have been added to the Amazon account, offer, and order recovery features, allowing for better extensibility without modifying the core module directly.
Original PR description
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it
Resolved issues and error corrections
This fix improves the robustness of the Spanish Profit and Loss report by using stricter date range calculations. Previously, if an account was incorrectly configured with the wrong type, the report could display incorrect historical balances. The fix ensures the report handles such misconfigurations more gracefully without requiring immediate account corrections.
Original PR description
Before this fix, when a P&L account was wrongly configured with a Balance Sheet type, the 'normal' date_scope set on the P&L expressions made it so that the balance of this account was computed on the whole accounting history. Of course, the most proper fix in that case is to fix the account type, but using strict_range as the date_scope will just make the report a little more robust. This is a partial backport of what was done in https://github.com/odoo/enterprise/commit/6e607e662dd2ae3ee5e3616bded11b62332ac2f9 for 18.0 Forward-Port-Of: odoo/enterprise#71578
This update resolves an error that occurred when users tried to filter subscriptions by customer or salesperson in the subscription dashboard. The fix corrects the underlying field references used for filtering, allowing users to successfully apply these filters without encountering system errors.
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204This fix improves the responsiveness of shared spreadsheets by processing updates immediately instead of waiting for server confirmation through the websocket. Users will now see their changes reflected faster, and the system is more reliable if the connection drops while they're the only person editing the spreadsheet.
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#71782
This fix corrects how shift end times are calculated when employees have working calendars with breaks. Previously, the system would simply add the shift duration to the start time without accounting for lunch breaks or other non-working intervals, resulting in incorrect end times. Now the scheduling system properly considers the employee's working calendar and break times when calculating shift durations.
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#63002
Fixed an issue in the Argentine VAT report that was causing the system to slow down or crash when displaying large numbers of records (over 6,000 lines). The fix limits the number of records shown in the web interface while still allowing the full dataset to be exported to Excel or PDF files.
Original PR description
ticket 80761