Wednesday, December 18, 2024
8 changes · 17.0
Resolved issues and error corrections
Fixed an issue where moving between records with the pager could leave a reference field showing the value from the previously opened record. This helps users see accurate information when reviewing records such as External Identifiers.
Original PR description
Let say we have two record with a reference field with char type. Record X with reference A Record Y with reference B If we open the record x form view directly from the list view the fetch will works as wanted (reference A) But if we use the pager to navigate to record Y, the reference field will not be correct, it will dispay the old one (reference A instead of B) This is because in the `ReferenceField` setup method we use an `useRecordObserver` to track record changes and update reference data. But before this commit, we passed the wrong `props` to `_fetchReferenceCharData` `useRecordObserver` has a second argument, which is the new `props`, so we can use it instead of `this.props` still referring to the previous record This can be reproduced on `External Identifiers` view (accessible with debug) opw-4349296
This fix helps prevent unused tooltip-related page elements from staying in memory after they are no longer needed. It improves browser stability and reduces the risk of old screen data being kept longer than necessary.
Original PR description
The PR [1] fixes a memory leak in the tooltip service. The `Map` was used with `HTMLElement` as key. These elements were not removed and so never garbage collected. A more important issue is that these elements could retain info from components like views with models. In a forward port, the change `Map` to `WeakMap` dispeared. This PR just re-adds this diff. [1]: https://github.com/odoo/odoo/pull/186579
This fix prevents automated actions from unnecessarily clearing a long-lived template cache when Odoo workers start or the registry reloads. It helps preserve cache efficiency, reducing avoidable performance overhead in systems using onchange-triggered automations.
Original PR description
Since https://github.com/odoo/odoo/pull/152498, we invalidate the 'templates' orm cache when we load the registry if there is an onchange trigger automation exists. Every time that a worker takes its first request or that the registry is reloaded, it will then invalidate this long-term (we try anyway) cache, reducing its efficiency depending on worker recycling.
A previous error occurred when creating planning slots due to missing calendar information for resources. This update corrects the code to handle cases where a resource doesn't have a working calendar, preventing a traceback and ensuring planning slots can be created successfully. This improves the reliability of the planning module.
Original PR description
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in…
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in Gantt view and redirect to resource from the slot 3) Remove the Working Time of that resource 4) Now try to create a new planning slot for that resource from Gantt view Error:- ``` ValueError: Expected singleton: resource.calendar() ``` Here, `calendar_id` is not required in the resource. So, when the user removes the calendar_id from the resource and tries to create a new planning slot, it leads to the above traceback. In the below line, we try to get calendar_d from the resource if it is available. https://github.com/odoo/enterprise/blob/7847510dc6ad8dec73f01470714aacb0c3510769/planning/models/planning.py#L611-L612 We can resolve this issue by taking calendar_id from the company as it is required. If it fails to get the value from the resource. sentry-6150920391
A bug was preventing users from accessing documents after archiving the default 'Projects' workspace. This update prevents archiving of the projects workspace, resolving the error and ensuring proper document access. This change improves the stability and usability of the documents application.
Original PR description
Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132
This update resolves a compatibility problem in the Account Accountant module. It addresses an error that occurs when the Account module isn't updated alongside the Account Accountant module. The fix adds a temporary field to ensure proper functionality until the Account module is updated.
Original PR description
Scenario: - install account without commit (eg. before 3 december 2024): odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221 - install account_accountant with commit (eg. after 3 december 2024):…
Scenario:
- install account without commit (eg. before 3 december 2024): odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221
- install account_accountant with commit (eg. after 3 december 2024): e4111ac8f817f97b3d6128453659a1014b6db00f
=> Traceback with odoo.tools.convert.ParseError: while parsing
account_accountant/views/product_views.xml:3
Field 'is_coa_installed' used in attrs
({'invisible': [('is_coa_installed', '=', False)]}) must be present
in view but is missing.
Cause:
The change in account_accountant
(e4111ac8f817f97b3d6128453659a1014b6db00f) relies on the change in account (odoo/odoo@d413a9895742594d064084cd6dafbf1f2ec97221) but account_accountant can be installed/updated without updating account.
Fix:
Add a duplicate is_coa_installed field in account_accountant useful if account module is not up to date.
opw-4323694
note: only useful up to saas-17.2, in saas-17.4 the field is automatically added if it's necessary for an attribute.
pr note: issue found when working on an unrelated ticket
Forward-Port-Of: odoo/enterprise#75490This update addresses a technical issue preventing the correct generation of TNT manifest PDFs when using Starshipit in Australia. While the core problem isn't fully resolved, the fix allows stock picking to be marked as 'Done' with tracking number and link visibility for users. The manifest PDF itself remains unavailable.
Original PR description
If Starshipit is configured with TNT service (Australia), the API does not return a pdf field for `orders/manifest` endpoint. This causes the transfer validation process to fail in Odoo. This fix does not resolve the core problem, but it will allow the stock picking to be marked as "Done", with tracking number and link available to the user. The downside is that the manifest PDF will not be available Task: 4195503
This update ensures Odoo correctly identifies the company's currency when synchronizing bank accounts. This is crucial for accurate testing and integration with financial institutions, resolving a previous issue that could lead to incorrect account data. It primarily impacts the account synchronization process.
Original PR description
This commit updates the process to pass the company's currency code to the `_get_accounts` route. By doing so, the server can accurately identify the company's currency. This change is particularly important for supporting testing banks. task-4293992 Forward-Port-Of: odoo/enterprise#75372