Daily updates from Odoo
Friday, January 24, 2025
35 changes
1 change
Resolved issues and error corrections
This fix restores the system's ability to recognize cancelled time off records when checking related resource availability. It helps avoid incorrect scheduling or leave calculations caused by cancelled entries being treated improperly.
Original PR description
In https://github.com/odoo/odoo/pull/127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347
3 changes
Resolved issues and error corrections
Project update stat buttons now refresh their counts when users change the selected companies. This helps teams working across multiple companies see accurate project-related figures in the right-side panel.
Original PR description
Before this commit, the stat buttons count values in the project updates right-side panel were not updated when the user was changing companies in the company selector. After this commit, the counts displayed in the stat buttons are updated based on the selected companies. task-3689065 related-https://github.com/odoo/odoo/pull/150870
Indian payroll payslips no longer show the internal payslip ID in the page breadcrumb. This makes the payslip screen cleaner and avoids exposing unnecessary internal identifiers to users.
Original PR description
Steps to Reproduce: • Install the l10n_in_hr_payroll module. • Open payslip. you can see id of payslip in breadcrumbs. Fix: Removed id from the name of payslip. task-4402393
This fixes an error that could appear when users clicked a shift popover in Planning. The change helps staff view shift details without interruptions, improving reliability for sales planning workflows.
Original PR description
This PR fixes a traceback occurring in planning when clicking on the popover of a shift, due to an async method not being properly overridden. Task-4506661
31 changes
Resolved issues and error corrections
Messages sent in group chats with an @ mention are now correctly recognized as the sender's own messages, so they use the expected green bubble. The fix also prevents hidden errors during mention lookup from disrupting message display updates.
Original PR description
Before this commit, when posting a message with a `@` mention in group chat, the message had blue bubble instead of green bubble. This color means that the message is not recognized as a self…
Before this commit, when posting a message with a `@` mention in group chat, the message had blue bubble instead of green bubble. This color means that the message is not recognized as a self message. Steps to reproduce: - make group chat - post a message with `@` mention => the message bubble is blue rather than green This problem is a consequence of https://github.com/odoo/odoo/pull/176758 In this PR, when mentioning from any channel, the `groups_id` of partners from mention suggestions could be returned. If the users are in the group of group_public of channel, this means these partners could be invited in the channel. This is useful to make them elligible for `@` mention even when they are not member. This partial knowledge of the group id of partner is provided to client code so that the suggestions are shown too, since the list results in the JS modeling. This PR however introduced a silent crash in JS code from this LOC: https://github.com/odoo/odoo/pull/176758/files#diff-515b5eba2d7fbff9826774f16c701063cfd9c95967287eaec36b16db66ef8c48R102 The server data may send `[ADD, null]` for partner `groups_id`, which is the case in group chat. The internal code of JS models does not expect this kind of command data: it crashes because `ADD` command assumes the other part is genuine data or record(s). However `null` means nothingness, so internally the `target` is missing thus it leads to a crash in the internal code of JS models. Why is the crash not bubbled then? Well, this is silently ignored in business code by the fetch mention function, in `fetchSuggestions`. The silent crash is suspicious, but not necessarily the primary cause of the problem... No no no. Internal code of JS models has made a bigger sin: the silent crash aborts the pending update cycle, thus not flushing it. This is a huge problem, because the implementation of update cycle is made in a way that its integrity depends on no crash during the update cycle. That's because the synchronous processing of update cycle defines layers of update cycle with a global counter that is incremented and decremented. The 1st update cycle layer manages the flush, while the other layers do the operations without flush. If there's a crash during the update cycle, the update cycle is aborted but its counter is preserved. Let's say the counter is 4: that means the update queues are never flushed, because the only way to change this value is through `MAKE_UPDATE`, and this function only preserves its value or temporarily increases it. So what's the deal with the green bubble being blue? Well, there's a computed field `isSelfAuthored` that was never computed because of the silent crash. Thus it had the default value `false` rather than `true` for self messages. While the symptoms show blue bubble instead of green bubble, which feels cute but not a big deal... This was actually a side-effect of a much much bigger issue that compromises the overall modeling of JS. Yes, that's like having an eye tickling, thinking that we're just tired but it's actually a symptom of final stage cancer. Do not worry though: this commit doesn't cure cancer, but it fixes this problem as follow: `fetchSuggestions` in business code should not silently catch non-abort errors, and bubble it.
The messaging menu now correctly refreshes its notification count when a user dismisses the browser notification prompt. This prevents misleading unread counts and keeps the messaging indicator accurate for users.
Original PR description
**Current behavior before PR:** Since [1](https://github.com/odoo/odoo/pull/192336) when a user discarded the `Turn on notifications` option from the messaging menu, the systray notification counter was not updated. This issue occurred due to an incorrectly written condition. **Desired behavior after PR is merged:** The issue is resolved, and the systray notification counter is correctly updated when the user discards the native notification prompt. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a payment reconciliation issue that prevented commission purchase requests from being generated when invoices were paid through bank reconciliation without an outstanding account. This ensures commission-related follow-up documents are created reliably after customer invoices are paid.
Original PR description
## Issue: Commission RFQ is not auto-generated for journals(payment method lines) without outstanding accounts when an SO invoice is created, a payment is created for it, and it gets reconciled with…
## Issue: Commission RFQ is not auto-generated for journals(payment method lines) without outstanding accounts when an SO invoice is created, a payment is created for it, and it gets reconciled with a bank statement. ## steps to reproduce: 1. go to bank journal and remove the outstanding account from the manual payment method line 2. on the CRM app create a partner commission program with a percentage and attach it to a partner 3. create a sale order with the partner as a referrer and confirm it 4. create an invoice from the sale order and validate it 5. register a payment for the invoice using the manual payment method 6. create a bank statement line and reconcile the invoice with it in the bank reconciliation widget 7. check the purchase app and see that no RFQ was created ## Solution: - Before version 18.0 (see [this PR](https://github.com/odoo/odoo/pull/180813)), automatically assigning a default outstanding account ensured that every payment created a journal entry. This journal entry was reconciled with the invoice, triggering `invoice_paid_hook` as the invoice transitioned from `not_paid` to `in_payment`. `_reconcile_pre_hook` filtered out payments already marked as `in_payment` to avoid double-triggering `invoice_paid_hook`. However, since the default outstanding account is no longer assigned automatically, `invoice_paid_hook` is not triggered when an invoice transitions from `not_paid` to `in_payment` and then to `paid` by reconciling it with a bank statement line. - to address this issue we edited `_reconcile_pre_hook` and `_reconcile_post_hook` to handle in payment invoices in these cases. OPW-4282724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live chat window will now automatically open only once per visitor when configured to do so. This prevents repeated popups on every page visit, reducing annoyance and improving the website visitor experience.
Original PR description
Livechats can be configured to automatically open a chat window when a visitor opens a page. This should only occur once per visitor not to bother visitors. Before this PR, this occured each time the visitor accessed the page. The information on whether the popup was donce once is stored in the local storage but is incorrectly checked. This PR fixes the issue. opw-4503667
This fixes a visual issue on the online shop page where product grid borders could overlap nearby products or appear behind product images after changing product sizes. The correction keeps the grid layout clean and avoids confusing storefront presentation for shoppers.
Original PR description
Issue: in the /shop page, using the grid style if we change the size of a product on another column than the first one, the border of the grid will appear on the product or behind its image. This is due to the width 100vw which extends behind the product's current width and overflowing on other products of the same row. task-4513299 opw-4447224 | | |--------| --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing lot valuation from a product variant now uses the correct product-level update process. This prevents inconsistent valuation checks and helps keep inventory valuation behavior reliable.
Original PR description
The write logic for lot_valuated is handled on the ProductTemplate. When you change the value of 'lot_valuated', '_svl_empty_stock()' is called before the new value is set, and the code expects ProductTemplate.lot_valuated and ProductProduct.lot_valuated to not yet be updated. However, if you change 'lot_valuated' from the ProductProduct model, ProductProduct.lot_valuated will be updated before ProductTemplate.write() is called. Hence, in '_svl_empty_stock()', ProductTemplate.lot_valuated != ProductProduct.lot_valuated This issue only happens in the 'write' context, so it should not cause too much issue. To fix this issue, when lot_valuated is updated from ProductProduct, we call the ProductTemplate write instead. --- https://github.com/user-attachments/assets/9d2f64a4-a7ad-4078-ad0b-0cc50270492b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents invalid fixed tax rate values from being sent to Egypt's electronic invoicing authority. It helps keep Egyptian EDI tax submissions compliant with official ETA requirements and reduces the risk of rejected invoices.
Original PR description
To comply with Egyptian tax law, we need to remove rate for fixed taxes when sending data to ETA. Official docs say: "if Channel = “ERP” OR Channel = “POS” and itemData[*].taxableItems[*].subType is fixed, itemData[*].taxableItems[*].rate should be zero or omitted" Source (point 36): https://sdk.invoicing.eta.gov.eg/main-calculations/ This fix ensure no values are sent for fixed tax type. Currently using null, which is invalid. opw-4457780
This fix prevents an accounting currency query from being built incorrectly when no companies are configured with a domestic currency. It helps avoid errors in affected accounting workflows and improves reliability in less common company setups.
Original PR description
We are not gonna find a value for domestic_currency_companies everytime, sometime they simply don't exist. In that case, we should check that they exist before we call _get_table_builder_domestic_currency. otherwise syntax of this query: https://github.com/odoo/odoo/blob/18.0/addons/account/models/res_currency.py#L157 is gonna be wrong. 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 live chat button now receives the information it needs when opened from the chatbot test page. This prevents a setup gap that could affect testing live chat behavior before publishing it.
Original PR description
The livechat button loader template adds `websocket_worker_version` to the Odoo session. However, when the loader is called through `chatbot_test_script_page`, it does not receive the `websocket_worker_version`. In the standard Odoo environment, this value is already available in the session This fix ensures the `websocket_worker_version` is properly handled in scenarios involving `chatbot_test_script_page`. Task-4462067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A missing company partner identifier was added to the accounting onboarding form so partner autocomplete works correctly. This prevents errors when users apply partner autocomplete during company setup or onboarding.
Original PR description
`partner_gid` was missing from `res_company_form_view_onboarding` view which was creating a bug when applying the partner autocomplete. opw-4489441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payments made in Philippine pesos through Xendit no longer fail because of decimal amounts. This ensures customers can complete PHP payments without seeing an “Amount must be integer” error.
Original PR description
Steps to reproduce: 1) Configure Xendit provider 2) Try paying in PHP currency 3) Observe: 'Amount must be integer' error Xendit does not allow decimal places for PHP. opw-4415419
This fixes an issue in Point of Sale employee handling where opening or closing a session could fail for employees linked to more than one partner record. Businesses can now manage POS sessions more reliably without interruptions caused by this employee setup.
Original PR description
Before this commit, if an employee had multiple related partners, an expected singleton error occurred when attempting to set the opening or closing of the session. opw-4482497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Quote Builder tab now appears as soon as a product with linked documents is added to a sales order, without needing to save and reopen it. This removes an extra step for sales users and ensures document availability is consistent across users with different access rights.
Original PR description
Steps to Reproduce: - Ensure no headers or footers are in Configuration > Headers/Footers. - Create a new Sale Order (SO). - Add a partner to the SO. - Add a product to the SO that has a document…
Steps to Reproduce: - Ensure no headers or footers are in Configuration > Headers/Footers. - Create a new Sale Order (SO). - Add a partner to the SO. - Add a product to the SO that has a document linked to it. - The `Quote Builder` tab does not appear until the SO is saved and reopened. Issue: The `Quote Builder` tab did not appear immediately after adding a product with linked documents. This required saving and reopening the SO to make the tab visible, causing inconvenience to users. Cause: The `_compute_available_product_document_ids` method lacked an `@api.depends` decorator for fields `product_id` and `product_template_id`. As a result, the dependent field `is_pdf_quote_builder_available` was not updated dynamically. Fix: Added the `@api.depends` decorator to `_compute_available_product_document_ids`, ensuring the computation is triggered immediately when `product_id` or `product_template_id` changes. This ensures that `is_pdf_quote_builder_available` is recalculated dynamically, making the `Quote Builder` tab visible immediately. - Also added `compute_sudo` on `available_product_document_ids` field to ensure available documents consistancy even though users have different access. opw-4364152
Point of Sale sessions now record their opening time when the cashier clicks "Open register". This prevents new sessions from incorrectly inheriting the previous session's closing time, improving the accuracy of store session records.
Original PR description
- Fix bug where session opening time was set to previous session closing time. - Now we want the pos session opening time to be set when we click "Open register". task-id: 4500391 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 Manufacturing planning view now identifies late work orders using the exact current date and time instead of only the calendar day. This makes the late filter more reliable for teams prioritizing urgent production work.
Original PR description
Steps to reproduce: ---- - Go to manufacturing - Planning by production - Add late filter Issue: ---- The late filter "does not work", the filter is based on the day. But the late order should be based on a much more precise datetime. Fix: --- Changed the filter from current_date to datetime.now to have more precision in the time, and so it filters more accurately. opw-4493678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates a sales project test so it works consistently when that module is tested on its own. It helps prevent false test failures caused by missing project accounting setup, improving confidence in future releases.
Original PR description
It was failing in single module builds /locally and the reason was due to the fact that project not having a analytic account. task-4500108
Egyptian electronic invoices with withholding tax now report the withheld amount correctly as a positive value. This prevents validation failures when businesses submit invoices with withholding tax to the tax authority.
Original PR description
Steps to reproduce:
- With an EG Company setup
- Create an invoice with a '3% WH' tax
- Confirm invoice and send for validation
Issue: Validation will fail with error
```
{'code': '2', 'message': 'Validation Error', 'target': 'INV/2025/00001', 'propertyPath': None, 'details': [{'code': None, 'message': 'ArrayItemNotValid', 'target': '[0]', 'propertyPath': '#/invoiceLines[0]', 'details': None}, {'code': None, 'message': 'ArrayItemNotValid', 'target': '[1]', 'propertyPath': '#/taxTotals[1]', 'details': None}]}
```
This is caused by the withholding tax amount being reported as negative, while it should be reported as positive
opw-4453002
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-prThe website editor now creates a proper primary button when users choose the button command from the powerbox, instead of accidentally inserting a regular link. This makes content editing more predictable and helps users create the intended call-to-action elements without extra manual adjustments.
Original PR description
Before this commit: Using the button command in the powerbox resulted in the creation of a regular link instead of a button. After this commit: Executing the button command now correctly creates a primary button as intended. task-4380129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds coverage to ensure overtime is calculated correctly when an employee clocks in and out multiple times in one day, such as for breaks. It helps prevent incorrect extra-hours balances by making sure adjustments are applied to the latest attendance entry.
Original PR description
This PR adds a test to ensure that negative overtime works properly and is recomputed as multiple attendance records are made on a single day. For employees who clock out to take breaks, this is necessary. This ensures that the "extra hours" propagate to the most recent attendance record, while zeroing out those before it. The PR that brought the notion of negative overtime to flexible working schedules is here: https://github.com/odoo/odoo/pull/193523#pullrequestreview-2569240672
This update improves how Odoo calculates and displays tax totals, especially when invoices use different tax rates, no-tax lines, cash rounding, or globally rounded amounts. It helps produce clearer customer documents and more accurate tax data for markets with strict reporting requirements, including Mexico and Portugal.
Original PR description
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 fixes an issue where list views did not apply certain custom settings because a setup step was not being run. Businesses using tailored list views should now see expected behavior when dynamic options or custom display rules are used.
Original PR description
Before this fix, the list widget's extractProps function was never called due to an incorrect method reference in the web module. This caused issues when rendering dynamic props or customizing the list view behavior. After the fix: - The extractProps function is properly invoked. - The list widget can now retrieve props values as expected. 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 Barcode app no longer fails when users update and validate produced quantities for manufacturing orders. This prevents an error that blocked completion of the workflow, helping production teams process manufacturing orders smoothly.
Original PR description
Issue: ========== A traceback occurs when validating the quantity produced through the Barcode app, causing the process to fail. Steps to Reproduce: ======================= 1. Create a new database and install the Manufacturing module. 2. Create and confirm a manufacturing order (MO) from the backend. 3. Open the Barcode app, access the MO, edit the quantity produced, and validate. With this commit: ==================== Prevent error when lot_producing_id is undefined during form save and allow smooth validation of produced quantities. task-4443489
Fixes issues in the Documents app where edits made from the details panel could be lost, applied to the wrong selected documents, or fail to show contact information after reload. This improves reliability when users preview, tag, rename, move, or update documents and folders.
Original PR description
Several things addressed on the details panel. A. When editing a previewed document, no data was saved. When editing a previewed document, no data was saved. Reproduce: 1. Without selecting any…
Several things addressed on the details panel. A. When editing a previewed document, no data was saved. When editing a previewed document, no data was saved. Reproduce: 1. Without selecting any document, open a preview 2. Rename the document or add a tag 3. Close the preview 4. Reload the page 5. See that changes were not saved BTW, tags could not be created from the inspector, it's not clear why. Technical note: for previewed record, that are not "selected" when we update them, we need to force saving immediately. For records that are selected, we can leave the webclient behavior for saving records (urgent save). This can lead to having tracked fields being immediately reported (seen in chatter) when editing previewed documents but not the others. This is acceptable for simplicity. B. When showing data for the current folder opened, the contact info was missing (partner_id). Reproduce: 1. Go inside any folder 2. Without selecting any documents, add a contact to the current folder via the details panel 4. Reload the page 5. The partner doesn't show up in the field (even though it is updated on the record). C. U pdate previewed document only Reproduce: 1. Select two records 2. Preview one of them 3. Change a value in the details panel 4. Both records were modified instead of the previewed one only We're also fixing the removal of the correct documents from the kanban view when documents are moved and making sure we do not try to edit this document again as it could likely not be in the view anymore at all. Task-4465443
This fixes an issue that prevented users from exporting batch payments as XML files. Businesses can again generate the required payment export files for bank processing without manual workarounds.
Original PR description
Since this commit:https://github.com/odoo/enterprise/commit/7bfeb39f64bfecde2960c6f6678062ac515589cb it wasn't possible to export in xml a batch payment. no-task-id
Recruitment-related attachments now open in the expected document location instead of sending users to the broader documents view. Recruiters and interviewers are granted the needed folder access automatically, and that access is removed when they no longer have those roles.
Original PR description
Steps to reproduce: 1) install document_hr_recruit module 2) create an application and upload an attachment to it 3) go to the kanban view and click on the attachment icon on the right bottom 4) it will lead you to the document view instead of the document Cause : In the document settings, there’s a recruitment option to select the folder for job positions and application documents. By default, the setting should be 'Recruitment', but the visibility is not configured in the code Fix: We will provide 'view' access to the folder Task-4348197
Direct debit mandates with a future start date are no longer closed when the mandate update task runs. This prevents valid upcoming customer payment authorizations from being incorrectly deactivated before they can be used.
Original PR description
### Steps to reproduce: - Go in Accounting > Customers > Direct Debit Mandates - Create a new mandate with a start date in the future - In Scheduled Actions search for "Mandate state updater" - Run manually this action - Return to Accounting > Customers > Direct Debit Mandates - The mandate was closed ### Cause: The code checks if `mandate.start_date <= today <= expiry_date`, if not the mandate is closed. ### Solution: Only check if `today <= expiry_date` opw-4460087
Embedded document actions now keep all stored translations instead of copying only one language, so multilingual users see the correct labels. The accounting document actions are also prepared for easier journal customization, helping less technical users configure them more confidently.
Original PR description
1. [FIX] documents: keep translations when embedding action When creating an embedded action from a server action, only one language was copied. Note that we are using `_get_stored_translations` instead of `get_languages` to identify values to write as a simple method to avoid storing too much unnecessary data as possible (e.g., 100 languages installed but only `en_US` on the record). 2. [IMP] documents_account: prepare actions journal customization This can be helpful to guide less technical users. Task-4486261
This fix ensures Belgian salary package users can select private car or bike options when a mobility budget is part of the contract. It prevents an incorrect restriction in the salary configuration flow, making mobility-related compensation choices available as intended.
Timesheet overtime now uses the configured average hours per day for employees on flexible schedules, instead of relying on detailed work intervals. This makes daily and weekly overtime totals match the intended schedule setup while keeping standard schedules unchanged.
Original PR description
#### Issue: - When an employee is assigned a resource calendar with the `flexible_hours` option enabled, the daily/weekly overtime on the timesheet calendar is not calculated based on the 'Average…
#### Issue: - When an employee is assigned a resource calendar with the `flexible_hours` option enabled, the daily/weekly overtime on the timesheet calendar is not calculated based on the 'Average Hour per Day' that we set for the flexible resource, it is instead being calculated based on the specific work intervals. #### Steps to reproduce: 1. Assign a resource calendar with `flexible_hours` enabled to an employee. 2. Ensure the calendar has a defined `hours_per_day` value. 3. Verify that the timesheet grid correctly shows the daily/weekly overtime hours as per `hours_per_day`. 4. Test with non-flexible schedules to confirm existing behavior remains unchanged. #### Solution: - In the frontend, the method `fetchDailyWorkingHours` retrieves daily working hours data by calling the backend method `get_daily_working_hours`. - This method computes working hours based on the employee's `resource_calendar_id` and its associated work intervals. However, It does not check if the `flexible_hours` flag is enabled on the `resource_calendar_id`. For employees with flexible schedules, the backend still calculates working hours based on detailed intervals instead of simply using the `hours_per_day` value defined in the `resource_calendar`. - To fix this I ensure we respect flexible schedules by using `hours_per_day` directly when `flexible_hours` is enabled. opw-4407910
This update fixes rounding differences in Mexican electronic invoices so tax authority validation accepts the generated documents. It also updates related localization logic and tests to prevent the issue from returning.
Original PR description
See test in this commit to reproduce.
This fix updates automated checks for Knowledge articles so they match recent editor changes and run reliably again. It removes a source of inconsistent test failures caused by embedded video loading, helping keep future Knowledge updates safer and more stable.
Original PR description
1st issue: Since the introduction of the [media command] in the editor, replacing the previous `/file`, some tour steps of a disabled test became obsolete. This commit fixes these steps according to…
1st issue: Since the introduction of the [media command] in the editor, replacing the previous `/file`, some tour steps of a disabled test became obsolete. This commit fixes these steps according to changes introduced along the `/media` command, in order to re-enable this test. 2nd issue: Other steps were incorrectly modified by [this commit] and had to be adapted too, related to the composer signature. 3rd issue: An embedded video was present in an article body in the readonly tour, and the patch supposed to neutralize it (to avoid external http requests) was applied in a manner that resulted in an indeterministic result: Sometimes the article body was loaded with the video, resulting in errors, sometimes the patch was applied resulting in the tour performing normally. This commit fixes the issue by ensuring there is no embedded video after the end of the editable tour, so that there is no need to care about it in the readonly tour. [media command]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 [this commit]: https://github.com/odoo/enterprise/commit/1a73e227a5ce9fb1194e5664c8c4f5fcfe51b572 runbot-task-111948