Friday, March 22, 2024
5 changes · 17.0
Resolved issues and error corrections
Fixed three critical issues with Estonian tax reports (KMD INF and VD/EC Sales) that were preventing file acceptance by tax authorities. The fixes address incorrect XML formatting, number format requirements, and missing credit note data in tax calculations.
Original PR description
There were a few problems reported with the KMD INF and VD reports. 1. The namespace of the VD (EC Sales) XML export was incorrect, causing the file not to be accepted on the autorities platform. This was fixed. 2. In the VD XML export, the numbers were floats, while they had to be integers for the platform to accept the file. This was fixed. 3. Customer credit notes were not taken into account in the KMD INF report. This was a small issue in the SQL query, were we only considered lines with a tax balance > 0, where for credit notes it is < 0. opw-3758841 Forward-Port-Of: odoo/enterprise#58897
A recent update broke the ability to generate sales reports when a point of sale session used multiple bank payment methods. This fix restores report generation functionality by resolving a technical error that occurred when processing sessions with more than one payment account. Users can now successfully generate sales reports regardless of how many payment methods were used.
Original PR description
Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
This fix resolves a critical memory consumption problem in the POS self-order kiosk when displaying products with images. By switching from processing large image files to checking smaller, pre-stored image versions, the system now uses 55 times less memory—reducing usage from over 1.6 GB to just 30 MB. This prevents server crashes when loading kiosks with many product images.
Original PR description
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128`…
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key). Previously, the field `image_1920` was used which has two issues: 1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used. 2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so: a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157 b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550 So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead. Memory benchmarks for allocations by `_get_self_order_data`: Done on customer DB with 1340 product.products, with a total of 776 images between them. Before commit: 1638.4 MiB + server memory limit reached After commit: 29.7 MiB total Total improvement of 55x less memory usage Current behavior before PR: Server memory limit reached when loading pos kiosk with many product images in filestore Desired behavior after PR is merged: Use much less memory. opw-3809503
This fix prevents the system from getting stuck in an infinite loop when a scheduled task (cron job) is configured with an invalid interval setting of 0. The system now disables the problematic task and shows a warning message to users, preventing system hangs and improving stability.
Original PR description
Create a cron with an `interval_number` of 0 and change its nextcall so that it is called soon. When the cron gets executed, the cron worker enters an infinite loop during the computation of the next nextcall. The cron now gets disabled with an error message. On the form view, users now get a warning when `interval_number` is invalid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158122 Forward-Port-Of: odoo/odoo#144717
This fix prevents users from accidentally deleting the Deliveries product category, which is essential for all shipping carriers. When this category was deleted, users couldn't install or use any delivery carriers, causing significant operational issues. The system now protects this critical category from deletion.
Original PR description
Purpose ======= Lots of tickets are issues when the end user deleted this product category, leading to the impossibility to install another carrier as this category is referenced by all the specific carriers products Ticket example: 3789116 TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158420 Forward-Port-Of: odoo/odoo#158084