Friday, March 1, 2024
31 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where job applicants were unable to upload documents in the recruitment module. The problem was caused by an incorrect model configuration that prevented uploaded documents from being properly stored and displayed. With this fix, applicants can now successfully upload and manage their documents.
Original PR description
**Description of the issue/feature this PR addresses:** In the kanban view of all applicants within the recruitment module, an issue arises when applicants attempt to upload documents, this functionality is currently malfunctioning. --- **Current behavior before PR:** Document uploads by applicants are failing. --- **Desired behavior after PR is merged:** Applicants should be able to successfully upload documents. ___ **Fix:** The PR addresses the problem by modifying the default_res_model in the context. This adjustment is crucial as the current setting results in an incorrect model name, preventing the display of uploaded documents in this model. task-3579833 Forward-Port-Of: odoo/enterprise#57717 Forward-Port-Of: odoo/enterprise#52029
A recent update to journal options in account reports inadvertently caused journal groups to be incorrectly selected as individual journals. This fix ensures that only actual journals are selected, not journal groups, restoring the correct behavior for financial reporting.
Original PR description
In #25518, the journal options were reworked to better use journal groups and multi-company reports. However, this caused a regression where _get_options_journals would select journal groups as journals This change uses the 'model' key in the journal options to only select the 'account.journal' ids --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#56730
This fix removes an incorrectly added country_code field from the Mexico EDI module that was accidentally included during a merge conflict resolution. The field should not have been present and its removal ensures the module functions as intended without unnecessary data duplication.
Original PR description
Erroneously added (https://github.com/odoo/enterprise/commit/0695afece962ad1c5d3dafc930b00c0e16d30b25) coutry_code field when reselving merge conflict. Forward-Port-Of: odoo/enterprise#57774
This fix resolves an issue where purchase orders and delivery quantities were being doubled when adding storable products to subscription upsells. The problem occurred because stock rules were being triggered twice—once from the parent subscription and once from the upsell. The fix ensures stock rules are only triggered from the upsell, preventing duplicate orders and quantities.
Original PR description
Steps to reproduce: - Create a storable product invoice on delivered qty MTO enabled - Create a subscription for a service product and invoice it - Create an upsell and add on it the storable product Bug: PO line and delivery quantities are doubled Fix: only trigger stock rules on the upsell not from the parent SO opw-3696134 Forward-Port-Of: odoo/enterprise#57590
This fix corrects a critical issue where UPS return labels were being generated with reversed addresses—showing the customer as the receiver and seller as the sender, when it should be the opposite. Return labels are used to ship items back from customers to sellers, so the addresses must be correct for the return process to work properly.
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
This update makes the Task Gantt View component available for developers to reuse and customize more easily. Previously, developers had to access the component through a technical registry, but now it can be imported directly. This improves the development experience and makes it simpler to create custom Gantt-based views for project management.
Original PR description
Before this commit, the taskGanttView object was not exported and so if someone would like to override that object, he will have to get that object in the views registry. This commit allows to export taskGanttView from that file to easily use it to create another Gantt JS based on that one instead of getting the object from the registry. task-3776786
This fix improves how non-UK companies using UK tax positions submit VAT reports to HMRC. The system now automatically handles foreign VAT numbers correctly and removes the need for users to manually strip the 'GB' or 'XI' prefix from VAT numbers before submission, making the process simpler and less error-prone.
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
This update synchronizes the intrastat code lists with 2024 regulatory standards by adding new codes and removing outdated ones. The changes include setting effective dates for new codes and expiry dates for removed codes to ensure accurate international trade reporting and compliance with current regulations.
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This update fixes a technical issue where video calls could experience problems if a channel was removed while the call was still loading. The fix prevents these timing conflicts, ensuring calls remain stable and don't encounter unexpected errors when channels are closed during the loading process.
Original PR description
Before this commit, there could be race conditions in which a channel could be removed while the call was still loading, this commit prevents this issue. task-3660964
This fix prevents the Point of Sale system from incorrectly creating expense entries when selling consumable products. Previously, when a consumable product was sold in a POS session without an invoice and the session was closed, an unwanted expense entry would be added to the accounting records. This fix ensures consumable products are properly excluded from cost of goods sold (COGS) calculations.
Original PR description
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156
This update fixes an issue where product attributes with multiple selection options were not appearing in the product configurator popup when using Point of Sale on mobile devices. Customers can now properly select from all available product options when adding items to their order on mobile, improving the checkout experience.
Original PR description
Current behavior: When adding a product with a multi selection attribute, the attribute is not displayed in the product configurator popup. This only happens when opening it on a mobile device. Steps to reproduce: - Add a product with a multi selection attribute - Open PoS - Add the product to the order - The attribute is not shown on the product configurator popup opw-3711164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where dropdown menus (like user menu and language selection) were not visible when clicking on them in website headers with the "Fixed" scroll effect. The fix ensures dropdowns appear properly by adjusting how the header behaves during scrolling and automatically scrolling to the top when users interact with dropdowns.
Original PR description
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling…
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling the page until it completely disappears. To reduce the height of this element without leaving its contents fully visible (because they maintain their height), we added an "overflow: hidden" property on it. However, this "overflow: hidden" introduced a bug fixed by this commit. Due to this, the dropdowns within the "o_header_hide_on_scroll" element, like "user menu" dropdown or "language selection" dropdown, became invisible. Steps to reproduce the bug: - Go to Website edit mode. - Click on the header. - Choose the "Menu - Sales 2" template from the options. - Select the "Fixed" Scroll Effect from the options. - Click on the "User Menu" dropdown in the header. - Bug: The dropdown menu does not appear. The same issue occurs if you type something in the search bar; the dropdown with the results does not appear either. To fix this, we don't apply "overflow: hidden" on the "o_header_hide_on_scroll" element when the page hasn't been scrolled yet. And if the page has been scrolled just a bit and the user clicks on a dropdown or the search bar, we scroll the page to the top first, and then display the dropdown menu. This commit also add a test tour to prevent the bug from reappearing. [1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb opw-3698887
This fix resolves an issue where QR codes were not appearing on automatically printed receipts at the point of sale. The problem occurred because the QR code image was being fetched after the receipt was already sent to the printer. The fix ensures the QR code image loads completely before printing, so customers receive complete receipts with the QR code included.
Original PR description
Prior to this commit, enabling auto receipt printing resulted in the QR code not being printed on the receipt. This was due to the QR image being fetched post printing. This commit addresses the issue by first loading the QR code image, then sending it to the printer, ensuring its presence on the printed receipt. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where custom ribbon colors on products were reverting to the default color after saving changes. Users can now set custom background colors for product badges/ribbons on the shop page and have those changes persist correctly.
Original PR description
Before this commit, the `bg-primary` class was overwriting the `bg_color` set by the user after saving changes as it has the `!important` tag. Steps to reproduce the issue: 1. Go to Shop page on website 2. Enable edit mode 3. Pick a product and create a new Badge (ribbon) 4. Change the background color and save changes -> color reverts to `bg-primary` This commit fixes this behavior by adding the `!important` tag to the `bg_color` so that it properly overwrites the `bg-primary` color. opw-3734598 Forward-Port-Of: odoo/odoo#155040
This update improves how the Calendar module handles default values for relationship fields (many2one). The change enables the Appointments module to properly retrieve and set default values for linked records, making the quick event creation process more reliable and consistent across modules.
Original PR description
function getDefaultValuesFromRecord has been adapted so that can be utilized in the appointment module to retrieve default values for the fields. Related Enterprise pr:https://github.com/odoo/enterprise/pull/56123 Task-3679307
This fix resolves an issue where invoices with fixed taxes, discounts, and multiple quantities were not being imported correctly from UBL/CII XML files. The system now properly accounts for line quantities when calculating fixed tax amounts during import, ensuring accurate invoice data is captured. This is particularly important for businesses using electronic invoice formats with complex tax structures.
Original PR description
Fix import of invoices with fixed taxes, discount and quantity > 1. When exporting the UBL xml, we compute the fixed tax amount of the line and create a charge on the line with this amount (e.g. see the test). When importing this xml, we read the charges with code 'AEO' on each lines and use the `amount` and `name` to search the fixed taxes on the database. This issue is that we do not take the quantity of the line into account: if we have a line with quantity = 2, and the fixed tax amount = 1, the xml indicates a charge of 2. When we import the line, the amount of the fixed tax to be searched should be 2 / quantity = 1. In addition, add an test for the export and import of a line with quantity > 1, a discount, a fixed tax and a regular tax. opw-3717306 Forward-Port-Of: odoo/odoo#155468 Forward-Port-Of: odoo/odoo#153639
This fix resolves an error that occurred when users with limited employee access tried to search for employees in timesheet entries. The system now correctly uses the appropriate employee data view based on each user's permission level, ensuring that users only see employees they're authorized to access.
Original PR description
Steps to reproduce ================== - Install Timesheets - Login as Admin - Edit the access rights of Mark Demo: * Timesheets: "User: all timesheets" * Employees: "None" - Logout and login as Demo - Go to a project task - Switch to the Timesheets notebook - Add a new line - Click on the employee field > Search More => An error occurred Cause of the issue ================== The hr.employee.public model is an SQL view of the hr.employee table with differents permissions. Since the user doesn't have the hr.group_hr_user group, the model hr.employee.public should be used and not hr.employee. Since [0], the model is switched depending on whether the user has the appropriate group. The EmployeeFieldRelationMixin is used and defines a getter for the relation. That relation was not propagated to the Many2OneField. Solution ======== Pass the relation to the many2OneProps. --- [0]: https://github.com/odoo/odoo/pull/136786 opw-3765393
This fix ensures that when a customer places an order with zero total amount in the self-service kiosk, they now receive a printed receipt instead of being redirected to the home page. The order confirmation and receipt are now handled consistently regardless of whether payment is required, improving the customer experience for promotional or complimentary items.
Original PR description
Before this commit: =================== If there is an order with a total amount of 0 in kiosk mode, then after the cart page it is redirected to the home page without printing a receipt. After this commit: ================== with this commit, if an order amount is 0 then it will redirect to the confirmation/receipt page like a normal order with the amount without redirecting to the payment page. task - 3773450
This update fixes a spelling error in the Belgian localization module where the French abbreviation for the National Social Security Office was incorrectly spelled as "ONNS" instead of the correct "ONSS". This ensures accurate account naming and compliance with official Belgian terminology in the system.
Original PR description
Office National de Sécurité Sociale (ONNS) should be (ONSS).
This fix resolves an issue where the document upload button was hidden in the applicant view when the Documents for Recruitment setting was disabled. The fix ensures the upload button remains visible and functional regardless of the Documents setting status, allowing applicants to properly upload documents to their profiles.
Original PR description
**Description of the issue/feature this PR addresses:** In the kanban view of all applicants within the recruitment module, an issue arises when applicants attempt to upload documents. --- **Current behavior before PR:** upload button is hidden while uncheck the settings from Documents for Recruitment. --- **Desired behavior after PR is merged:** upload button is visible while uncheck the settings from Documents for Recruitment. --- **Fix:** The PR addresses the problem by modifying tree view of ir.attachment and default_res_model in the context. This adjustment is crucial as the current setting results in an incorrect model name, preventing the display of uploaded documents in this model. task-3579833 Forward-Port-Of: odoo/odoo#155747 Forward-Port-Of: odoo/odoo#150593
This fix resolves a problem in the color picker tool where clicking on hex color codes or RGBA values would incorrectly reset the cursor back to the original text instead of allowing users to edit the color value. The fix ensures that when users click on color input fields within the color picker dropdown, their selection is preserved so they can properly modify the color code.
Original PR description
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create…
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create a note , type anything and apply custom color - When clicking on the hex color code , the cursor is alwyas set back to the text. Origin of the issue: ==================== The behavior was introduced by https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3 In the click listener, we always reset the comuted selection wich reselects the original text. When clicking on empty space on the dropdown menu, it happens too but it doesn't matter since the menu closes anyway, but clicking on text input fields that you want to update will be a problem since the menu doesn't close but the text get reselected. Solution: ========= To overcome the problem of resetting when clicking on the dropdown, we first check if the click is on the colorpicker or not, if Yes do nothing and skip this. task-3648629 Forward-Port-Of: odoo/odoo#149480
This update removes an outdated requirement for Norwegian Bronnoysund field data when creating electronic invoices. The system now uses the newer, more flexible Peppol endpoint fields that were introduced in version 16.2, making it easier for businesses to configure their invoice routing without needing localization-specific fields.
Original PR description
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node. Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field. Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled. [1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119 opw-3763725 Forward-Port-Of: odoo/odoo#155604
This fix resolves an issue where user preferences were being lost during a session when reordering apps in the home menu. The system was incorrectly discarding unchanged preference settings instead of preserving them. Now, only the settings that have actually changed are updated, while all other user preferences remain intact.
Original PR description
User settings is used to store user's preferences, in web we use it to store the home menus apps order and in mail for various settings like push to talk key, discuss sidebar preferences, etc. Before…
User settings is used to store user's preferences, in web we use it to store the home menus apps order and in mail for various settings like push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service overrided all the previous key that has not been changed because it kept only the changed keys returned by the backend. Leading to preferences being lost during the session when reordering the home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```This update fixes a problem where Raspberry Pi 5 devices were generating excessive error messages in system logs when trying to detect connected displays. The fix adds better error handling to prevent these messages from cluttering the logs, making the system more stable and easier to monitor. Once devices receive this update, they will handle display detection issues gracefully without filling up the logs with errors.
Original PR description
Currenlty, on raspberry pi 5 our dislay interface is invading the logger with errors due to the absence of both tvservice and the required vcgencmd methods to identify the connected displays The goal…
Currenlty, on raspberry pi 5 our dislay interface is invading the logger with errors due to the absence of both tvservice and the required vcgencmd methods to identify the connected displays The goal of this PR is to avoid this  While searching for a solution to properly detect displays on a raspberry pi 5 we can avoid the excessive log errors by protecting the subprocess calls. When used with vcgencmd, the python wrapper of 'vcgencmd' bash utility is missing the 'Vcgencmd().display_power_state()' method on raspberry pi 5, which causes a subprocess.CalledSubprocessError because the wrapper itself is missing a try/except block arount its subprocess call [here](https://github.com/sushantnadkar/vcgencmd/blob/68578dd887f2e0f62c1e8bf95323574cfc489be0/vcgencmd/vcgencmd.py#L18) Tvservice is not used on new rpi models so there is no need to protect it While the errors will still be present in the logs for a fresh image at the moment, once an rpi5 is connected to a database, it will receive the code from this PR and will handle the exceptions more gracefully [task-3771334](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form&id=3771334) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155615
This update fixes an unreliable automated test for scheduling activities in the mail module. The test was failing inconsistently across different build environments because it relied on a fixed timeout that wasn't long enough. The fix replaces the timeout with a more reliable check to ensure the activity type data is ready before proceeding, making the test more stable across all builds.
Original PR description
Since PR #154105, `mail_activity_schedule_from_chatter` test was failing on some runbot builds. The problem is, the `timeout` to make sure the activity type input is ready (has its data) to click again, is not enough for all builds. Instead of using timeout (which is not same for different builds), we can add an extra step to check if the activity id input has its data after clicking on dropdown, to proceed to the next steps. fixes runbot-57738