Daily updates from Odoo
Friday, September 6, 2024
15 changes
1 change
Resolved issues and error corrections
Fixed an issue where invoices using both fixed and percentage taxes included in the price could show different tax and untaxed totals depending on tax ordering. This makes invoice calculations more reliable and prevents unexpected amount changes when taxes are refreshed or reordered.
Original PR description
### Steps to reproduce the issue: 1. Create two Taxes, one with Fixed "Tax Computation" and one with Percentage of Price. 2. Set "Included in Price" to True and and "Affect Base of Subsequent Taxes"…
### Steps to reproduce the issue: 1. Create two Taxes, one with Fixed "Tax Computation" and one with Percentage of Price. 2. Set "Included in Price" to True and and "Affect Base of Subsequent Taxes" to False for both. 3. Create an Invoice with one line, add both Taxes to it, make sure each Tax has a different amount. 4. Change the order of the Taxes in the Taxes menu 5. Refresh the Invoice Line (e.g.: remove and put back one of the taxes) 6. The amount of the "percent" Tax has changed along with the Untaxed Amount of the Invoice ### Explanation: In `_prepare_taxes_computation`, taxes are preprocessed with a priority set on fixed taxes, then taxes with `price_include` set to True, both in descending order and lastly, taxes with `price_include` set to False in ascending order. In `_propagate_extra_taxes_base`, the currently preprocessed tax is also added to the base of other taxes depending on the specifications of those taxes. When `price_include` is set to True, taxes are never being added to the base of the ones with a higher sequence, it should only be the case if `include_base_amount` is set to True as well. ### Fix reasoning: The computation should be consistent regardless of the order of the taxes, as they are not supposed to have an influence on each other. The special modes computation are changed accordingly. The change to the `total_included` special mode for non `_original_price_include` batches fixes an inconsistency when all taxes are excluded, added a test for it. opw-4068781
2 changes
Resolved issues and error corrections
Spreadsheet pivots are now inserted in the familiar static format by default instead of using dynamic formulas. This makes pivot results easier for everyday users to understand and use without needing advanced spreadsheet knowledge.
Original PR description
Dynamic pivot formulas technically are array formulas, which only are used by advanced excel users. The common user will more likely be lost with the concept whereas the static pivots "just work" out of the box. This revision removes the default insertion of pivot formula from their "splilled formula" form to their previous static form. task-4137727
This fix restores reliable appointment slot display when users choose a date from the calendar. It also prevents an error when changing appointment types on sites using only the Appointment app, keeping the booking flow smooth for customers.
Original PR description
This PR fixes following 2 issues introduced in 9e38975d3f1e9dc87a3061c06ce9df7cf562949c 1. Slots were sometimes not displayed when we select day from the calendar picker. 2. When only appointment is installed and we go to /appointment and then change the appointment type, it throws error. (original task 3928221) task-4163398
12 changes
Resolved issues and error corrections
This fix corrects how customer and vendor account identifiers are formatted when exporting general ledger data in DATEV format for German accounting. Previously, the system inconsistently handled account codes for duplicate receivable/payable accounts. Now all accounts are properly formatted according to DATEV standards, ensuring accurate financial reporting exports.
Original PR description
When exporting GL in datev format, the receivable/payable accounts were not well formatted. Steps: - duplicate the Receivable Account (A) - create a customer C with receivable set as A - create and confirm an invoice for C - go to GL and export datev file -> column konto is account code of A, it should be 1000000 + C.id, according to datev (starting by 1 for customers and 7 for Vendors) Before this commit, we were making the distinction between the customers that had the "original" receivable account and the others, and we were displaying the account code in the second case. It should be the datev format in any case. opw-4117993 Forward-Port-Of: odoo/enterprise#69573
This update adds necessary safety measures to the Uruguay EDI module to prevent test database copies from accidentally communicating with external systems or affecting production data. This allows the support team to safely investigate issues on database duplicates without risk of impacting customers or production systems.
Original PR description
This commit adds the missing neutralization necessary for the l10n_uy_edi module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/51266
This fix resolves an issue where users couldn't drag and drop signature template components in Firefox. The problem was caused by Firefox's lack of support for drag and drop on button elements. Users can now easily drag and drop new components throughout the entire button area, not just the text inside, improving the template creation experience.
Original PR description
The problem was that the button tag doesn't support drag & drop functionality in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=568313). Steps to reproduce (On firefox): - Open Sign up - Open template - Try to drag and drop new compoent - You can only drag and drop through the text inside opw-4085496
This fix restores the "I am unavailable" (unassign) button that was missing from the planning gantt view after a technical update. The button allows employees to mark themselves as unavailable for scheduled shifts. The fix ensures the button now appears correctly in the shift details dialog by properly passing the necessary context information.
Original PR description
Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller Task-3819134
This fix corrects how phone numbers from Ivory Coast and other countries with leading zeros are formatted for WhatsApp. Previously, the leading zero in numbers like "0708151718" was being removed during formatting, resulting in incorrect phone numbers. The fix now preserves these leading zeros as required, ensuring customers can be reached at the correct WhatsApp numbers.
Original PR description
Current behaviour: --- Ivory Coast phone numbers aren't formatted correctly `0708151718 => 225708151718` Expected behaviour: --- `0708151718 => 2250708151718` National number leading zero should be…
Current behaviour:
---
Ivory Coast phone numbers aren't formatted correctly
`0708151718 => 225708151718`
Expected behaviour:
---
`0708151718 => 2250708151718`
National number leading zero should be preserved
Steps to reproduce:
---
```py
from ... import phone_validation as wa_phone_validation
wa_phone_validation.wa_phone_format(
record, number='0708151718',
force_format="WHATSAPP",
)
```
Result => `'225708151718'`
Should be => `'2250708151718'`
NB: record has an Ivory Coast `country_id`
Cause of the issue:
---
`WHATSAPP format` is country_code + national_number
But because `national_number` is an `int`, the leading zero gets removed.
Fix:
---
See [phonenumbers/phonenumber.py](https://github.com/daviddrysdale/python-phonenumbers/blob/7f60158f325ed2ee14212b71ef7e7dc2ce5f01bb/python/phonenumbers/phonenumber.py#L124 )
The `italian_leading_zero` is set True when the national number starts with a zero,
and it should be kept. (ie: Italian numbers) `number_of_leading_zeros` counts the zeros.
Taking those into account when formatting.
opw-3963124This update fixes a confusing technical error that appeared when users tried to select a model they don't have permission to access in the Data Cleaning module. Instead of showing a technical traceback, users will now see a clear, user-friendly error message explaining that they don't have access to that model.
Original PR description
Problem: When a model is selected that the user doesn't have access to, a traceback is shown instead of a clear error message. Steps to reproduce: - Install Data Cleaning. - Go to Data Cleaning > Configuration > Duplication. - In the Model field, select "Account Chart Template". - A traceback occurs. opw-4113923
This fix prevents users from renewing subscription contracts that haven't been invoiced yet. Previously, a subscription could be renewed even if it had never generated an invoice, which violated business rules. Now the system will display an error message when attempting this invalid action, ensuring subscriptions are only renewed after they've been properly started with an initial invoice.
Original PR description
Steps to reproduce: - Subscriptions > New > Set recurrence - Set 'Date of next invoice' in the future - Renew This should raise a ValidationError because renewing a subscription which was never started (no invoice) is invalid, as specified in the error message "You cannot upsell or renew a subscription that has not been invoiced yet". opw-4116538
This fix resolves an issue where scanned barcodes were not being properly saved in the Manufacturing ShopFloor module. The system was not correctly registering changes when barcodes were scanned, and the "Continue Production" feature was not utilizing the proper save mechanism. This ensures that all barcode data is now accurately captured and persisted.
Original PR description
Scanned barcodes were not saved (setting field in record do not register the change). Continue Production did not take advantage of saveModel parameter of doActionAndClose
Fixed an issue where the GSTR-3B tax report for Indian companies was not showing data from bank reconciliation transactions. The report now correctly captures manual reconciliation entries with tax information, ensuring complete and accurate tax reporting for section 3.1(d) of the GSTR-3B form.
Original PR description
* With an IN company setup * Open the bank Reconciliation widget * Make a manual reconciliation with tax 18% IGST RC * Go to tax report GSTR-3B * Issue: there is no impact on the report (3.1 d) This occurs because in the report we take into account move of type `out_invoice` while move registered in the bank journal are of type `entry` Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4058256) opw-4058256 Forward-Port-Of: odoo/enterprise#67520
Draft event registrations will no longer receive periodic WhatsApp notifications until they confirm their attendance. This prevents confusing situations where attendees receive reminders with ticket information before their registration is fully validated.
Original PR description
Draft registrations should not receive any periodic notification until they confirm they will be attending. This avoids awkward situations where the reminder contains a ticket but their ticket isn't validated yet. task-4104891
This fix enables users to set approval rules on form buttons that are linked to actions via XML identifiers. Previously, the system only supported approval rules on buttons with numeric action references, limiting flexibility in workflow customization. This enhancement expands the approval workflow capabilities in Odoo Studio.
Original PR description
Have a button in a form view of type="action" and name="some.xml_id" Before this commit, it was not possible to set approval rules on it. This was due to code in general expecting an int, which is only part of the API for viewButtons (see `action_service.js:doActionButton`) After this commit, it is possible to set approval rules on such button. backport of odoo/enterprise#69399 opw-3925360
This fix restores the EDI certificate that was missing from the Chart of Accounts (COA) SAT XML export for Mexican companies. The certificate is now properly included in the XML file when users download the COA SAT report, ensuring compliance with Mexican tax authority requirements and consistency with other SAT reports.
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" **Issue:** The certificate is not present in the XML. **Solution:** Add the EDI certificate of the company in the "COA SAT (XML)" as it was done in previous versions and as it is also done in the "SAT (XML)". opw-4076158 Forward-Port-Of: odoo/enterprise#68887