Daily updates from Odoo
Wednesday, October 22, 2025
27 changes · 19.0
Enhancements to existing features
The Taiwan localization now includes updated balance sheet and profit and loss reports that better match common Taiwanese business practices. The previous report versions are kept as legacy for now but are planned for removal in a future version.
Original PR description
This commit adds new improved accounting reports (balance sheet & profit & loss), providing users with improved reports that aligns better with the common Taiwanese business practices. The old balance sheet and profit & loss reports are depreciated and will be fully removed in later versions. [Task-4915057](https://www.odoo.com/odoo/project.task/4915057)
The Taiwan localization now includes a refined chart of accounts and updated default accounts aligned with common local business practices. This helps Taiwanese companies start with accounting structures that better reflect publicly listed company reporting formats.
Original PR description
This commit adds improved Chart of Accounts for Taiwan to better match common business practices. The chart of accounts, balance sheet, and profit and loss are referenced from the accounting structures used by publicly listed companies in Taiwan to ensure relevance and practicality. Updates: - Revise Taiwanese chart of accounts - Revise Taiwanese default accounts [Task-4915057](https://www.odoo.com/odoo/project.task/4915057) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican localization demo company has been replaced with one that supports payroll stamping as well as existing electronic invoicing demo flows. This keeps demos and testing usable for payroll, invoicing, stock, and accounting scenarios in Odoo 19.
Original PR description
The SAT has a list of ‘demo’ companies to enable invoicing demo operations through Electronic Data Interchange (EDI). Currently, in Odoo, the default demo company is Kemper School. However, with the release of payroll stamping in version 19, this company is no longer useful, as it cannot stamp payroll. So, instead of adding another company, we modified the Kemper School data to change it to another company that can stamp payroll and all other existing documents. The demo company data was changed, the certificates were changed, and a file that was never added to the manifest and therefore had no use was deleted. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Financial reports can now group account-based lines by account code before showing individual accounts when used across multiple companies. This makes cross-company reports easier to compare when different companies use matching account codes but separate account records.
Original PR description
If the report has a line that contains a group by `account_id` and if the report is multi-company, we allow the user the group per `account_code` before `account_id`. task-5092712
Equity transaction forms are now easier to read with fields in a clearer order and more understandable names for transactions, beneficial owners, and valuations. Price change tracking now shows the correct currency symbol, reducing confusion when reviewing transaction history.
Original PR description
This commit 1. Reorders fields on transaction form 2. Gives better display names for transactions, ubos, and valuations 3. Fixes the tracking of transaction security_price not having currency sign task-5144766
Follow-up and customer statement reports now have a simpler, more focused header with centered titles and fewer technical details. The reports also show the partner bank account below the Tax ID, making key payment information easier for customers to find.
Original PR description
This commit updates the layout for follow-up and customer statement reports. Changes made: --- **Follow-up & Customer Statement Reports:** - remove journal and filter details from header. - centered the title of the report. - Added the partner bank account display below the Tax ID. --- task-4823880 Forward-Port-Of: odoo/enterprise#90068
When a user manually assigns an emission factor to an account move line, Odoo now creates a matching assignment rule automatically. This reduces repeated manual work and helps apply the same emission factor consistently to future lines with the same product or partner.
Original PR description
Before this commit, when the user assigns an emission factor to an account move line, no assignation rule is created based on that, which means the user has to either manually create an assignation rule into emission factor or each time select that emission factor for the same product/partner set on other account move line. This commit automatically generates an assignation rule into emission factor when the emission factor is manually set into an account move line. By doing that, the user will be able to use the assignation rule to automatically assign that emission factor to other account move lines. task-4933207
The Peppol configuration wizard now remains available even if the external service list cannot be retrieved. This lets businesses still complete important actions such as unregistering, instead of being blocked by a non-critical service outage.
Original PR description
Handle `api/peppol/2/get_services` errors gracefully, without blocking critical section of peppol functionnal flow (deletion). If the API endpoint for services returns an error (which should not be affecting any users), the whole peppol config wizard is no longer accessible. The users will therefore not be able to unregister. Note that with this change, if we get an API error, all services will be marked as disabled (which is fair, and better than displaying an API request error) no-task Forward-Port-Of: odoo/odoo#228800
Resolved issues and error corrections
This change ensures older browsers load the compatibility support needed after users log into Odoo. It prevents backend crashes so affected users can continue using Odoo normally.
Original PR description
Description of the issue/feature this PR addresses: Old browsers crashing for Odoo 19.0 after logging into backend ``` TypeError: this._tables.difference is not a function\n at request.onsuccess (http://.../web/assets/d7f7d1b/web.assets_web.min.js:4763:464) ``` Current behavior before PR: Polyfill for Set difference() is only loaded in web.assets_frontend_minimal and not loaded after login since 2d56c0930f824ae9a8fd33c376e1dd9f34900ffa Desired behavior after PR is merged: Polyfill for Set difference() is also loaded in backend and the User can use Odoo. References: https://www.odoo.com/de_DE/forum/hilfe-1/error-code-new-to-odoo-278378 https://www.odoo.com/de_DE/forum/hilfe-1/there-is-an-error-please-solve-this-error-282526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Info @wt-io-it
This change prevents a client-side error that could appear when using Odoo 19 on mobile browsers, especially Safari on iOS. It replaces a browser-incompatible operation with a standard approach, improving reliability for mobile users on newly created databases.
Original PR description
Description of the issue/feature this PR addresses: Error occurred only on mobile device on v19.0 community installation with new created database. On the same device and browser no error on v18.0…
Description of the issue/feature this PR addresses:
Error occurred only on mobile device on v19.0 community installation with new created database.
On the same device and browser no error on v18.0 but always this error on v19.0
Error:
———————
UncaughtPromiseError > TypeError
Uncaught Promise > this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
Occured on mydomain.fr on 2025-09-17 19:05:42 GMT
TypeError: this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
@https://mydomain.fr/web/assets/debug/web.assets_web.js:48443:58 (https://mydomain.fr/web/assets/debug/web.assets_web.js:48443)
———————
Analyze:
——
Original: Using .difference()
const newTables = this._tables.difference(dbTables);
- This syntax assumes that _tables is a Set and that the difference method exists.
- However, native JavaScript has never defined Set.prototype.difference in the ECMAScript specification.
- In some environments (e.g., Node.js with a polyfill, or certain experimental JS engines), it might exist, but Safari does not have this method, which causes the error.
FIX: Using filter and new Set()
const newTables = new Set([...this._tables].filter(x => !dbTables.has(x)));
- Here, we convert _tables to an array, filter out elements that are not in dbTables, and then create a new Set.
- Everything is standard ECMAScript, so it works in all modern browsers, including Safari on iOS
Fix:
Use standardized JS function supported by all browsers in indexed_db.js
Test:
All is fine, no more error on client side
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where company-specific special products could be missing from Point of Sale configurations for that same company. This ensures stores can reliably access the products assigned to their company after reloading PoS data.
Original PR description
### Problem When assigning a special product to a company, the product will not be loaded when accessed from a PoS config of the same company. The issue occurs because `product.sudo().company_id == self.company_id` fails as `self` is an empty recordset. ### Steps to Reproduce on Runbot * Add a company to the special PoS product. * Access a PoS config on the same company. * Reload data. * The product will not be loaded. original PR: https://github.com/odoo/odoo/pull/194451 opw-5157959 Forward-Port-Of: odoo/odoo#231273
This fixes the French VAT report submission so address details follow ASPOne’s required validation rules. It helps prevent rejected filings by limiting postal code and city values correctly and using the expected address field format.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
Users who choose to handle notifications inside Odoo and also enable browser push notifications will no longer receive two alerts for the same message. This reduces confusion and notification noise when users are working with Odoo open in a browser tab.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221259The point of sale customer display now automatically scrolls to show the currently selected order line. This helps customers see the latest or active items clearly during checkout, reducing confusion at the register.
Original PR description
Steps to reproduce: - Turn on customer display in point of sale - Add some order lines - Customer display doesn't auto scroll Current behavior: - Customer display doesn't auto scroll Expected result: - Customer display should scroll to the selected lines
This fixes an issue where users configuring a website on iPhone or iPad Safari could not select dropdown values. The website setup flow now handles Safari's mobile behavior correctly, making configuration smoother on Apple mobile devices.
Original PR description
Scenario: - go to /website/configurator on safari iOS (ipad, iphone, …) - configure the website Result: the dropdown are not selecting a value Cause: 7a291d59909b2ee57111ddec35a20a2302291f29 fixed the issue on desktop safari by using pointerdown and pointerup handler, and handling the dropdown hiding in the pointerup. This work since events happen in order: pointerdown -> focusout -> pointerup -> focusin But on iOS safari the order is: pointerdown -> pointerup -> focusout -> focusin that is not taken into account by the fix. Fix: change the safari fix to close the dropdown on a focusin on another element following a focusout of a dropdown. opw-5129288
This fix prevents the mass mailing editor from crashing when users edit HTML content inside a pop-up and switch from text to an image. It improves reliability for users creating or editing email campaigns in modal windows.
Original PR description
Have a mass mailing html field in a modal click on some text then on some image Before this commit there was a crash. This was because some overlays use a sequence lower that the dialog they are related to. Hence, when the OverlayContainer reconciled its Owl list of element, the dialog got displaced, making the iframe unloading The Editor crashed subsequently, tryng to access the iframe's defaultView which did not exist anymore after unloading the iframe After this commit, this use case doesn't happen any more. This is really ad-hoc Owl cannot be fixed to account for iframes in that situation the web framework could do more to stack overlays in order to avoid this. related to task-5182993 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
Budget line reports now show committed amounts for the specific budget line instead of matching the whole budget. This prevents purchase or bill amounts from appearing doubled when multiple analytic plans are used, improving confidence in budget tracking.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
Job applications created by email now keep the company from the job position when the linked department has no company set. This prevents hiring teams from losing key application settings, such as assigning recruiters or interviewers.
Original PR description
When an applicant applied to a job position with a company_id and department_id, but the department itself had no company_id set, the application would have company_id set to False rather than the company_id from the job position. This caused bunch of issues such as the inability to add a recruiter or interviewers to the application.The bug seems to come from the default values created in the method `_alias_get_creation_values` on the job position, which sets the default company_id to the department's company_id when the job has a department that can result in False when the department exists but has no company set. task-5184275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232492
Portal and public users can now print or export public Knowledge articles with the expected content and formatting. The fix adds the right print styling for Knowledge pages and removes a conflicting Planning print rule that could hide article content.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96656 Forward-Port-Of: odoo/enterprise#92665
This change prevents spreadsheet-specific print styling from being loaded in the general backend area, where it could interfere with printing Knowledge articles. Users should see fewer blank-page issues when printing or exporting content, while spreadsheet printing continues to use its dedicated print setup.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing Print Assets (Public View)** The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode. ### Fix This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle. The remaining issues are tackled in odoo/enterprise#92665 opw-4816241 Forward-Port-Of: odoo/odoo#230639 Forward-Port-Of: odoo/odoo#223434
Fixes an issue where changing rental dates in the online cart could shift the layout and make quantity buttons stop working. Customers can now adjust rental dates and quantities without the cart becoming difficult or impossible to use.
Original PR description
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and…
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and quantity buttons become unclickable. Cause: ====== Two separate issues caused this behavior: 1. **Layout shift:** When updating the date range, `cart_quantity` can be undefined. The logic that determines whether to toggle the `col-lg-7` class relies on this value. When undefined, it incorrectly assumes the cart is empty and shifts the layout to the left. 2. **Unclickable buttons:** The following line replaces the entire `.js_cart_lines` element: https://github.com/odoo/odoo/blob/abf9bc083c5a219a0b6fc0346dcd2a2cb503e081/addons/website_sale/static/src/js/website_sale_utils.js#L88 This removes all old elements (and their event listeners) and inserts new ones from the server. As a result, interactive buttons (e.g., quantity update) lose their functionality. Older versions didn't face this issue because they used jQuery event delegation, which automatically handled dynamic elements. Solution: ========= 1. Use a reliable check for cart emptiness by falling back on `data['website_sale.total']` when `cart_quantity` is undefined, 2. Restart the cart interaction after re-rendering to restore event bindings for clickable buttons. opw-5167866 related : https://github.com/odoo/enterprise/pull/97715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Trial Balance PDF exports now correctly apply search filters when hierarchy and subtotals are enabled. This ensures users see the expected account lines when filtering by either account details or group names, improving accuracy in exported audit reports.
Original PR description
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create…
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create an account group (e.g Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance ) - In the Options select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to pdf #### Current behavior: - No lines are displayed in the pdf as the backend uses only the account name to apply the filter #### Expected behavior: - Lines are displayed using account name and group name to filter #### Cause: - Filter was applied only on account name #### Solution: - If hierarchy is enabled, display accounts where filter appears on either account or group opw-4906593 Forward-Port-Of: odoo/enterprise#96338 Forward-Port-Of: odoo/enterprise#90403
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from automatically using taxes that should no longer be available. This helps keep invoice tax calculations aligned with active accounting settings and reduces manual correction work.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775 Forward-Port-Of: odoo/odoo#231462 Forward-Port-Of: odoo/odoo#230729
Receipt-type bills now keep their deferred date settings and use the correct accounts when deferral entries are generated. This prevents accounting errors and avoids users having to re-enter deferred dates after changing document types.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5.…
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97824 Forward-Port-Of: odoo/enterprise#97653
This update resolves several user-facing issues across Odoo, including broken invite email links, untranslated public page content, payroll and time-off errors, accounting mapping problems, and subcontracting valuation safeguards. It also improves electronic invoice exports by adding delivery party details, helping businesses avoid operational errors and produce more complete documents.
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
Project and sales administrators can now open and update SMS templates used by project workflows without running into access errors. This fixes incorrect access rules so authorized managers can manage project-related communications more smoothly.
Original PR description
**Issue** Project administrators are not able to manage SMS templates related to project models. **Steps to reproduce** - Have `project_sms` and `sale_sms` installed. - Have a regular user (not admin) with Project: "Administrator" and Sales: "Administrator" rights. - Go to Project/Task kanban view > cog icon on top of columns > edit > try to open/modify the SMS template. Issue: access rights error **Cause** - the rule in `sale_sms` is problematic because it is the only record rule affecting read operations, while other modules only target CUD operations. It has the effect of restricting read operations for Sale:Administrator users. - the rule in `project_sms` was referencing the wrong models, SMS templates are linked to `project.project` and `project.task`. opw-4908909 Forward-Port-Of: odoo/odoo#232676 Forward-Port-Of: odoo/odoo#228590
Field Service users can now see and select task templates from the app even when multiple Field Service projects exist. This removes a workflow blocker for teams using several projects to organize their field operations.
Original PR description
**Steps to reproduce:** - Install the industry_fsm module. - Create a new FSM project. - Create a task template under that project. - Go to the Field Service (industry_fsm) app. - Check the Kanban view (dropdown action). **Issue:** When there are multiple FSM projects, users cannot select FSM task templates from the FSM app. **Cause:** The default_project_id is not passed in context. **Fix:** With this change, users can now see and select FSM task templates even when multiple FSM projects exist. task-5139928