Daily updates from Odoo
Wednesday, October 16, 2024
10 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 fixes three critical issues in the bank reconciliation report: system crashes from division errors, incorrect display of partially reconciled amounts, and duplicate entries appearing in the report. The fix improves the underlying logic for how the report calculates and displays bank reconciliation data, ensuring users see accurate and complete information without errors.
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589
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
This fix resolves a critical error that occurs when processing invoices in the Point of Sale system for Chilean businesses. The system was looking for an outdated field name, causing the invoice payment process to fail. The fix updates the code to use the correct field name, allowing invoices to be processed smoothly.
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528
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
This update resolves a memory error that occurred when processing large numbers of accounting transactions (170,000+) in Indian localization. The system was trying to load all transaction data into memory at once. The fix optimizes how the system processes these transactions by only loading the relevant Indian records, preventing system crashes during updates.
Original PR description
After applying l10n_uk patch, the l10n_in_transaction_type field is set to compute in a customer database with approximately 170,000 moves. For each move, we need to check if move.country_code ==…
After applying l10n_uk patch, the l10n_in_transaction_type field is set to compute in a customer database with approximately 170,000 moves. For each move, we need to check if move.country_code == "IN". To optimize performance and prevent memory errors, we should fetch only the records where the country code is 'IN' and avoid loading unnecessary data.
[l10n_uk](https://github.com/odoo/odoo/pull/181154/commits/3b1fef4bbb667fb747e1272db7852f1f27263b0e)
```python
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 514, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/migrations/1.1/end-migrate.py", line 7, in migrate
env['account.chart.template'].try_loading('uk', company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 153, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/enterprise/17.0/l10n_ae_corporate_tax_report/models/template_ae.py", line 9, in _load
super()._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 213, in _load
self._load_translations(companies=company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 1326, in _load_translations
translation_importer.save(overwrite=False)
File "/home/odoo/src/odoo/17.0/odoo/tools/translate.py", line 1446, in save
env.flush_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 721, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 717, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6929, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1367, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1340, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4893, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/l10n_in_reports/models/account_move.py", line 23, in _compute_l10n_in_transaction_type
if move.country_code == "IN":
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4893, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6649, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2907, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3795, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3845, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3955, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1113, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
opw-4161124
upg-2056124
```