Daily updates from Odoo
Wednesday, June 19, 2024
9 changes · 17.0
Enhancements to existing features
Users can now select which bank journal to use when importing bank statements through Document Actions. This improvement makes it easier for users importing CSV files, as the system previously only worked optimally with CODA files. If no journal is selected, the import defaults to the first available journal.
Original PR description
[IMP] documents_account: Add selection of journal in Document Action 'import bank statement' Backport of: https://github.com/odoo/enterprise/pull/46482/commits/d2a95d7ffa3ef2976172ed17eaf93056ea0f8c6c For now we didn't chose the bank journal because we assume that only coda file where push like this, and in the coda file we can find in which journal to send it. But Coda is limited to BE and lot of user import CSV file for bank. Add the selection of the journal (not mandatory) for Document action, and inject CSV in the journal selected. If no journal selected inject the CSV in the first one of the list. If it's a coda file, keep as now and don't take care of the journal selected. Task-3932055
The GST return report generation has been significantly optimized to handle large volumes of transaction data much faster. By improving how the system retrieves and processes accounting and point-of-sale records, the report now completes in approximately 10% of the previous time—reducing processing time from 2800 seconds to 300 seconds for typical datasets. This improvement directly benefits users who need to generate GST compliance reports without experiencing long system delays.
Original PR description
Issue --> With a large number of `account.move.line` and `pos.order.line` records, methods `_get_tax_details`, `_get_gstr1_hsn_json` and `_set_details_pos_lines` do not perform well. Solution --> In…
Issue --> With a large number of `account.move.line` and `pos.order.line` records, methods `_get_tax_details`, `_get_gstr1_hsn_json` and `_set_details_pos_lines` do not perform well. Solution --> In `_get_tax_details` --> Replace the journal items recordset with a set of ids to do deletions. Move the fetch to when it is actually needed. In `_get_gstr_hsn_json` --> Prefetch the l10n_in_code values on `uom.uom` records that are used in the for loop. This optimization prevents additional hits to the backend. In `_set_details_pos_lines` --> Fetch `product.product` records and all the `uom.uom` records before the for loop to prevent additional hits to the backend when trying to fetch `product_id.type`, `product_id.l10n_in_hsn_code` and `product_uom_id.l10n_in_code` Benchmark --> For about 110k journal items and 95k pos order lines, the current implementation takes about 2800 seconds to finish computation. After the fix, the process takes about 300 seconds to finish. opw-3895401
Resolved issues and error corrections
Fixed an issue where retweeted messages were truncated in the system, even though Twitter displays them in full. The fix retrieves and displays the complete text of the original tweet instead of the limited version provided by Twitter's API, ensuring users see the entire message content.
Original PR description
This commit fixes an issue where the retweeted message would only display a part of the retweeted message while twitter displays it in full. This is a limitation of the Twitter API which only sends a limited part of the tweet. To fix this, we are setting the message value to the text of the referenced tweet. task-3653108 Forward-Port-Of: odoo/enterprise#59335 Forward-Port-Of: odoo/enterprise#55642
This fix ensures that sign request documents display in the customer's preferred language instead of always showing in English. Previously, when a customer with a non-English language preference (like Finnish) opened a sign request, all text and placeholders appeared in English, and date fields didn't auto-fill correctly. Now the system respects the partner's language settings when displaying sign items.
Original PR description
Issue:
======
Sign items are in english in sign
Steps to reproduce the issue:
=============================
- Create a user with Finnish language (or any other)
- Create a sign request and add a date sign item
- Send it to the Finnish customer
- Open the link
- The date doesn't fill automatically and the placeholders are all in english
Origin of the issue:
====================
We don't use the language of the partner when fetching the sign items. The date field doesn't fill automatically is a consequence of this because we check `type.name === _t("Date")` but we have `type.name` in english and not the lang of the partner so we don't go into the condition to add the automatic fill for the date field here [1].
[1]: https://github.com/odoo/enterprise/blob/15.0/sign/static/src/js/sign_common.js#L1646
opw-3871779
Forward-Port-Of: odoo/enterprise#64824
Forward-Port-Of: odoo/enterprise#61744This fix prevents system upgrade failures when users have previously modified appointment payment products. By marking the product data as non-updatable, the system will no longer attempt to change the product type during upgrades, which was causing errors. This ensures smooth upgrades for businesses using the appointment and payment features together.
Original PR description
During an upgrade, if the user has used the record and modified its type, it will [trigger](https://github.com/odoo/odoo/blob/17.0/addons/stock/models/product.py#L890) the `UserError`: `You can not change the type of a product that was already used.`
Fixed an issue in the bank reconciliation widget where currency decimal formatting would fail if the currency wasn't loaded in the system. The fix adds a fallback value that defaults to 2 decimal places, ensuring the widget displays amounts correctly even when currency information is temporarily unavailable.
Original PR description
The aim of this commit is giving a fallback value when we need digits' currency and that we don't have this currency loaded in the js session. This commit is almost backport of what we have done in this commit [1]. The only difference is the default value for the toFixed set to 2. task-3959277 [1]: https://github.com/odoo/enterprise/commit/6a3623c168f3bdf32b9530071e21c014dd19ea07 Forward-Port-Of: odoo/enterprise#63913
Fixed an issue where error messages in the account consolidation view were displaying raw HTML code instead of formatted text. When users clicked on unmapped accounts, they would see HTML tags as plain text. This update ensures error messages display properly formatted and readable to users.
Original PR description
- When clicking on an account that hasn't been mapped, the help message shown in the tree view contained HTML code (tags explicitly shown). - We fix that by directly executing the action returned by the server, which then gets the proper markup and properly interprets the returned HTML code. task: 3715833 Forward-Port-Of: odoo/enterprise#63376
This fix resolves an issue where spreadsheet tests were failing because the spreadsheet viewport had zero size, making cells invisible and unclickable. The fix moves styling rules from the documents_spreadsheet module to the spreadsheet_edition module to ensure the spreadsheet properly fills available space and displays correctly during testing.
Original PR description
… module Steps to reproduces: - install module `test_spreadsheet_edition` - run js tests => some tests fail. The reason is we are trying to click or hover some cells in those tests. But the spreadsheet (its viewport) size is 0. The cells are not visible. This commit moves some scss from module `documents_spreadsheet` to `spreadsheet_edition`. This css ensures the spreadsheet takes all the available space and be sized properly. runbot errors 65775, 65774, 65773, 65772
This fix resolves an issue where payroll batch status was not being set to confirmed when regenerating payslips for the same employees after reverting to draft. Now when payslips are regenerated, the batch will correctly transition to confirmed status, ensuring accurate tracking of payroll processing workflow.
Original PR description
-steps to reproduce: create a batch, generate the payslips, set the batch back to draft, regenerate the payslips (with the same employees). -what is the bug: the state of the batch is not set to 'confirmed' after the second generation of payslips. -expected behaviour: the batch should be in confirmed state. -fix: if regenerating with the same employees, nothing is actually done, it should at least set the batch in confirmed state. Task: 3975654