Thursday, November 21, 2024
6 changes · 18.0
Resolved issues and error corrections
New products created while importing sales documents now keep the unit of measure from the sales line, such as dozens instead of defaulting to units. This helps avoid pricing and quantity mistakes when products are created automatically during sales import workflows.
Original PR description
Steps: - Go to sales. - Enable UOM from settings. - Export Purchase EDI file with Dozens UOM on product in another DB. - Import that file here in sales. - Since that product is not created here in our db create product on fly from SOL. Issue: - Newly created product does not have Dozens UOM instead it set to Unit and update it in SOL so price on SOL and product is according to Dozens UOM and UOM set on product and SOL is Unit which can lead to issues. Cause: - Missing context to set default UOM from SOL to product. Fix: - Added `default_uom_id` context on product field on SOL view. - Ensure that an uom is always provided to the creation values even if `default_uom_id` is set to `None` in the context, since `uom_id` is a required field on products. - Updated sale_timesheet code to avoid overwriting default values when product is not a timesheet product opw-4316426
This fix lets website grid sections grow vertically when content needs more space, such as on smaller screens or when translated text is longer. It helps prevent cramped or cut-off content, improving the browsing experience for visitors.
Original PR description
Website CSS grid bug fix affecting responsiveness to smaller screen resolutions. **Description of the issue/feature this PR addresses:** Having `grid-auto-rows` fixed at 50px stops the grid cells from growing in a responsive manner. **Current behavior before PR:** Grid cells don't respond to changes in screen resolution or changes caused by the content being translated to a different language. **Desired behavior after PR is merged:** Using the `minmax()` CSS function allows the grid cells to expand vertically to accommodate content that exceeds the minimum height of 50px, improving responsiveness on smaller screens. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents receipt validation failures when a product is changed from lot-based tracking to quantity-based tracking. It automatically clears the lot valuation setting when it no longer applies, helping purchasing and inventory flows continue without manual correction.
Original PR description
Issue: Cannot validate receipts for products whose tracking changed from lot to quantity. Steps to reproduce: - Install both Inventory & Purchase apps - Create a new product - Track the product's inventory by Lot and set it's valuation by Lot - Set the product's tracking in inventory by quantity - Create a Purchase Order for the product - Confirm the PO - Validate the linked Receipt Cause: Lot valuation is not set to False when changing the tracking of a product from lot to quantity. Solution: Add an onchange on the "[tracking](https://github.com/odoo/odoo/blob/78b8a1670b5272c820f64ef904f4bdf00760031e/addons/stock/models/product.py#L694-L700)" field to update "lot_valuated" to False when **lot_valuated is still True** despite **no tracking being specified**. Ticket: [4345571](https://www.odoo.com/odoo/project/49/tasks/4345571) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment transactions can now be completed even when they are linked to more than one invoice due to changes made while the customer is redirected or while webhooks are delayed. The process now selects one eligible posted invoice instead of crashing, reducing failed payment follow-up and manual intervention.
Original PR description
When post-processing a payment transaction, if could happen that the transaction is linked to multiple invoices. Several things can happen while a customer is redirect to a payment provider up to when we post-process the payment (we may long delay for some webhooks), like salesman create multiple downpayment invoices, accountant cancel a pre-existing invoice, etc... In such case we were crashing with a singleton error because `_get_invoice_next_payment_values()` only accept a single recordset. This commit ensure we only match a single posted invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where serial numbers added or changed on Point of Sale order lines were not always shown correctly in the cart. Staff can now see the correct serial numbers when adding the same tracked product multiple times or updating its serial numbers, reducing order errors for tracked items.
Original PR description
When adding/modifying SN on an orderline in the PoS the changes where not always correctly reflected and sometimes it was just not displayed. Steps to reproduce: ------------------- * Create a product tracked by SN * Open PoS * Add this product to the cart and put SN 1 * Add the same product by clicking on it, and put SN 2 > Observation: The item in the cart won't be updated correctly, only one SN will be shown * Click on the lot icon * Add a new SN 3 > Observation: Again the new SN won't be shown opw-4323167
Opening or refreshing a direct link to a document now shows the intended item even when default document filters are configured. This prevents users from landing on an empty or filtered-out view when sharing or revisiting document URLs, including items without previews such as requests or links.
Original PR description
Reproduce: 1. Add the context key `search_default_my_documents_filter` in Documents action context 2. Go in a folder where a document exist that does not match this filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar (or refresh page) 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs. While we're here, we remove the check on open_preview which was incorrect (e.g., requests and urls have no preview but should be accessible this way too). Follow-up of https://github.com/odoo/enterprise/commit/3418e7318ed993abc2a601ae601e7214e28293a3 (https://github.com/odoo/enterprise/pull/74028) Task-4342960