Daily updates from Odoo
Thursday, August 8, 2024
14 changes
3 changes
Resolved issues and error corrections
This fixes an issue where IoT devices could be blocked from connecting to Odoo's live update service because they do not send browser version information. The check now applies only to browser connections, avoiding unnecessary IoT device updates and helping existing deployments keep working.
Original PR description
Since [1], outdated websocket connections are refused by the server. However, the IOT connects to the websocket endpoint without passing any version. In order to pass the version, IOT devices should be updated which is cumbersome. This PR fixes the issue by enforcing this check for browsers only. [1]: https://github.com/odoo/odoo/pull/174962
Fixed an issue where Indian POS receipts did not show tax information in the HSN summary for products with HSN codes. This ensures receipts include the expected tax breakdown, helping businesses provide accurate billing information.
Original PR description
Steps to reproduce : -------------------------- - Install pos and l10n_in - Go to products - Create a product with HSN code and set tax - Open a session - Add that product to cart - Order and pay the bill Issue : ------- Opened reciept doesn't contain tax information on the HSN summary section Cause : --------- Trying to fetch data which wasn't sent from arguments causing the related computations NaN and 0. Fix : ----- Passed the argument correctly. task: 4095698
This fixes how Point of Sale calculates taxed list prices by using the correct fiscal position for each order, including orders that have already been paid. It helps prevent inaccurate displayed or computed prices in specific checkout scenarios.
Original PR description
Before this commit, the computation of the orderLine taxed list price incorrectly used the selected order's fiscal position, even for paid orders. This could lead to inaccurate pricing in certain scenarios. opw-4093746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
The Planning calendar popover now hides its footer when a user does not have permission to edit or delete a planning slot. This removes a confusing empty area and makes the interface cleaner for users with limited access rights.
Original PR description
**Current behaviour before PR:** In planning app calendar view, when user has no rights to edit or delete a record then clicking on a planning slot opens a calendar popover with empty footer. Steps to reproduce: - Set no editing rights for demo user for planning app. - Log in as demo user, open planning app. - Switch to calendar view, click on a planning slot. - Notice that calendar popover gets opened with empty footer. **Desired behaviour after PR:** Popover footer shouldn't be displayed at all if user has no rights. task-3823315
Peruvian invoices are now checked to avoid duplicate invoice names when companies share the same RUC. This prevents reporting collisions with SUNAT and helps businesses avoid submission errors or compliance issues.
Original PR description
In Peru, the name we use to report an invoice to SUNAT is composed from the sending company's RUC, the document type code and the numbers from the invoice name. To avoid collisions when sending to SUNAT, we want to prevent Peruvian invoices from having the same name if they belong to companies with the same RUC. Note: I wanted to implement this as a SQL constraint originally, but since some of the data that should be taken into account for the constraint (company fiscal country being Peru, company RUC) doesn't reside in the account.move table, I think the only option is to make this a Python constraint. This means it would not be added on upgrade, but would be active for all invoices in the new version. opw-3900393
The Data Cleaning module now limits a click action to the intended view instead of applying it more broadly. This prevents unintended behavior in base model views and keeps navigation/actions consistent for users.
Original PR description
Since #64854 view_model_tree inherited an action on click that was meant only for a specific view this action has been moved to a primary inherited view. Related to task-id: 3861100
8 changes
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 test failure in the website rental module that occurred when running tests without demo data. The test was failing because user timezone information wasn't properly specified. By setting the timezone directly in the test, the availability test now runs reliably regardless of whether demo data is present.
Original PR description
before this commit [test_availability_in_clients_tz](https://runbot.odoo.com/runbot/build/66644573) was breaking when not having demo data. Was first introduced in https://github.com/odoo/enterprise/pull/61047 Now we fix the issue where test test_availability_in_clients_tz without demo data as user does not have tz specified by specifying it in the test itself.
This fix resolves a critical error that occurred when viewing the French "Intermediate Management Balances" financial report after upgrading from version 16 to version 17. The report was failing to display due to incorrect ordering of report line items. By adding proper sequencing to the report lines, the fix ensures that parent report sections are loaded before their child sections, allowing the report to display correctly on migrated databases.
Original PR description
**Description** A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new…
**Description**
A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases.
The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence, id`, where `sequence` column (if unchanged) remains null, causing lines to be sorted by `id`. The change caused larger id records to be assigned as the parent of smaller id records, violating the required hierarchy and raising a traceback.
**Traceback :**
```py
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 4386, in get_report_information
'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 2123, in _get_lines
parent_generic_id = line_cache[line.parent_id]['id'] if line.parent_id else None # The parent line has necessarily been treated in a previous iteration
KeyError: account.report.line(338,)
```
**steps to reproduce**
1. install 'l10n_fr' and 'account_accountant' in a demo database of version 16
2. migrate it to version 17.
3. go to Reporting->Profit and Loss (Fr company should be selected)
4. Change Report to "IMB - Intermediate management balances"
Note: This PR is created by this [suggestion](https://github.com/odoo/upgrade/pull/6267#issuecomment-2244373973).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.