Daily updates from Odoo
Thursday, August 8, 2024
7 changes · 17.0
Enhancements to existing features
This update improves how discounts are handled in Ecuador electronic invoices. Previously, negative invoice lines (global discounts) were not accepted by the Ecuador government. The system now automatically converts these negative lines into proper discounts applied to positive line items, ensuring compliance with government requirements.
Original PR description
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009
Resolved issues and error corrections
This fix resolves an issue where quality control labels were not printing to IoT printers and were being downloaded instead. The problem was caused by a data format mismatch where the printer device information needed to be converted to the correct format. Now labels will print automatically to the IoT printer as intended.
Original PR description
Before this commit: Having a quality control point using "Print label" with an IoT printer will not print anything and download the file. This happened due to the JS function `iotReportActionHandler` ignoring the device sent as it expected it to be a list, see: https://github.com/odoo/enterprise/blob/1412cd3edc6005b05d43d42828e6647ee58594ae/iot/static/src/iot_report_action.js#L21 Therefore, defaulting to the behavior of downloading the file After this commit: Print the label automatically to the IoT like expected opw-4032741,4017327,3895056
This update fixes a compatibility issue that prevented Argentine companies from testing their AFIP Web Services connections in Odoo 17. The fix removes outdated code that relied on a function removed from the PyOpenSSL library, ensuring the system works properly with Python 3.12 and newer versions.
Original PR description
### Steps to reproduce * install python 3.12 * install odoo's python required libraries (requirements.txt) * install `l10n_ar_edi` * switch to an Argentinean company * in the Invoicing settings, under the AFIP Web Services section, click 'Test Connections' You should be met with the following error: `AttributeError: module 'lib' has no attribute 'PKCS7_sign'` ### Cause `PKCS7_sign()` was removed in recent version of `pyopenssl`. opw-4085411 opw-4085389
This fix resolves a system error that occurred when users tried to add an existing attendee's email as a guest to an appointment booking. The issue happened because the system was creating duplicate attendee records instead of recognizing the email already existed. Now the system properly checks for existing attendees before creating new ones, allowing users to smoothly add guests without encountering errors.
Original PR description
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment`…
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment` from the website 3) Click on `Appointment Type` in the right corner and on the `options page` enable `Allow Guests` 4) Get back to the website and select one user, date & time 5) Now give Email value as email in Guests 6) Confirm Appointment Error:- ``` ValueError: Expected singleton: calendar.attendee(4762, 4763) ``` When the user adds a guest with the current user email, multiple attendees will be created with the same partner ID in a calendar event (see below) https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/models/appointment_type.py#L944-L955 This leads to the above traceback from here https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/controllers/calendar.py#L103 This commit will resolve the issue by filtering out the existing attendees while creating a new attendee from the guest email. sentry-5646921453
This fix prevents automatic population of Peppol fields when using Mexico's localization module. Previously, the system would incorrectly fill these fields based on the Mexican VAT format, causing validation errors. Now these unused fields remain empty for Mexican companies, eliminating the need for manual correction.
Original PR description
Version: 17.0+ Current Behavior: Peppol fields are automatically populated based on the `vat` field of the res.partner record. With l10n_mx localization installed the `vat` field is based on the first two letters of the first name and the first letter of the last name. However, the peppol fields with be automatically computed if the first two letters are similar to country codes. Purpose of this PR: This PR overrides the peppol computation so that the peppol fields are emptied when l10n_mx_edi is installed. These fields are unused in l10n_mx localization so they can be omitted. Steps to Reproduce on Runbot: 1) Install accounting and contacts 2) Create a contact with l10n_mx vat format (i.e. ESPN0101011E2) 3) Navigate to the Accounting Tab of the partner record and find that the peppol fields are filled. Notes: In the current behavior, the user will have to manually empty the peppol fields to avoid receiving the error of incorrect peppol format. opw-4074094
This update fixes how XML documents are formatted in the Mexican localization modules to improve compatibility with third-party vendors. The change ensures XML declarations use double quotes instead of single quotes, which some external systems require for proper validation. This makes the generated documents more universally compatible without changing any functionality.
Original PR description
This commit refactors the generation of pretty printed raw xml string to a helper function in `l10n_mx_edi.document` for `l10n_mx_edi` and `l10n_mx_reports`. It modifies the xml declaration to be a custom generated string, which only difference from the normal one is that it uses double quoted string rather than single quoted string in it. This way, the top file of the generated xml string will look like this: ```xml <?xml version="1.0" encoding="UTF-8"?> ``` This ensures as much support as possible from third party vendors because some do not consider single quoted string to be valid (even though it should be). related opw-4085399 task-id: no task
This fix resolves an issue where converting a helpdesk ticket to a sales lead would fail in certain situations. The problem occurred when the system had many helpdesk teams but fewer sales teams, causing a configuration conflict. Users can now successfully convert helpdesk tickets to leads without encountering errors.
Original PR description
Prior to this fix, trying to convert a helpdesk ticket to a lead would fail if the default_team_id was set and beyond the possible IDs for crm.team records. This happens in installations with a large number of helpdesk teams and relatively few sales teams.