Tuesday, September 1, 2026
26 changes · saas-19.2
Resolved issues and error corrections
Mobile invoice views now show the line description when an invoice line has no product selected. This prevents blank cards and makes invoices easier to review and edit on mobile devices.
Original PR description
Invoice lines can be created without a product. However, the mobile kanban view does not handle such lines properly and displays an empty card without a name or image. This commit adapts mobile kanban view to show invoice line's name when `product_id` is not set. Before | After -- | -- <img width="469" height="277" alt="image" src="https://github.com/user-attachments/assets/3b367581-b73d-4b12-a487-1a54c3b88470" /> | <img width="406" height="300" alt="image" src="https://github.com/user-attachments/assets/107d7294-90e8-49c6-826a-9be75c6b799f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285608 Forward-Port-Of: odoo/odoo#284755
The Guatemala electronic invoicing setup now applies the updated tax calculation for regular gasoline containing 10% alcohol. New customers will receive the revised chart of accounts tax formula, while existing databases can manually update their configuration if needed.
Original PR description
Starting August 22nd Regular Gasoline is changing to a version that contains 10% alcohol. Because of this, the government is only taxing 90% of the gallons since the 10% alcohol portion is exempt. This will update COA for new customers, any current dbs who need to use the new formula can manually update theirs to include the * 0.9 portion. task-6483303 Forward-Port-Of: odoo/enterprise#129483 Forward-Port-Of: odoo/enterprise#129412
This fixes an error that could occur when verifying bank accounts for several Polish partners if some partner records were missing a VAT number or bank account. The verification process now continues reliably instead of failing for the whole batch.
Original PR description
When we check for multiple partners with some valid and some being incomplete (no vat or no bank account), a traceback is raised This was due to a bracket accessor, changed into a get in this commit. no-task Forward-Port-Of: odoo/odoo#285631
This update fixes an occasional failure in a manufacturing test caused by results appearing in a different order. It makes the test focus on verifying the correct amounts rather than relying on line order, improving confidence in automated checks without changing user-facing behavior.
Original PR description
Issue: Test product_produce_6 fail from time to time due to lines being misordered. The test aim to check the amount within the line, not their order. runbot-946209
Invoices created from point-of-sale orders linked to sales orders now keep the customer reference from the original sales order. This helps businesses maintain clearer traceability between customer orders, POS activity, and invoices, especially when orders are consolidated.
Original PR description
The pos_sale override of _prepare_invoice_vals left ref and invoice_origin untouched, so the SO's client_order_ref was lost on the invoice. The fix is to mirror sale.order._prepare_invoice and set both fields from the linked SO, while preserving pos_reference traceability for mixed consolidated batches. task-id: 6295629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278035
This fixes an automated point of sale test that could fail on slower or heavily loaded systems. The change makes the test check screens in a safer order, improving release validation without changing the customer-facing checkout experience.
Original PR description
The tour relies on the receipt rendering completing very quickly, as it removes the feedback screen after 500ms. On a slow/loaded machine (e.g. set `cpu_throttling=3` in the tour), the tour consistently fails as it waits for the feedback screen which has already disappeared. The fix is to check the feedback screen first, then confirm the receipt printing dialog. This lets the tour pass both normally and under load. runbot-946294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French PDP invoice responses are now sent through only the PDP channel instead of being duplicated through both PDP and classic Peppol. This reduces duplicate messages and keeps invoice communication records cleaner while preserving the intended response flow.
Original PR description
When responding to an invoice received through PDP, 2 responses were actually sent: one through PDP and the other through the 'classic' Peppol. This was done to allow more reliability, in case one channel is down when trying to respond, but this mainly creates cluttah' in the chattah' (call me busta rhymes yo) task-6522652 Forward-Port-Of: odoo/odoo#285596
Recurring maintenance requests no longer create an extra reminder on the completed request when the next request is generated. This keeps responsible users focused on the new maintenance task and avoids confusing duplicate follow-ups.
Original PR description
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an…
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an activity is created for the responsible user. 3. Mark the activity as done. 4. Move the request to `Repaired`, or another done stage. 5. Check the newly generated request in the recurring series. When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series. The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`. Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request. The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request. Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request. opw-6409396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279470
This fix narrows how document-related emails are found so the system only retrieves messages for the intended record type. It helps prevent the wrong mailings from being shown or processed in Documents, reducing confusion and improving data accuracy.
Original PR description
Description of the issue/feature this PR addresses: Updates the `_get_mail_messages` domain filter to include the target model, preventing accidental retrieval of incorrect mailings. runbot-242254 Forward-Port-Of: odoo/enterprise#129061
This fix prevents website editors from deleting an image inside a card cover while leaving the empty cover container behind. It avoids confusing editor behavior and prevents an error that could occur when using the Cover Image options afterward.
Original PR description
It was possible to remove the image inside a card cover while keeping the figure wrapper. The card option would then still consider that there was a cover image even though the image was gone, which could also lead to a traceback. Steps to reproduce: - Insert the `s_three_columns` snippet - Click on the image of one card - Either press "Enter", "Delete", "Backspace" - Hover the "Cover Image" options => The image is removed but the `<figure>` is still there, so the option is still considered active (leading to a traceback) task-6081728 Forward-Port-Of: odoo/odoo#283106 Forward-Port-Of: odoo/odoo#280086
Manufacturing bills of materials now exclude combo products from component selection. This prevents configurable sales bundles from being used where physical manufacturing parts are expected, reducing setup mistakes.
Original PR description
Version: --------- - 19.0+ Steps to reproduce: ------------------- - Install `mrp` and `sale_management` - Create a product of type `combo` - Go to Manufacturing > Products > Bills of Materials - Create or edit a BoM - Add a component line - Select the combo product Issue: ------ Combo products can be selected as BoM components. Since combo products represent configurable sales bundles rather than physical products, they are not meaningful manufacturing components. Before Commit: ------------------- - It was possible to select a product of type 'combo' as a component in a Bill of Materials. After Commit: ----------------- - Combo products are filtered out of the component picker and cannot be added as BoM components --- opw-6425024 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278861
This fixes an error that could appear when users added a new group in a grouped list that shows totals or aggregates. The change keeps list views stable during group creation, avoiding an unexpected traceback and interruption to the workflow.
Original PR description
Adding a new group on a grouped list view with aggregates gives a traceback. This comes from `getFieldCurrencies` and `computeAggregates` which didn't guard for group with no currency aggregates (like a newly created group). Steps to reproduce: - open a list view (CRM) - group by a m2o (Contact) - click on 'Add a Contact' - press Enter => Traceback Forward-Port-Of: odoo/odoo#285438 Forward-Port-Of: odoo/odoo#285325
This fix prevents slow mobile-style taps in automated tests from being mistaken for long presses when the system is under load. It helps avoid random test failures around saving HTML mail content, improving confidence in build results without changing end-user behavior.
Original PR description
Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the…
Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the write:
[verifySteps] expected the following steps
> Expected: [
"web_save",
]
> Received: []
This happens because a tap held longer than `LONG_TAP_DELAY` counts as a long press, and `_pointerUp` then dispatches no click at all. That delay spans the synthetic pointerdown and pointerup of a single `click()`, so the work a listener does during the press counts towards that delay: tapping save blurs the html field, which converts the whole editor content to inline styles, and under the load of a runbot build that conversion alone takes longer than the delay.
One solution could have been to raise `LONG_TAP_DELAY`, but a listener slower than the new value suppresses the click again.
This commit counts a tap as long only when the test releases the pointer itself, with `pointerUp`, so the work a listener does during a `click()` no longer suppresses the click.
https://runbot.odoo.com/odoo/error/946581
Forward-Port-Of: odoo/odoo#285640
Forward-Port-Of: odoo/odoo#284971Loading sample data in Shop Floor no longer fails if a specific work center schedule was deleted. The system now uses the standard working schedule as a fallback, preventing setup interruptions for manufacturing work orders.
Original PR description
Currently, an error occurs when loading the sample data in the Shop Floor. **Steps to Reproduce:** - Install the `mrp_workorder` module. - Go to `Employees` > `Configuration` > `Working Schedules`. -…
Currently, an error occurs when loading the sample data in the Shop Floor. **Steps to Reproduce:** - Install the `mrp_workorder` module. - Go to `Employees` > `Configuration` > `Working Schedules`. - Delete the `Work Center 40 hours/week` record. - Go to `Settings` > `Users & Companies` > `Groups`. - Open the `Manage Work Order Operation` group and add the `Administrator` to the `users` list. - Open the `Shop Floor`. If the `Activate your Work Center` dialog appears, click it and then click `Configure Later`. - Click `Load Samples`. `ValueError: External ID not found in the system: mrp.mrp_workcenter_calendar` After the [recent commit], the sample work center uses the `Work Center 40 hours/week` working schedule instead of `Standard 40 hours/week`. As a result, if the `Work Center 40 hours/week` record is deleted, loading the sample data raises the error [1]. This commit ensures that when the Work Center 40 hours/week calendar is not available, it falls back to `Standard 40 hours/week`, restoring the previous behavior [2]. This fallback is required because `resource_calendar_id` is mandatory from the view perspective, even though it is not required at the model level. If it is left empty, the form displays a missing required field. The `Standard 40 hours/week` calendar is always available because it is linked to the main company [3] and its `resource_calendar_id` field uses `ondelete='restrict'` [4], preventing it from being deleted. [recent commit]: https://github.com/odoo/enterprise/commit/336d721f7b353473fe5e07c29ce14ed77a88fb98 [1]- https://github.com/odoo/enterprise/blob/c0045ec3cf94650d66192a4ca3e0dc3c17daa5bd/mrp_workorder/models/mrp_production.py#L213-L216 [2]- https://github.com/odoo/enterprise/blob/51c1e74e90e510d59aad78820e2c29e821ba2854/mrp_workorder/models/mrp_production.py#L214-L217 [3]: https://github.com/odoo/odoo/blob/4c4219a7d9d51f703b15e83ab755faf1f2c8a71d/addons/resource/data/resource_data.xml#L10-L12 [4]: https://github.com/odoo/odoo/blob/4c4219a7d9d51f703b15e83ab755faf1f2c8a71d/addons/resource/models/res_company.py#L12-L13 sentry-7651161729
This fix changes the order of test cleanup messages so memory information is recorded before the test result is finalized. It prevents failed test runs from showing an extra, misleading error, making build reports clearer and easier to act on.
Original PR description
Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one: odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser: Error received after…
Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one:
odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser:
Error received after termination: [MEMINFO] tests done (after GC)
- used: 220535896 - total: 341990868 - limit: 4395630592
Note that the figures themselves are fine (220MB used of a 4.4GB limit): the error is not about memory, only about when the line is logged.
This happens because the runner logs that line after `stop()`, and `stop()` is what reports the suite result: the server settles the test on that report and kills the browser. The final major GC outlasts the report. A passing build escapes because the browser dies within milliseconds; a failing one stays up for the screenshot, long enough for the GC to finish and the line to land after termination.
This commit fixes the issue by moving `stop()` after the final cleanups and their memory log: the [MEMINFO] line is still logged, but before the result report, while the server still waits on the browser.
https://runbot.odoo.com/odoo/error/229655
Forward-Port-Of: odoo/odoo#284957Product variant prices now keep the same minimum decimal display as the main product price when used in reports. This prevents prices such as 19.50 from appearing with too few decimals, improving consistency and clarity in generated documents.
Original PR description
Issue: --- Record's `min_display_digits` is not inherited in case of a model inheritance. e.g. `list_price` is inherited to `product.product` from `product.template`, however it renders with fewer decimals than `product.template.list_price` in reports. Steps to reproduce: 1- Set a product's Sales Price to 19.5. 2- Add `product.product.list_price` to a report using studio. The variant's field renders with 1 decimal while `decimal.precision` is 2. Cause: --- This is missed in ee32a17495a10af18f0b5de0a295283c5059d3c2 which introduces minimum precision. opw-6465159 Forward-Port-Of: odoo/odoo#285336 Forward-Port-Of: odoo/odoo#285064
This fix makes Odoo's web test process stop and report the real loading error when required test dependencies cannot be fetched. It prevents builds from sitting idle until a timeout, helping teams identify infrastructure or test setup problems more quickly.
Original PR description
Before this commit, a unit test suite could go silent between two test files, and `browser_js` then waited out its whole timeout before failing with:
[ERROR] TypeError: Failed to fetch
at orm (web.assets_unit_tests.min.js)
FAIL: WebSuite.test_unit_desktop
AssertionError: Script timeout exceeded
This happens because `fetchDependencies` gives every addon a `Deferred` that only the success handler of the batched `all_dependencies` call resolves, and a loaded runbot host answers that call with `RuntimeError: can't start new thread`. Nothing then settles those deferreds, so the `Promise.all` waiting on them never returns, `stop()` is never called, and the browser holds the build until the timeout.
This commit rejects the deferreds of a failed batch and reports an error escaping `runTests` on the console, so the build fails on the fetch error instead of running out its timeout.
https://runbot.odoo.com/odoo/error/243504
Forward-Port-Of: odoo/odoo#284980This fix prevents one timed-out mail test from continuing to trigger false failures in many later tests. It makes test results clearer and helps teams identify the real problem faster without being distracted by cascading errors.
Original PR description
Before this commit, one test contains() reaching its 10 seconds budget made the 129 tests that ran after it fail with its own assertion, over 14 suites:
[HOOT] Test "@mail/message/link_preview/Delete all link previews at
once" failed:
Failed assertion:
3. [toBe] expected values to be strictly equal (Failed to find 1 of ".o-mail-Message-body:text(...)" (Timeout of 87 seconds). Found 0 instead.)
This happens because the tick re-schedules itself on the result of runOnce(), which is undefined on a failure, the crashing one included. The check keeps selecting every 500ms and logs its assertion against whichever test is running, until a tick lands between two suites and getFixture() throws.
This commit re-schedules a tick only while the check is not done, so the crashing one is the last.
https://runbot.odoo.com/odoo/error/946650
Forward-Port-Of: odoo/odoo#285585A product page selector was tightened so it only targets the intended product option inputs. This prevents unrelated form fields from being affected, improving reliability when customers configure products online.
Original PR description
The selector was matching unrelated inputs because it wasn't specific enough. Forward-Port-Of: odoo/odoo#283742 Forward-Port-Of: odoo/odoo#283464
The India payroll settings now accept the correct EPF employee ID format by requiring a 7-digit establishment ID and removing the extra employee account number segment. This helps payroll administrators enter compliant EPF information and reduces validation errors during setup.
Original PR description
Steps to reproduce: - Install Indian localization, and use an Indian company - Go to Settings under Payroll > Indian Localization - Tick the "Employee Provident Fund (EPF)" - Insert a EPF Employee ID Issue: The "valid" format is not correct: XX/XXX/1234567/000/1234567 with the first series of 7 numbers having a flexible range from 1 to 7. The first series of 7 numbers must always equal to 7 (it represents the establishment ID), and the last series of number should be dropped as it represents the employee's unique PF account number. Solution: - Modify the constraint for the variable: - Remove last 7 trailing digits from the constraint. - Make the length of the first series of 7 digits strictly equal to 7. - Update placeholder value and help info. Task: 6482315 Forward-Port-Of: odoo/enterprise#128777 Forward-Port-Of: odoo/enterprise#128421
The Kenya OSCU invoice form now hides the validation message area when there is no message to show. This removes an unnecessary whitespace gap, making the form cleaner and easier to read.
Original PR description
When there is no validation message, an empty div causes a whitespace gap between the header and the sheet in the form view. This commit adds `invisible="not l10n_ke_validation_message"` to the div to prevent this issue. Forward-Port-Of: odoo/enterprise#129364 Forward-Port-Of: odoo/enterprise#129318
The activity menu now opens Project Updates filtered to the current user's relevant activities, such as late, due today, or upcoming items. This prevents users from seeing unrelated project updates in that view and makes activity follow-up more accurate.
Original PR description
**Problem:** Opening a Project Update activity from the activity menu (the clock icon in the systray) lists every project update of every user, instead of the ones carrying the current user's…
**Problem:**
Opening a Project Update activity from the activity menu (the clock icon in the systray) lists every project update of every user, instead of the ones carrying the current user's activities.
**Steps to reproduce:**
1. Schedule an overdue activity on a project update
2. Have a colleague create another project update with no activity
3. Click the clock icon in the systray
4. Under "Project Update", click the "Late" count
**Current behavior:**
The list opens unfiltered and shows all project updates, including the ones of other users and the ones carrying no activity at all.
**Expected behavior:**
The list shows only the updates carrying the user's own activities, restricted to the bucket that was clicked.
**Cause of the issue:**
The activity menu never builds a "my activities" domain. `openActivityGroup` in `mail/static/src/core/web/activity_menu.js` narrows the generic act_window it opens purely through context keys — `search_default_filter_activities_my` plus `search_default_activities_overdue` / `_today` / `_upcoming_all` — and the only domain it forwards comes from `_get_activity_groups`, which is limited to `[('active', 'in', [True, False])]`. A `search_default_<name>` key is resolved against a filter of that name in the model's search view, and is silently dropped when no such filter exists. `project.update`'s search view never declared them, so every key the menu sends is discarded and the action opens on an empty domain.
**Fix:**
`project.project` and `project.task` — the addon's two other `mail.activity.mixin` models — already declare this block of invisible activity filters, as does every other model reachable from the activity menu. Declaring them on `project.update` is what makes the menu's context keys resolvable, and keeps the model consistent with the rest of the codebase instead of special-casing `project.update` on the client side.
opw-6416397
Forward-Port-Of: odoo/odoo#281511This update prevents warning messages and compatibility issues when Odoo uses newer operating system versions of a certificate library. It keeps email and certificate handling working reliably across different server environments without changing user-facing workflows.
Original PR description
pyOpenSSL 24.3.0 deprecated passing its own X509/PKey objects to Context.use_certificate()/use_privatekey(), and started accepting cryptography objects instead. Odoo pins pyopenssl 24.1.0, but the distro builds run the version shipped by the OS: since the test added by f0fb287c6502 covers that path, they now add a warning in the logs. Load the certificate and the key as cryptography objects when the installed pyOpenSSL supports them, keep the previous loaders otherwise. Reference: https://github.com/pyca/pyopenssl/commit/b0cb4b4 This fix is based on https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/odoo/addons/base/models/ir_mail_server.py#L34-L46 runbot-944176 Forward-Port-Of: odoo/odoo#284802 Forward-Port-Of: odoo/odoo#277449
This fix prevents an upgrade-time warning when employee records temporarily have no version data. It makes HR upgrades cleaner and avoids misleading error logs while the upgrade process completes its normal backfill steps.
Original PR description
### Issue: A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version ### Cause: `_get_version` on `hr.employee` falls…
### Issue: A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version ### Cause: `_get_version` on `hr.employee` falls back to `versions[0]` when no version matches the given date But if the employee has no versions at all, `versions` is empty and `versions[0]` raises an `IndexError` ### Steps to reproduce: - Create a database with `hr_attendance` installed in 18.0 - Upgrade to 19.0 Before the fix, a warning is logged during the upgrade ### Notes: An employee without any version is a transient state during upgrade `hr/saas~18.4.1.1/end-migrate.py` backfills a version for every employee still missing one (`current_version_id IS NULL`) once the whole upgrade chain is done Since it only runs at the very end, an employee can still be found without a version by earlier steps (e.g. modules reloading their demo data), which is when this warning was logged Confirmed on an upgraded RunBot database that employees without a version before the upgrade do end up with one once fully completed runbot-241187 Forward-Port-Of: odoo/odoo#284467
Event agenda pages now scroll more smoothly in Firefox and Safari when many agenda items create a horizontal scrollbar. This improves the browsing experience for visitors viewing busy event schedules and avoids distracting shaking while navigating the agenda.
Original PR description
On Firefox and Safari, horizontal scrolling on an agenda with many items stuttered. This was likely caused by triggering too many scroll events, without throttling them. Steps to reproduce: - On Firefox or Safari, run with demo data - Go to the "Design Fair Los Angeles" agenda (click on the event > Talks > Agenda. Alternatively, enter the URL directly: `/event/ID/agenda`, with the right event ID) - Resize the page (or open the dev tools) so that there is a horizontal scrollbar. - Scroll horizontally with a trackpad or with shift + mouse wheel. => The agenda stutters/shakes: as you go to the right, it sometimes slightly goes back left, and vice-versa. You might have to scroll from left to right and right to left a few times to see the issue. Forward-Port-Of: odoo/odoo#285237
AvaTax invoice PDFs now align section or divider rows correctly when the Taxes column is hidden. This prevents uneven table borders and avoids large blank gaps on longer invoices, improving the appearance and reliability of customer documents.
Original PR description
Steps: 1. Turn on AvaTax for a company (connect it to Avalara). 2. In Settings > General Settings > Invoicing, set the Document Layout to Boxed (Box), just for a clear view. 3. Create a customer…
Steps: 1. Turn on AvaTax for a company (connect it to Avalara). 2. In Settings > General Settings > Invoicing, set the Document Layout to Boxed (Box), just for a clear view. 3. Create a customer invoice: - Use the customer with an AvaTax fiscal position and proper address details. - Add a product with an AvaTax category. - Add a section line (a divider/heading row). - Compute Taxes for the AvaTax. 4. Print the invoice as a PDF. 5. Look at the section/divider row. Its cell border does not line up with the other rows. On longer invoices, this can also cause a big blank gap at the bottom of a page. Cause: When an invoice is computed by AvaTax, the Taxes column is hidden from the PDF (this is intentional, since AvaTax shows tax differently). But a different part of the same template decides how wide the section row should be. This part does not know the Taxes column was hidden, so it still counts it. That makes the section row's width wrong by one column, which breaks the table layout in the PDF. Fix: Instead of hiding the Taxes column only in one place, fix it at the source: the variable that decides (does this invoice show a Taxes column) now also checks if the invoice is an AvaTax invoice. Every other part of the template that uses this variable (the header, the tax cells, and the section row width) automatically gets the right answer, since they all read from the same place. Result: - Section rows on AvaTax invoices now have the correct width. opw - 6455674 Forward-Port-Of: odoo/enterprise#129097