Daily updates from Odoo
Wednesday, June 12, 2024
4 changes · saas-17.2
Resolved issues and error corrections
Duplicating website pages now gives each copy a unique internal identifier, preventing errors when users open or edit the original or duplicated pages. This improves reliability for website managers who create pages by copying existing ones.
Original PR description
When a user duplicates a view of a website page and then attempts to open either the original or duplicated view and click on ``edit``, a traceback will appear. Steps to reproduce: - Install the…
When a user duplicates a view of a website page and then attempts to open either the original or duplicated view and click on ``edit``, a traceback will appear. Steps to reproduce: - Install the ``website`` module - Website > Site > Pages - Create one new page > Actions > Duplicate - Repeat 2-3 times - Click on the newly created page or a duplicated one > ``Edit`` Traceback : - ``Expected singleton: ir.ui.view(2224, 2225)`` When duplicating a website page view, we encounter an issue where the ``key`` value remains unchanged, leading to an error. This occurs because, after calling the super in the ``copy_data`` method, the ``key`` is already set on the fields that are being copied to the new record, and ``website.page`` delegates some of its fields to the ``ir.ui.view`` that it holds. This commit will fix the above error by calling the ``copy`` method instead of ``copy_data``. sentry - 4991676595 opw-3936237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders now keep component quantities that users manually enter instead of recalculating them from the bill of materials when using Produce All. This prevents unexpected changes to recorded material consumption and helps keep production records accurate.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM consuming 1 unit of a product COMP - Create and confirm a MO for 1 unit of FP using the BOM - Set the consumed quantity of COMP to 2 and tick…
### Steps to reproduce: - Create a product FP with a BOM consuming 1 unit of a product COMP - Create and confirm a MO for 1 unit of FP using the BOM - Set the consumed quantity of COMP to 2 and tick consumed - Save and "Produce All" #### > the consumed quantity of COMP was updated to 1 according to the BOM ### Cause of the issue: Clicking on "Produce All" will trigger the `pre_button_mark_done` that will update the qty_producing according to the bom proportions because of these lines: https://github.com/odoo/odoo/blob/86f977f8f4b9859790ad77af3a40234c8eb374e9/addons/mrp/models/mrp_production.py#L1217-L1227 However, this update should be bypassed if the quantity was set on the move. This is the role of these lines: https://github.com/odoo/odoo/blob/86f977f8f4b9859790ad77af3a40234c8eb374e9/addons/mrp/models/mrp_production.py#L1218-L1220 The issue does not appear in 17.0 because, thanks to commit https://github.com/odoo/odoo/commit/5bb0f96f1973fa7e19b6701944b4a29577f3314f the `manual_consumption` field of the stock moves related to a manufacturing order is set to be True as soon as the quantity is changed because of these lines: https://github.com/odoo/odoo/blob/9a11717c17b860ec2f1b2e228517c0d3945c474a/addons/mrp/static/src/widgets/mrp_consumed.js#L25-L27 However, this js file was removed in saas-17.2 by commit https://github.com/odoo/odoo/commit/e143345193577442ffd1f46272a09d7a5801d567. opw-3934942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Signatures now keep their intended size on high-resolution displays, including 4K screens with scaling enabled. Automatically generated signatures are also better centered, making signed documents look more consistent and professional.
Original PR description
Before this commit, when a 4K screen was used with devicePixelRatio > 1, the signature svg size was divided by the devicePixelRatio value. We would have small automatic signature shrinked. taskid: 3971056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where website live chat replies could fail for visitors whose browser language was not installed in the database. Notifications are now sent without depending on the visitor's session language, so operators' responses reach guests reliably.
Original PR description
Use case: On a database that has only the "English (US)" (`en_US`) language installed, 1. A visitor having set his browser prefered language to `fr_FR` browse the website, open the livechat and ask a question. 2. A livechat operator pick-up and respond 3. The visitor never see the reponse On the server we see an error: ```odoo.addons.bus.websocket: Invalid language code: fr_FR``` That crash prevent sending the operator response back to the guest (website visitor). As we don't need the language at all to dispatch bus notification, set it to `None`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr