Monday, January 19, 2026
31 changes · 19.0
Enhancements to existing features
This update ensures that Thai province names within Odoo are displayed in their native Thai language, improving accuracy and consistency. Previously, these names were stored in English, leading to potential translation issues. This change enhances the user experience for Thai-speaking customers and users.
Original PR description
State names are not translatable in Odoo, so they should be stored in their native language for consistency. This PR updates all Thai provinces to use their native Thai names. task-5484432 Forward-Port-Of: odoo/odoo#243461
This update aligns the invoice payment field with the standard version used in the Community Edition of Odoo. This ensures consistency and simplifies the process for users entering payment information, leading to fewer errors and a smoother user experience.
Original PR description
Added extra fields to align with the widget in CE task-5258726
Resolved issues and error corrections
This update resolves an issue where administrators were unexpectedly redirected to the 2FA login page, even when 2FA was disabled. The fix ensures that 2FA is only triggered for privileged Australian users when it's actually required, improving the login experience and preventing unnecessary security prompts.
Original PR description
Steps to reproduce: -------------------------- 1. Install l10n_au_hr_payroll_api with demo data 2. Logout and login again with `admin` Issue: -------- The login flow redirects to the Two-factor Authentication page even when 2FA is not enforced (auth_totp_enforce disabled) Cause: ------- https://github.com/odoo/enterprise/blob/8e8890f84b1c6b5b54f46e950af63b701c1dde4e/l10n_au_hr_payroll_api/models/res_users.py#L32-L38 Here, it overrides `_mfa_type()` to always return `totp_mail` for privileged Australian users, implicitly triggering the 2FA flow. Since the admin user belongs to [all privileged groups](https://github.com/odoo/enterprise/blob/8e8890f84b1c6b5b54f46e950af63b701c1dde4e/l10n_au_hr_payroll_api/models/res_groups.py#L11-L29), this affects the default login flow even when 2FA is disabled. Solution: --------- Only return `totp_mail` for privileged Australian users when 2FA is actually required by the `auth_totp.policy`. opw-5419671
This update fixes an issue where a popup remained open and displayed an empty white rectangle after deleting content. It also resolved problems with options still being displayed and causing errors when interacted with. This improves the user experience when editing popups.
Original PR description
wip
This update fixes a problem where inviter notifications were sent to portal users when they connected for the first time, causing unnecessary alerts. Now, inviters only receive notifications when an internal user connects. The notification message has also been updated for clarity.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited…
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users. For portal users, this resulted in unnecessary toast notifications and chat window pop-ups. **Current behavior before PR:** --------------------------------- - The inviter is notified when any invited user connects for the first time. - This includes portal users. - Unnecessary notifications and chat pop-ups are shown for portal user connections. **Desired behavior after PR is merged:** ----------------------------------------- - The inviter is notified **only when an internal user** connects for the first time. - Portal users no longer trigger first-connection notifications. - The notification message is updated to: “[Username] just connected for the first time. Wish them luck!” **Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242235
This update removes a restriction that prevented users from inserting records into lists grouped by many2many fields. The previous limitation was unnecessary and blocked functionality without a clear reason. This change ensures users can now seamlessly add records from these grouped lists.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035 Forward-Port-Of: odoo/enterprise#103869 Forward-Port-Of: odoo/enterprise#103161
This update enhances how users manage their consent for online account synchronization. The change allows for a more flexible approach to consent management, addressing a previous technical issue and expanding compatibility with different data providers. This improves user control and data privacy.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update ensures the website's barcode lookup feature works correctly when products are created without a category selection. It aligns the test with a recent community change, preventing newly created products from automatically being published – a key improvement for data accuracy and streamlined workflows.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#104364 Forward-Port-Of: odoo/enterprise#103778
A recent issue prevented Attendance Officers/Admins from correctly accessing the employee onboarding feature within the HR Attendance module. This update restricts access to the onboarding menu for users without full Employee rights, preventing errors and ensuring proper functionality. This change improves stability and usability for users with the appropriate access levels.
Original PR description
# Issue Getting a traceback when trying to access the onboarding menu with just Attendance: Officer access right. # Steps to reproduce 1. Log in with a demo user, with just Attendance: Officer access right. 2. Navigate to Attendances app, and yes, you don't see Configuration, but still you can access the Onboarding menu by typing some random text on search. 3. Now, navigate to the Onboarding menu, and try setting a badge of an employee 4. You get a traceback. # Fix Attendance: Officer/Admin without Employee rights (either Officer/Admin) will not be able to access the Attendances Onboarding menu. Only the user with both the rights can access it. task-5267189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Other Input' section in the payroll module incorrectly displayed trailing zeros for negative salary attachment amounts. The fix adjusts a widget to properly handle negative values, ensuring accurate count representation. This improves the user experience and data integrity for negative salary attachments.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466 Forward-Port-Of: odoo/odoo#243074
This update resolves a recurring issue where the quotation signing tour occasionally failed to complete correctly. The fix adds a deliberate pause within the tour to ensure all interactions have finished loading, resulting in a more stable and reliable user experience. This improves the overall efficiency of the sales process.
Original PR description
This commit fixes the flaky quotation signing tour in sale_management by adding an explicit step to wait for interactions to fully load before proceeding with the next steps. runbot error-224021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242746
This update fixes a usability issue where the filter button in list views was hidden behind the column resize handle, making it difficult to click. By increasing the button's layering, the change ensures a more consistent and intuitive user experience for selecting filters. This improves overall ease of use.
Original PR description
Description of the issue/feature this PR addresses: The filter button in lists views appear under the column resize handle, meaning that the handle can be grabbed accidentally when trying to click the filter button. Layering the button above the handle makes it more consistent to click. Video showing before/after behavior: https://drive.google.com/file/d/1Tmj-qX3nxsoG-QfO4LpGdp0adAfC69J5/view?usp=sharing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users in French (fr_FR) from importing bank statements through the document app. The fix corrects a language-dependent ordering of import actions, ensuring the import process functions correctly. This improves the usability of the document app for all users.
Original PR description
**PROBLEM** You can't import a bank stamement from the document app in some languages (ie. fr_FR). **STEP TO REPRODUCE** 1. install account_document 2. upload a camt file to the Finance/ folder (you…
**PROBLEM** You can't import a bank stamement from the document app in some languages (ie. fr_FR). **STEP TO REPRODUCE** 1. install account_document 2. upload a camt file to the Finance/ folder (you can find them in account_bank_statement_import_camt) 3. switch the user language to french. 4. try importing the camt file, it will fail saying you have no right to execute this action in the folder. **CAUSE** In the data of document_account, the children actions of the import bank statement action don't have any sequence defined. This means there sequence will have a default value (5). Because they have the same sequence, their order of execution depend on their name, and it could changes depending on the language loaded. In English, the order is : 1. import the bank statement 2. move the file to some folder In French, the order is : 1. move the file to some folder 2. import the bank statement The import action doesn't work, because the action can't be executed in the folder we moved the file into. opw-5413409
This update resolves an issue where demo data installation caused incorrect packaging behavior. Specifically, a pre-existing package name interfered with the test process, leading to items being packed into the demo data package instead of new ones. The fix ensures a unique package name is created during demo data installation.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802)
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from a subscription end date set for December 31, 2026, causing the system to incorrectly close recurring invoices. This ensures the subscription functionality operates correctly regardless of the current year.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658
This update corrects a bug that caused an unnecessary 'Resume' prompt to appear after large CSV imports, even when all records were successfully processed. The fix ensures the 'Resume' prompt only appears when a batch is truly incomplete, improving the user experience and preventing confusion. This change enhances the reliability of the import process.
Original PR description
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce:…
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce: 1. Create a CSV file with enough records to trigger at least 2 batches 2. Go to any list view and select "Import records". 3. Upload the file and click "Import". 4. Wait for the import to complete. 5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears. The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes. * In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated. * If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch. * `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value. This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`). opw-5343837
This update fixes an issue where newly created appraisal templates weren't appearing in the selection list when launching a campaign. The problem stemmed from a technical error excluding templates based on company settings. The fix ensures that all templates, including newly created ones, are correctly displayed, streamlining the campaign setup process.
Original PR description
**Version:** - 19.-0 **Steps to reproduce:** - Install the Appraisal module. - Click the Launch Campaign button. - Open the wizard and create a new appraisal template. **Issue:** - Newly created appraisal templates do not appear in the selection list. **cause:** - When a new template is created, the company field is automatically set by default. - However, the domain used to fetch templates does not include the company condition, causing the newly created template to be excluded from the results. **Solution:** - remove domain and use check_company=True to get the company. Task-5416593
This update corrects a data issue within the Odoo Enterprise system related to Chilean SII (Service de Impuestos Internos) reporting. Specifically, it adds the necessary information for the 'Alto Hospicio' Regional Office, ensuring accurate tax reporting compliance. This ensures the system correctly handles regional office details for tax purposes.
Original PR description
Oficina Regional Alto Hospicio Comuna Alto Hospicio Región Taracapá Forward-Port-Of: odoo/enterprise#102712
This update simplifies the GSTR report generation by removing a redundant credit note warning. Previously, a warning appeared on invoices when a credit note was issued, which has now been corrected. The warning is now automatically cleared when the credit note is fully processed and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104565 Forward-Port-Of: odoo/enterprise#102106
This update simplifies the Odoo Point of Sale receipt by removing the unit price display for individual items within combo products. This change, aligned with a recent Odoo 19.0 update, reduces customer confusion and provides a cleaner, more straightforward receipt experience. The removal ensures the total combo price is clearly presented.
Original PR description
Steps to reproduce: - In POS, select a combo product, confirm, and pay for it. - When the receipt is shown, the price per unit for the combo and for each product inside the combo is showing. Issue: - The price calculation of the individual products constituting the combo and showing the unit price of the combo when the combo quantity is 1 is confusing for the customer. Fix: - Since Odoo 19.0, we stopped showing prices for child lines in a combo on the cashier side; the same logic was followed here for the receipt. - The price per unit for a combo isn't necessary to appear when the quantity of the combo is 1.
This update fixes an issue where contacts with duplicate courses were incorrectly merged, leading to data inconsistencies. Now, the system prevents merging contacts with identical courses, displaying an error message to the user. This ensures data accuracy and a better user experience when managing attendees for website slides.
Original PR description
Expected Behaviour: Contacts with Duplicate courses should not be merged and the merge should fail. Actual Behaviour before the Fix: Contacts with duplicate courses are getting merged and the duplicate course is kept in the destination contact. Behaviour with the Fix: Contacts with duplicate courses are blocked from being merged and an error message is shown to the user saying that the reason the merge is blocked is a duplicate course. Steps to reproduce: 1- Go to one of the courses 2- Add two attendees to the course 3- Go to Contacts App 4- Select the two attendees you added to the course 5- Try merging the two contacts Before the fix, the merging will happen. After the fix, the merging will stop and an error message will appear.
This update fixes an issue where the Odoo Studio export process incorrectly excluded certain related and computed fields. The team has refined the exclusion logic to accurately handle these fields, ensuring a more reliable export experience. This change was validated by the Industry team and addresses a previous bug.
Original PR description
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but…
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but there are subtle differences that cause the excluded fields to sometimes be wrong. While analyzing the heuristic with the ORM team, we decided to separate the computation of related and computed fields. After this commit, we have a refined computation of excluded fields for related and computed fields: - for computed fields (that are not related ones), we always exclude them except when they are writeable (i.e. stored or with inverse) - for related fields, we always exclude them when the relation is in the list of related models to exclude. We also exclude them when they are not writeable on the current record only (not the source record), except if they are required. Some export scenarios have been tested manually and brought with them adaptations in the hardcoded lists of default fields to exclude. The Industry team agreed with these changes. Task id: opw-4974787
This update fixes an issue where sorting of picking records wasn't functioning correctly due to a technical detail in how Odoo compares related data. The change ensures that picking records are accurately sorted based on their identifiers, improving data consistency and reliability. This resolves a potential problem with reporting and data analysis.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512 Forward-Port-Of: odoo/enterprise#104561
A test used to fail intermittently due to a race condition during inventory adjustments. This update ensures the test accurately reflects the process by closing a notification message after the first adjustment, preventing confusion and ensuring correct results. This improves the reliability of our inventory testing.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104481
This update resolves a technical issue where Stripe was not properly reporting the reason for failed expense authorization requests. Specifically, when Stripe reached its spending limit, a 'authorization_controls' reason wasn't displayed. This change adds a user-friendly translation of this reason, improving the clarity of error messages and enabling better tracking of expense authorization problems.
Original PR description
When Stripe refuses an authorization due to the maximum allowed being reached, there is a specific technical reason "authorization_controls" that wasn't mentioned in their documentation. This adds the reason with a user-friendly translation See [doc](https://docs.stripe.com/api/issuing/authorizations/object?api-version=2025-01-27.acacia#issuing_authorization_object-request_history-reason)
This update corrects a visual glitch where dynamic website snippets would briefly appear and disappear. The issue stemmed from a change in how snippets were styled, and this commit restores the original design: snippets now start with no visibility class, relying on content to determine display.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523 Forward-Port-Of: odoo/odoo#240475 Forward-Port-Of: odoo/odoo#238305
This update corrects a bug where free product rewards in the loyalty program were incorrectly displaying a non-zero price in the shopping cart. The issue stemmed from an override in the `sale_subscription` module that was causing unnecessary discount calculations. This fix ensures accurate pricing for free loyalty rewards.
Original PR description
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on…
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on configuration. 3- Create a `promotion`: - rule: minimum quantity: 0, minimum purchase: 10 - reward: free product, quantity: 1 4- Set a non-zero price on reward product from product page. 5- Create a product with price of 6 and publish it on the website. 6- On website, add 1 unit of created product to cart. 7- Open cart, and increase the quantity. 8- As you see the free product is added to cart but the price is non-zero. ### Cause: Based on #89397, the reward line have the discount of 100. In the `_compute_discount` this discount is set to 0: https://github.com/odoo/odoo/blob/e48a7f1b03f23a4c96e35ee4350029439ec73e47/addons/sale/models/sale_order_line.py#L797 As `compute_discount` only depends on `product_id`, `product_uom_id`, `product_uom_qty` this shouldn't cause issue. However, in `sale_subscription` its override includes `sale_order.plan_id` as dependency: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/sale_subscription/models/sale_order_line.py#L86-L90 Which setting `plan_id` to `False` here makes discount to be recomputed: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/website_sale_subscription/models/sale_order.py#L27-L30 ### Fix: This can be avoided by filtering reward lines in a `_compute_discount` override. As none of reward lines regardless of reward type are expected to have a discount calculated this fix will not break any other flows. It's noteworthy to mention that in the test, `_compute_discount` is directly called in order to mimic the flow without the need to install `sale_subscription`, as the `sale_subscription` is not root cause of the issue and the same issue could reproduced by any other modules overriding `_compute_discount`. opw-5485796
This update resolves a minor issue within the email invite tour process. Previously, the tour's speed caused conflicts with the automatic opening of the channel member list. This fix ensures the tour waits for the member list to open, preventing a rare but disruptive behavior. This improves the overall user experience for inviting new members to channels.
Original PR description
The `test_01_invite_by_email_flow` test ensures we can invite partners to a channel using their email. The tour opens the invitation panel, then sends an email. However, it conflicts with the auto-open of the member list. Sometimes, the member list opens after clicking on the invite panel button. This only occurs because the tour runs very fast. It's very unlikely that this occurs to a real user. This commit fixes the tour in order to wait for the member list to open initially. runbot-237994 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 update fixes a performance issue in the translation sidebar. By preloading translated elements, the sidebar now renders fully before tests begin, preventing delays and ensuring tests pass consistently. This improves the reliability of our translation testing process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
This update prevents unnecessary WebRTC testing when the IoT Box record is a stable version, which doesn't support this feature. This avoids a potential performance issue and ensures the 'Test' button functions correctly for the intended use case. It's a minor fix improving the user experience.
Original PR description
We now avoid testing WebRTC when pressing "Test" button on the IoT Box record, when the IoT Box is a stable IoT Box (which does not support it). Task: 5490291
This update resolves a technical issue that was preventing embedded actions from functioning correctly in our web interface. The fix involved adjusting a test to accurately simulate user interaction and ensure the action is correctly triggered. This improves the reliability of embedded actions for users.
Original PR description
In this commit, we fix an embedded action test that failed because when clicking on the sliders to show the top bar, the dropdown was directly opened as there is only one visible action (since this commit: https://github.com/odoo/odoo/pull/208005/commits/a5709e870e033b83d50a2f581c81cceb2a98d91b). We then adapt the test to wait for the dropdown to open automatically, and then when it's the case, create the new custom embedded action. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr