Daily updates from Odoo
Thursday, May 23, 2024
4 changes
Resolved issues and error corrections
This update corrects how base amounts are calculated in accounting tax reports when they are grouped by account and tax. Previously, only tax amounts were properly summed while base amounts were duplicated, causing inaccurate tax reporting. The fix ensures both base and tax amounts are correctly aggregated in grouped tax reports.
Original PR description
Before this commit: The sum of base amounts and tax amounts for accounting reports in 16 is inaccurate. When collecting taxes, implementation was included in 16 to create multiple nodes based off whether the node was a refund, it's tax_id, sale/purchase, and it's account_id. This logic was done to prevent duplicates from being added to the report. However, the base amount was the only value that did this sum with a check, and the tax amount was added regardless. This results in multiple databases with improper tax information generated on the tax reports that are sorted by "Account >> Tax" or "Tax >> Account". Including the addition of base_amount in the computations that check for duplicates will create the right sum for the grouped tax report templates. opw-3890736 opw-3793820
This update fixes a critical issue where setting the repeat interval to zero in recurring maintenance requests causes the system to crash when accessing the maintenance calendar. A validation check has been added to prevent users from saving invalid repeat interval values, ensuring the maintenance calendar functions properly.
Original PR description
If you have "repeat interval" set to "0" in the Maintenance request, and if you go to the Maintenance calendar, then the system crashes. Adding a validationError to avoid the crash. To Reproduce on Runbot: 1. Go to Maintenance Request 2. Make a new request with Maintenance type as Preventive, Recurrent checked, and Repeat Every to 0. 3. Save it 4. Go to Maintenance Calendar 5. The system crashes opw-3859966 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
This fix prevents customers from completing purchases when shipping information contains errors (such as invalid addresses or unsupported delivery locations). Previously, the "Pay Now" button remained active even when shipping costs were incorrectly calculated as zero due to carrier validation failures. Now the payment button is properly disabled when shipping errors are detected, protecting both customers and the business from incorrect orders.
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165267
Forward-Port-Of: odoo/odoo#161704This fix resolves a problem where WebSocket connections were hanging and becoming unresponsive when using Werkzeug version 2.3.x or newer. The issue occurred because Werkzeug was discarding socket data after sending responses, which prevented WebSocket frames from being processed. The fix ensures WebSocket connections remain active and responsive by using alternative data streams.
Original PR description
Since [1], Werkzeug discards any remaining data in the read socket after sending the response. In the case of WebSocket connections, the socket is not closed, and data keeps coming. As a result, WebSocket connections to the threaded server hang indefinitely in this discarding phase and never reach the processing phase. Thus, frames sent to the server are never processed. To solve this issue, rfile and wfile are replaced by dummy byte streams to ensure that our socket remains intact. [1]: https://github.com/pallets/werkzeug/commit/4f7048e7a31752142f18eefeccd49acc42a89e31 Forward-Port-Of: odoo/odoo#166231