Daily updates from Odoo
Tuesday, January 28, 2025
14 changes
1 change
Resolved issues and error corrections
The calendar view now displays more consistently after a recent calendar component update. This resolves visual issues such as missing or doubled borders and cropped text in month views, making schedules easier to read.
Original PR description
Since the update of FullCalendar some styling was not properly applied. Which leads to the following issues: - Missing borders - Cropped text in month views - Double borders task-3833841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
The appraisal report now uses the correct status values when assigning colors. This ensures report visuals accurately reflect each appraisal's state, reducing confusion for HR users reviewing appraisal progress.
Original PR description
- update the appraisal state values in the `COLORS_BY_STATE` dict inm the report Task: 4521549
12 changes
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 prevents an unwanted horizontal scrollbar from appearing in mobile self-order when a product has a very long name and no image. Long product names are now shortened visually, keeping the ordering screen easier to use on phones.
Original PR description
- Fix issue when in self order on mobile a weird horizontal scroll bar appears when a product with a long name (and no image) was sell. - Now we just truncate the product name to avoid this issue. task-id: 4510206 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 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.
Demo data for Point of Sale and Restaurant now includes the unique identifiers required by the user interface. This prevents demo orders and restaurant sessions from failing or behaving incorrectly when loaded in the frontend.
Original PR description
Before this commit, demo data had no uuid, which is necessary for the rontend to function properly. A fix had been merged by adding a default value to the uuid field, but this did not work. The frontend is responsible for creating UUIDs, so we added the uuid to the demo data.
This fixes several guided product walkthroughs that could behave inconsistently during testing or demonstrations. The changes make the tours wait for pages, dialogs, chat areas, and interface loading states before continuing, reducing flaky behavior and improving confidence in automated checks.
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors: - show_expense_receipt_tour: Wait the chatter is loaded to prevent lost focus on the input targetted on the next step. - discuss_channel_tour: use hover helper to concat three steps. - website_gray_color_palette: use range hoot helper and wait ui loading appears before to wait it disappears... In the goal to change tour engine and base it on waitFor instead of MutationObserver, these additionnal steps are crucial. - website_form_contactus_submit: wait livechat if module is installed. - course_member: wait the modal is shown before click on element inside. 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
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
This change makes an automated Web Studio test more stable by adding a short wait where timing could previously vary. It helps reduce false test failures, supporting smoother development and release validation without changing user-facing behavior.
Original PR description
Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182
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
This fixes a broken automated tour related to Knowledge article commands in read-only mode. The change helps keep quality checks reliable so issues in the Knowledge app can be caught before reaching users.