Wednesday, July 29, 2026
16 changes · 19.0
Resolved issues and error corrections
This fix makes automated checks around creating sales order lines for project and timesheet flows more stable. It reduces false test failures caused by timing issues and makes product selection in tests clearer and less fragile.
Original PR description
- Fix: The edit() calls now pass { confirm: false } to avoid calling the extra step that involved clicking manually on the input to trigger the search and the dropdown display. This should remove the race condition.
- Small cleanup: clickFieldDropdownItem replaces the hardcoded ".dropdown-item:nth-child(1)" click, allowing selecting by product name instead of position.
runbot-error: 941390
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCharts in spreadsheets now keep their customized series colors when users change date granularity or date filters. This prevents dashboards from unexpectedly reverting to default colors, making reports more consistent and easier to read.
Original PR description
Before this commit: When changing the date granularity of a chart that has a customized color, the color was lost and replaced by the default one. How to reproduce: - Go to any dashboard with a chart - Change the color of a serie - Go back to Dashboards - Plays with the date filters Task : 6148498 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
Fixed an issue where reopening or replacing an existing YouTube video with options such as autoplay could trigger an error in debug mode. This keeps the website editor workflow reliable when users adjust embedded video settings.
Original PR description
**Steps to reproduce:** 1. Enable debug mode and add a snippet. 2. Add a YouTube video with options like autoplay enabled. 3. Double click the video or use "Replace Media". 4. A traceback occurs…
**Steps to reproduce:**
1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.
**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`
The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.
**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.
task-6233423This update adds automated coverage to ensure optional products on sales quotations receive the correct price when customers change quantities in the quotation preview. It helps prevent pricing errors where volume-based pricelist discounts might not be reapplied correctly.
Original PR description
Steps to produce:
---
- Install the Sales module.
- Enable `Pricelists` from Sales settings.
- Create a new product.
- Go to Sales > Products > Pricelists and open an existing pricelist.
- Add the following rules for a product:
- min qty: 1 > price: 100
- min qty:10 > price: 80
- Create a new quotation > add section > add the same product.
- Set the section as optional > Preview the quotation.
- Change its quantity to 10.
Added test covering the fix introduced in [commit], ensuring
that pricelist rules are correctly reapplied when the quantity of an
optional product is changed from the quotation preview.
[commit]: https://github.com/odoo/odoo/commit/93b6bdd6a4909bc0b45b90ab6a2d0734a218292d
opw-6241183
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an automated test in the Mail app that could fail when the system was under heavy load, even though the product behaved correctly for users. By waiting for the right screen before continuing, it reduces false test failures and helps keep releases moving smoothly.
Original PR description
The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')" step timed out.
This is a test-timing artifact: a real user always sees the starred view render before navigating away, so the breadcrumb is correct for them.
Wait for the starred thread to be displayed before opening the channels list, and assert the channels view opened via its "Public Channels" breadcrumb. Also use :text instead of :contains for the text selectors.
https://runbot.odoo.com/odoo/error/242893Invoices now show lot and serial number quantities with clear spacing between the amount and unit of measure, such as "1.00 Units" instead of "1.00Units". The related table alignment was also corrected, making invoice details easier to read and more professional for customers.
Original PR description
When displaying lots or serial numbers on invoices, the quantity and UoM were rendered without any separator in the SN/LN table, e.g. `1.00Units`. - Add a non-breaking space between the quantity and UoM so the table renders as `1.00 Units`. - Also align the SN/LN value cell consistently with its right-aligned column header. - Update the `sale_stock` and `sale_mrp` report tests to expect whitespace between the quantity and UoM in the rendered invoice output. Task [link](https://www.odoo.com/odoo/project/967/tasks/6365178) task-6365178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale feedback screen now closes sooner after payment, reducing the time customers and staff may spend waiting. The delay is set to 1.5 seconds so the payment confirmation animation can still finish while keeping checkout flow faster.
Original PR description
- Some clients does not know that they can skip the feedback screen timeout by clicking on the screen. So we decrease the timeout to 1.5 seconds to avoid that they wait too much time. - This timeout was already reduced in version `saas-19.1` to 1 second (see PR: github.com/odoo/odoo/issues/235316) - We now set it to 1.5 seconds (because 1 second is not enough for the paid animation to finish on the feedback screen). task-id: 6425204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an automated test for cancelling a link popup during an attachment upload more reliable. It prevents occasional false failures in Odoo's testing infrastructure, helping releases proceed with fewer interruptions while leaving user-facing behavior unchanged.
Original PR description
The test that verifies the behavior of cancelling the link popover during an attachment upload relies on a hard-coded delay. Occasionally, when the test runs on an overloaded runbot infrastructure, the upload manages to complete before the discard happens. This commit fixes this by making sure the upload never completes within the test. runbot-940190 runbot-944098 Forward-Port-Of: odoo/odoo#278820
This fixes a reliability issue where Odoo's real-time messaging connection could fail to reconnect after a manually triggered close. It helps keep live notifications and bus-based updates available without users needing to refresh or retry.
Original PR description
The `bus_monitoring_service` test "connection considered as lost after failed reconnect attempt" fails about half of the time. Since [1], the reconnect delay in tests is much smaller. The retry…
The `bus_monitoring_service` test "connection considered as lost after failed reconnect attempt" fails about half of the time. Since [1], the reconnect delay in tests is much smaller. The retry therefore fires while the mock socket is still in the closing state. `_start` detects that socket and triggers the close event manually to keep the lifecycle consistent. In other cases, the error event will schedule a reconnect but in this case it will never arrive. The worker is then left with no socket, no listeners and no pending timeout: it never reconnects. Schedule the reconnection when handling a manually triggered close, since no error event will follow to do it. [1]: https://github.com/odoo/odoo/pull/278075 runbot-944578 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 Forward-Port-Of: odoo/odoo#278892 Forward-Port-Of: odoo/odoo#278779
Payment receipts now display the specific payment method name chosen on the journal, instead of always showing the generic Manual label. This makes receipts clearer and more accurate when businesses use multiple similarly configured payment methods.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Bank Journal** and go to the **Inbound Payment Methods** tab. * Add the **Manual** payment method multiple times and give each payment method line a different name. * Go to **Customers → Payments** and create a payment using any of these payment method lines. * Print the **Payment Receipt** from the gear menu. **Observed behavior:** * The receipt always displays the **Manual** payment method name. * The custom name configured on the selected payment method line is ignored. **Cause:** * The report retrieves the payment method name from `account.payment.method`. * However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name. **Fix:** * Read the payment method name from the selected `account.payment.method.line`. * The payment receipt now displays the configured payment method line name. opw-6395829
Expense card authorization updates now keep the merchant currency instead of falling back to the company currency when the currency lookup is less exact. This helps keep expense amounts accurate for businesses using Stripe-issued cards across different currencies.
Original PR description
During updates of the authorization amounts the currency may revert to the company one Specifically, if the merchant currency cannot be found, it defaults to the company currency. We now broaden the search search on currency with the `ilike` operator Task [link](https://www.odoo.com/odoo/project.task/6345203) opw-6345203
The Benefits form now stops users from creating new employee, cost, or mandatory benefit records directly from selection fields. This helps keep salary benefit setup consistent by ensuring related records are created through the proper workflows.
Original PR description
This commit prevents creating new employee, cost or mandatory benefits records directly from the Benefits form by setting these fields' `'no_create'` to `True`. task-5156844 Forward-Port-Of: odoo/enterprise#96770
This fix keeps Australian payroll accounting tests consistent by locking them to a specific date. It prevents recent payroll rule changes from causing unrelated test failures, helping maintain reliable payroll updates.
Original PR description
The new qualifying earning rule introduced was breaking the tests that were not frozen in the past as it changed over to the new reporting code. runbot-940160 related too [11736](https://github.com/odoo/enterprise/pull/117367#event-26694075694)
Chilean invoice PDF copies now always show the legally required CEDIBLE disclaimer in Spanish. This prevents the footer from appearing in English when the customer's language is not Spanish, supporting correct legal presentation of Chilean electronic invoices.
Original PR description
Steps to reproduce: - Set the database language to Spanish (Latin America). - Create a customer invoice, confirm it and send it to the SII. - Print it using Print > Invoice PDF copy (Chile). - Scroll…
Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.
Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.
Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.
opw-6390207
Forward-Port-Of: odoo/enterprise#124916Australian payroll no longer crashes if an employee's Tax Treatment Category is temporarily removed. The system now safely leaves the related tax treatment code empty until the required category is set again, helping payroll users continue editing employee records without interruption.
Original PR description
Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee. Steps to Reproduce: - Install the `l10n_au_hr_payroll` module with demo data. - Switch to an…
Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee. Steps to Reproduce: - Install the `l10n_au_hr_payroll` module with demo data. - Switch to an `Australian company`. - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value. `UnboundLocalError: cannot access local variable 'code' where it is not associated with a value` After the [change] in selection field behavior, users can clear the value of the field. When the user removes the Tax Treatment Category value, the system computes the tax treatment code [1]. During this process, if no condition matches, the code variable is not initialized. Converting this uninitialized variable to a string [2] raises an error. This commit ensures that when the tax treatment category is not set, the tax treatment code is set to False with an early return. Since the tax treatment category is required field and compute the correct tax treatment code, once the category is set. [change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef [1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451 [2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515 No task ID
The payment status display now refreshes correctly when users move between batch payment records. This prevents outdated payment information from being shown, helping users see the correct signing or initiation status for each batch.
Original PR description
To display the `payment_online_status` field, we use a widget called `account_online_payment_refresh_button`. The issue is that the widget don't update the field value when switching from one record to another. Steps to reproduce: 1. Create 2 batch payments 2. Do a payment initiation with the first one, and sign it 3. Do another payment initiation with the second one, but don't sign it. 4. Open 1 batch, and try to switch records with the pager 5. You should see the value is not updated task-6420585