Tuesday, January 28, 2025
7 changes · 18.0
Resolved issues and error corrections
PayPal checkout buttons are now disabled when customers are not yet allowed to pay, such as when required terms and conditions have not been accepted. This prevents customers from bypassing checkout requirements and makes PayPal behavior consistent with other payment methods.
Original PR description
Prior to this commit, the PayPal SDK was used to render a single payment button that replaced the generic submit button of the payment form. This prevented disabling the button when the conditions were not met to allow the payment (e.g., the "Terms and Conditions checkbox was not ticked) as this mechanism relies on the PaymentButton public widget, which was incompatible with PayPal's custom buttons. This commit ensures that PayPal buttons, too, are disabled when the payment is not allowed by making the PaymentButton widget attach itself to the PayPal button container, creating two PayPal buttons - one enabled and one permanently disabled - instead of one, and alternately showing them depending on whether the payment is allowed. opw-4354267
This fixes an issue where users could receive a validation error after changing the bank journal and selecting SEPA Direct Debit while registering an invoice payment. The system now keeps the selected valid journal and payment method, allowing payments to be created as expected.
Original PR description
Steps: - Install `account_sepa_drect_debit` - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `account_sepa_direct_debit.action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Dont recompute the `journal_id` if it is already in `available_journal_ids` Note: We do the same for `payment_method_line_id` opw-4485191
This fix ensures point-of-sale receipts and payment screens calculate cash rounding correctly when a customer pays more than the order total and receives change. It prevents missing or incorrect rounding amounts, helping cashiers provide accurate totals and receipts in cash-rounding setups.
Original PR description
Check the commit message for description.
Point of Sale now correctly validates orders where payments bring the total to zero, such as purchases fully covered by an eWallet. This prevents confusing prompts for an extra zero-value payment and helps cashiers complete affected sales smoothly.
Original PR description
Before this commit, a rounding error could leading to scenarios where orders with a zero total could not be validated. For instance, adding a product priced at $70 with a 15% tax included and then applying an eWallet payment in PoS would result in a zero total. However, during the payment step, the system erroneously prompted for an additional zero-amount payment line, causing confusion and preventing order validation. opw-4487591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from repeatedly marking normal email template content as quoted text during message processing. As a result, emails sent from chatter or automated field-change notifications should display correctly without unnecessary "Read more" breaks.
Original PR description
Some mail templates are having an issue where read more is getting redundant. This happens when we either send the template as mail in chatter or in some cases when an automatic mail is sent when a…
Some mail templates are having an issue where read more is getting redundant. This happens when we either send the template as mail in chatter or in some cases when an automatic mail is sent when a tracked field is changed. Technical Info: - Generally when a template is processed/added it is sanitized as xml (sanitize mode as 'email_outgoing'). - The body(a HTML field) is being sanitized. - Then when sending a message in chatter is again sanitized again into field `body_html` in `mail.message.compose`. - The `mail.message.compose` is further copied into `mail.message` where the field is again sanitized. Now that problem is that when we sanitized the template of `mail.template` we dont sanitize any of the tags as at this step the targetted output is a xml (beacause can contain any tags as opposed to as html). In this very step we do a clean up of tags which is causing the problem (in method 'tag_quote') which adds the read-more inducing tag called `data-o-mail-quote`. When this template is again sanitized now the due to the [condition](https://github.com/odoo/odoo/blob/db3b2671efaf7cb84dce93eefd9c3f12c0e6a65c/odoo/tools/mail.py#L221) here every other node is set to be having the tag `data-o-mail-quote`. When a break(`<br />`) tag has this tag it induces the `read more`. Solution: - The main culprit is quote detection causing all the issues. So a condition to stop it mutilating the main content of html which keeps on adding unnecessary css classes distorting the html displayed. task-4331146
Manufacturing order overviews now calculate expected BoM costs using the same work center timing factors as the BoM overview, including efficiency, setup, and cleanup time. This gives users a more reliable cost baseline to compare against actual production costs when parameters change during manufacturing.
Original PR description
Steps to reproduce the bug:
- Create a workcenter “WC1”:
- Cost by hour: 60
- Setup time: 10 min
- Cleanup time: 10 min
- Time Efficiency: 85
- Create a storable product “P1” with the following BoM:
- Operation: OP1 -> 60 min in WC1
- Create a MO to produce one unit of P1:
- Confirm the MO
- Go to the MO overview
Problem:
Time Efficiency, setup, and cleanup times are not taken into account in the BoM Cost calculation.
The calculation should be the same as in the BoM overview. The purpose of the BoM cost in the MO overview is to provide information for comparison with the real cost, in case the user has modified certain parameters during production.
opw-4478070This fixes an issue where users could not create SEPA Direct Debit payments after switching to a duplicated bank journal in the payment wizard. The selected journal is now kept when it is valid, preventing an incorrect validation error and allowing payment creation to continue.
Original PR description
Steps: - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Adding the `journal_id` in the write vals avoids it to be recomputed opw-4485191