Tuesday, December 17, 2024
6 changes · master
Resolved issues and error corrections
Browser-based automated tests now better match how a focused page behaves, preventing failures caused by Chrome not treating the page as active. This improves confidence in test results for areas such as live chat, accounting, bank reconciliation, and the web editor without changing user-facing functionality.
Original PR description
Apparently in normal mode (and thus the new headless mode) Chrome does not focus the document. The `activeElement` is correctly set, but `document.hasFocus()` always returns `false` and per-element focus events are suppressed. That makes tests testing or needing focus fail in the new headless mode as well as well as impossible (or at least frustrating) to `debug`. Enabling "focus emulation", which corresponds to the "Emulate a focused page" UI option, seems to resolve the issue. Fixes reliably failing tests - `/im_livechat:ExternalTestSuite.test_external_livechat` - `/account:TestUI.test_01_account_tax_groups_tour` - `/account_accountant:TestBankRecWidget.test_tour_bank_rec_widget` - `/web_editor:TestOdooEditor.test_odoo_editor_suite`
This fixes an automated survey form test so it works consistently with the newer headless testing engine. The change helps prevent false test failures by ensuring the relevant answer field is fully visible before interaction.
Original PR description
Because reasons the answers field may end up partially outside the viewport when we try to click on it. In the new headless engine, this apparently causes the field to be visible so the "Add a second trigger" trigger succeeds *but* some events to still be suppressed, and in this case the `click` doesn't cause the dropdown menu to open and the tour fails on "Add the second question's second answer as trigger". Ensuring the element is fully in view seems to fix the issue.
When users sort a related list inside a form, that on-screen order is now preserved after they save changes to the form. This prevents confusion and extra re-sorting during data entry, though the saved database order is unchanged when reopening the form later.
Original PR description
Have a form view with an x2many list. Click on a column header to sort the list by a given field. Then do a change in the form and save. Before this commit, the order of the x2many was lost. With this commit, it is kept. Note that the order is UI only, it doesn't impact the order of records in the relation in database, i.e. if the user leaves and comes back, the order will be lost. task~4366529 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
The point of sale order line now uses the same formatted quantity shown to users, preserving decimal precision and rounding. This avoids mismatches in displayed product quantities and helps keep POS behavior and tests consistent.
Original PR description
The `quantityStr` variable in the command line must be the one displayed in the command display, not the `qty` variable.
This error caused the quantity to be displayed without decimal point precision and rounding. This led to errors in the tests.
For example:
`ProductScreen.clickDisplayedProduct("Wall Shelf", true, "1.0"),`This update aligns the Italian Point of Sale fiscal document code with the latest POS naming conventions. It helps keep receipt and invoice flows compatible with recent platform changes without changing business workflows.
Original PR description
Rename methods used to fit the new camelCase naming scheme of POS methods instead of the previously used snake naming scheme
A bug fix ensures bank reconciliation records keep their chosen line ordering after saving. This prevents lists from unexpectedly reordering, helping accountants continue their work with a consistent view.
Original PR description
This commit adapts a call to _parseServerValues with respect to a change in community (odoo/odoo#190691). task~4366529