Daily updates from Odoo
Saturday, April 20, 2024
11 changes · 17.0
Enhancements to existing features
This update improves the speed of checking unit of measure categories, especially for businesses with large catalogs. By optimizing how the system counts units in a category, processing time is reduced dramatically—from 900ms down to just 15ms for large datasets—resulting in faster system performance and better user experience.
Original PR description
This commit improves the performance of the reference check for large categories of Units of Measure (UoM). After this commit, the number of UoMs in the category is counted using the read_group method instead, resulting in faster performance. ### Benchmark: | Nbr of UoM | Before | After | | ---------: | -----: | ----: | | 0 | 0ms | 0ms | | 1 | 1ms | 1ms | | 30 | 6ms | 3ms | | 200 | 7ms | 2ms | | 18000 | 900ms | 15ms | opw-3775689 Forward-Port-Of: odoo/odoo#157752
Resolved issues and error corrections
Fixed an issue where consolidation reports were always printing in portrait mode, even when the content was too wide to fit properly. The system now automatically detects when a report is too large and switches to landscape mode for better readability and proper formatting of wide financial data.
Original PR description
Before that, the report was always printed in portrait mode. This was due to the fact the consolidation report does not use the options['columns'] key, unlike pretty much every other report. Because of that, the standard code couldn't detect it would be too large for the portrait mode. We fix that by introducing a context key to control that, and forcing it when necessary on the consolidation report. OPW 3850656 Forward-Port-Of: odoo/enterprise#60946 Forward-Port-Of: odoo/enterprise#60637
This update resolves test failures in the appointment scheduling system that were occurring in no-demo mode. The fix adjusts test query counters to match actual system behavior, ensuring automated testing runs smoothly without errors.
Original PR description
Some tests have an additional query, making runbot fail in no-demo mode. This is to investigate but we can already ix tests. Runbot-62058 Runbot-62057 Runbot-62056 Runbot-62055
This fix prevents TaxCloud from recalculating taxes when confirming down payment invoices, which was causing incorrect tax amounts. Down payment taxes are now correctly preserved from when the invoice was created, ensuring the invoice total remains accurate throughout the process.
Original PR description
**Steps to reproduce:** - Install Accounting and Sales - Configure TaxCloud in Accounting settings - Create a SO: * Customer: [US customer] (e.g. Azure Interior) * Product: [any] * Unit Price: [any]…
**Steps to reproduce:** - Install Accounting and Sales - Configure TaxCloud in Accounting settings - Create a SO: * Customer: [US customer] (e.g. Azure Interior) * Product: [any] * Unit Price: [any] (e.g. $ 200.00) * Fiscal Position (Other Info tab): Automatic Tax Mapping (TaxCloud) - Confirm the SO => The taxes will be recomputed with TaxCloud (e.g. $ 20.50 with "Tax 10.250 %") - Create a down payment from SO (via "Create Invoice" button): * Create Invoice: Down payment (percentage) * Down Payment Amount: 50% => The total amount of the down payment is 50% of the total amount of the SO (i.e. $ 110.25) and the computed taxes are the same than the taxes on the SO. - Confirm the down payment **Issue:** Upon confirmation, the taxes are recomputed with TaxCloud and the total amount is not the same anymore. **Cause:** The "Down payment" product has a specific TaxCloud Category and as the taxes are recomputed upon confirmation, the tax amount changes (e.g. from $ 20.50 to $ 0.00). **Solution:** Do not recompute taxes with TaxCloud when confirming a down payment as the taxes should have already been computed correctly when the down payment has been created. opw-3814524 Forward-Port-Of: odoo/enterprise#60722
Fixed a layout issue with blog filters on mobile devices by replacing the broken filter dropdown with a more user-friendly dropdown or side panel (offcanvas) that appears next to the search bar. This improvement makes the mobile experience more consistent with other parts of the website and provides better spacing for easier navigation.
Original PR description
The blogs filters in mobile is breaking the layout. This commit applies a dropdown or an offcanvas instead which is displayed next to searchbar. In this 17.0 fix, the dropdown becomes an offcanvas if we have a sufficient amount of blogs which allows better navigation on mobile and makes it consistent with other website modules. Additionally it adapts the spacing to make it even between the navigation component. The `t-set="_classes"` is not removed in case of potential xpath in production. Same goes for the `container` class on the div at line 9, being overridden by it's t-attf-class counterpart. task-3315921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145547
This update fixes several critical issues with how accounting chart templates are loaded, particularly for localized versions like Nigeria. The fixes ensure that accounts are created before taxes that reference them, and that tax configuration values are properly applied. This resolves problems where certain countries couldn't properly set up their accounting structures.
Original PR description
Several fixes to the chart_template loading, found because to `l10n_ng` not being able properly accounts and taxes. See related PR. 1. **[FIX] account: defer recursive check** This bug is generally…
Several fixes to the chart_template loading, found because to `l10n_ng` not being able properly accounts and taxes.
See related PR.
1. **[FIX] account: defer recursive check**
This bug is generally hidden in normal localizations because the `get_account_account` function reads `account.account-xx.csv` soon enough to create all the needed accounts.
In `l10n_ng` there is no `account.account-ng.csv`, as it relies on the generic_coa. The chart_template's `get_account_tax` function reads `account.tax-ng.csv` before `get_ng_account_account` is called.
The `defer` function should check the account_tax fields and postpone them until the creates are done, but it only checks the "first level" and doesn't check all the way down to `account_tax.repartition_line_ids.account_id`.
By making `defer` recursive we are able to properly postpone the creation of taxes after the accounts are made.
2. **[FIX] account: deferred repartition_line_ids need Command.clear**
When we load a chart template, we generally create records from scratch. Some relational fields may get deferred, since the record they point at may not yet be created. These fields are then not created with the record itself, they are deferred by the `defer` function and they get updated after all creates.
In case the field is `account_tax.repartition_line_ids` though, if we don't provide repartition lines on a tax, `account_tax._compute_invoice_repartition_line_ids` creates two fake ones.
When the deferred field is populated, all the new repartition lines are added for a total of at least four, two fake ones (base, tax) and at least two regular ones (base, tax).
Since there can't be two base repartition lines, the validation `_validate_repartition_lines` raises a ValidationError.
This behaviour can be avoided if before creating relational fields' sub-records, we clear the existing ones.
It should cause no harm since we are anyway creating or updating the parent record, for example: `account.tax <-- account.tax.repartition.line`.
3. **[FIX] account, l10n_it_edi_withholding: Templates submodels values not evaluated**
Files in the CSV templates that had submodels didn't get their values evaluated.
Example:
`account.tax-xx.csv -> repartition_line_ids/use_in_tax_closing` was not evaluated by `account/models/chart_template.py`'s `_parse_csv` function, resulting in taxes having a "False" value still resulting as True.
This already affects l10n_eg.
In the process, code has been a little de-obfuscated.
*(This came out while testing `task-3724926`. Even if they're not in the scope of the task itself, we noticed that withholding taxes have `use_in_tax_closing` to `True` and putting them to False in the CSV had no effect)*
4. **[IMP] account: compute the template function only once**
The templating function is executed 5 times per Chart template instead of once. It may not be all this relevant, but the fix is very basic.
Note: `isinstance` should always be `list | tuple` instead of `(list, tuple)`
related PR: https://github.com/odoo/odoo/pull/148370
task-3607459This fix resolves an issue where the live chat system could select an operator who wasn't available for assignment, causing errors. The system now correctly ensures that only operators from the approved list are selected when assigning someone to handle a new chat conversation.
Original PR description
Before this PR, trying to get an available operator could result in an error. When a live chat is created, an operator is selected based on various criteria such as language, country, number of ongoing chats and availability for calls. This selection process involves the `_get_less_active_operator` method, which receives the status of all operators and a list of operators to choose from. Prior to this fix, an operator not included in the list of operators to choose from could still be selected, resulting in errors when trying to locate them in the operator list. This PR resolves the issue by ensuring that operators are only selected from the provided list. opw-3874872
This fix corrects a German translation issue where both "Source" and "Reference" fields on printed invoices were labeled identically as "Referenz". The translation team recommended using "Verweis" for "Source" to distinguish it from "Reference", making invoices clearer for German-speaking users.
Original PR description
Steps to reproduce:
- Install Contacts, Sales, Accounting and l10n_de
- Configure DIN5008 as document layout in the settings
- Install German language
- Create a contact with German as language (e.g. German Contact)
- Create a SO with German Contact as customer
- Create an invoice from the SO
- Add a Customer Reference ("Other Info" tab) on the invoice
- Confirm and print the invoice
Issue:
On the printed invoice, both "Source" (i.e. the SO) and "Reference" (i.e. Customer Reference) labels are translated with the same German term: "Referenz".
Solution:
Translation team suggested to use "Verweis" to translate "Source" in German.
opw-3821069
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#162559
Forward-Port-Of: odoo/odoo#162381Fixed an unnecessary database operation that was occurring when portal users were created, which could cause system errors during high-volume user signups. The system now skips this operation for portal users since they don't use the digest feature anyway, improving reliability and performance.
Original PR description
When a portal user is created (e.g. through the `auth_signup` module), an unnecessary write is done on the `write_date` of the default digest. This `write` is unnecessary since a portal user is never subscribed to the default digest. In case of a high signup frequency, it can cause concurrent transaction errors. We avoid writing if no internal user is being created. Forward-Port-Of: odoo/odoo#162230
Activity summaries in the Accounting app's Miscellaneous Operations view were stretching across the entire screen when text was long. This fix constrains the activity summaries to stay within their card boundaries, improving the dashboard's visual layout and readability.
Original PR description
Issue ----- The activities summaries displayed by the misc. operations view in the accounting app take up the entire screen and span across the card if the activity summary is too long. Steps ----- - Open the Accounting App. - Create a new entry from 'Miscellaneous Operations'. - Add an activity with a long summary. - Go back the dashboard. The summary will try to span the entire width. Cause ----- The activities are displayed with a field tag in the kanban view. The field tag refers to the activities js component as a widget. Due the use of a widget attribute, the template generates a div with class: "o_field_widget". This class is defined to have a css "display" attribe with a default value of "inline-block". Using "inline-block" causes the activity row to take up the whole width. opw-3839992 Forward-Port-Of: odoo/odoo#160167
This fix resolves a crash that occurred when users tried to install the PEPPOL accounting module. The issue was that enabling PEPPOL didn't properly update a related module's form view, causing the installation to fail. Now the system automatically updates the necessary form when installing PEPPOL, allowing users to successfully enable this feature without errors.
Original PR description
The aim of this commit is to allow user to install `account_peppol` without facing a traceback. Context: The commit cffd0e9dd91376dd7fe4613f4fd94e659daaeef0 introduced a check based on a field introduced in the view by another module it depends on. The problem is that ticking the peppol checkbox install the `account_peppol` module but doesn't trigger an update of the `account_edi_ubl_cii` module. Before the commit: Impossible to installing `account_peppol`. After the commit: Installing `account_peppol` will update the view `account_edi_ubl_cii.account_move_send_form` if the field added by commit cffd0e9dd91376dd7fe4613f4fd94e659daaeef0 can't be found. opw-3874304 Forward-Port-Of: odoo/odoo#162598