Monday, October 21, 2024
16 changes · 17.0
Resolved issues and error corrections
Italian e-invoice XML generation will no longer be stopped solely because the document type was not automatically set. This keeps invoicing workflows moving while still allowing users to set the document type manually when needed.
Original PR description
… is not set" This reverts commit fd1da69f8331dbc55be2d164fad381fca1622a67. The l10n_it_document_type belongs to `l10n_it_edi_ndd` module. This module exists to add this stored field that was missing. When the error that this commit tried to fix happens, which is due to the fact that the compute doesn't find a correct matching document, we don't want to block the flow. The user can still set a document type himself through Odoo (if he has the aforementioned module installed) or directly in the XML.
This fixes an error that could stop users from sending and printing Italian invoices when an optional related module was not installed. Businesses using the Italian localization can now complete invoice printing more reliably without needing to install the extra module.
Original PR description
The issue: A traceback occurs when clicking the "Send and Print" button in the Italian localization. Steps to reproduce: -Install l10n_it. -Ensure that l10n_it_edi_ndd is not installed. -Create an invoice and click "Send and Print". Explanation: In account_move of l10n_it_edi, a field is used that is only present in the l10n_it_edi_ndd module, which causes a traceback when the module is not installed. opw-4269081
Odoo no longer shows small unintended discounts when event tickets are priced in foreign currencies like JPY or CAD. This prevents customers from seeing misleading discounted prices and keeps ecommerce event pricing consistent with the intended ticket price.
Original PR description
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event…
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug only occurred when the Event Registration product price was set to a value different from the price defined in the Event record. While this bug is present in 16.0 onwards, the logic causing the issue has been refactored and will require a separate fix. Steps to reproduce the issue: 1. Create Pricelists for additional currencies (CAD, JPY) with empty rules and enable the “Selectable” checkbox for Ecommerce. 2. Set currency rates to 133.6200 for JPY and 1.338800 for CAD to replicate the conditions when the bug was found. 3. Create an Event. 4. Create an Event Registration Ticket, ensuring the linked Event Registration product price is $1.00 and the price in the event view is set to $30.00. 5. Visit the Event page on the website and attempt to purchase a ticket. Switch between currencies (JPY, CAD) to observe the issue. 6. Using JPY at the conversion rate of 133.6200, the expected converted price for a $30.00 ticket should be ¥4009, but Odoo calculates the price as discounted to ¥3997. 7. With CAD at 1.338800, the correct converted price should be $40.16 CAD, but the price is instead calculated as $40.12 CAD. 8. On 17.4+, the original and correct prices will display as a strikethrough discount. Cause of the issue: The method _get_contextual_discount in product_product.py was comparing a rounded lst_price to an unrounded contextual price, leading to a tiny discrepancy being mistaken as a discount. The bug occurred because the rounding of the lst_price did not match the rounding of the contextual price. While this method is defined in the product module, it only is used by the event_booth and event_booth_sale modules. Solution: The fix ensures that both operands are not rounded before comparison. Now, the _get_contextual_discount method does not round both the lst_price and the contextual price, preventing the calculation of an erroneous discount. opw-4213704
Viva Wallet payment requests now send the amount as a whole-number value, avoiding failures caused by tiny rounding differences on decimal prices. This helps point-of-sale users complete card payments reliably when products have prices such as 5.10.
Original PR description
Some payment request are failing when sent to viva wallet.
Steps to reproduce:
-------------------
* Configure viva wallet payment for shop session
* Configure one product to have a price unit of 5.1 and na taxes
* Open shop session
* Add that product to order (only once)
* Select **Payment**
* Select viva wallet payment method that you configured
* Select **Send**
> Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'loc': ['body', 'amount'], 'msg': 'Input should be a valid integer, got a number with fractional part', 'input': 510.00000000000006, 'url': '...'}]
Why the fix:
------------
Just a floating point precision issue. `3.1 * 100 = 310` but `5.1 * 100 = 510.00000000000006`, explaining why the issue does not always happen.
opw-4076168This fixes an email editor issue where links or buttons inside a cover template could appear incorrectly in sent mailings. The change ensures hidden email-specific content is handled properly, preventing unintended extra buttons from showing to recipients.
Original PR description
Issue: ====== Extra button in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing - Start from scratch - Drop cover template - Add a link inside it - Test send the email - There is an extra link in the sent email. Origin of the issue: ==================== In the case when the button is inside the cover template we end up with something like this `<!--mso condition ab <!-- another condition cd endif--> ef endif-->` but in reality comments can't be nested so the first comment will close at the ending of the second comment so we will end up with the content `ef` being displayed. Solution: ========= Since the two conditions are opposites, we remove completely the content of the nested comment if it has oppisite condition otherwise we just remove the comment tags since they will be replaced with the upper comment opw-4149948
This fixes an issue where users working in a non-default company could not crop or edit images added to documents such as quotations. Image editing now avoids the incorrect company check, so multi-company users can save image changes reliably.
Original PR description
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Select a company other than the default one. - Create a quotation. - In the description, add an image and save. - Try to crop the image and save again. The operation fails due to the company context issue. opw-4173391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where automated actions triggered on save could interfere with certain dynamic fields, such as project favorites, causing the screen not to update correctly. The change avoids reusing temporary calculated values in automation checks, making save-triggered rules more reliable.
Original PR description
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on…
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on project.project, clicking the widget while there is an automation rule set to trigger "on save" will not properly update the view. This is because the initial write call to `is_favorite` triggers its inverse function, which also attempts to write to project.project.favorite_user_ids which retriggers the automation rule again. During this retrigger, the `old_values` are populated which attempts to fetch the field values from project.project, causing is_favorite to be recomputed BEFORE the inverse function finishes writing the inverse data, causing this inconsistency. The Fix: Filter out non-stored values when memoizing old_values. This will avoid the issue entirely. It also does not make sense for non-stored field values to be "stored" in this way when they could be dynamically recomputed from the stored field values that will still be passed into the context. OPW: 4106799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with the Spanish VAT reporting model (Modelo 349) that was preventing accurate report generation. The changes include updated wording, a new calculation engine for rectifications, and fixes for data errors like negative amounts and incorrect discount calculations. This ensures accurate VAT reporting for Spanish businesses.
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#65074
This update corrects a variable scope problem in the Peru electronic invoicing stock module that was causing incorrect values to be used in certain operations. The fix ensures that the correct data is referenced when processing stock movements for Peru's electronic document system, improving the accuracy of EDI compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#72307
This update fixes how GST tax rates are calculated in Indian tax reports by properly tracking different tax types (IGST, CGST, SGST) separately before combining them. This ensures that businesses filing GST returns get accurate tax rate calculations, especially when multiple tax types apply to the same transaction.
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting.
Fixed a bug in the manufacturing shop floor where the Quality Checks button would remain visible and cause errors even after quality checks were already completed. The system now properly updates its internal record reference when production data changes, ensuring the interface stays in sync with the actual production status.
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393
This fix corrects a bug in the Brazilian electronic invoice system where messages were being posted to the wrong invoice. The issue was detected by an automated code quality check and has been resolved to ensure messages are properly associated with their correct invoices.
Original PR description
Spotted by runbot in master by the `self-in-iter` semgrep check.
Fixed an issue where authorized users couldn't duplicate document templates due to insufficient access rights. The system now properly handles permissions when creating a copy of a template, allowing users with the appropriate authorization to successfully duplicate templates without encountering errors.
Original PR description
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not authorized to see it. opw-4166973 Forward-Port-Of: odoo/enterprise#70496
This update corrects an incorrect reference in the US payroll accounting module. The system was looking for the wrong chart template name and has been fixed to use the correct generic chart of accounts template. This ensures proper accounting setup for US payroll operations.
Original PR description
Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None
This update fixes an issue where demo project stages were being removed when they were already in use by other projects. By removing default stages before assigning new ones, the system now prevents conflicts between demo data from different modules, ensuring a smoother setup experience.
Original PR description
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules.
This fix corrects a variable scope problem in the Peru EDI stock picking functionality. The issue was causing incorrect values to be used in the stock module's EDI processing, which could affect the accuracy of electronic document generation for inventory movements in Peru.