Friday, January 30, 2026
55 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where the scrollbar wasn't visible in the time off Kanban view, preventing users from easily seeing their vacation time requests. The fix adds a scrollbar to the view, ensuring users can now access and manage their time off requests effectively.
Original PR description
Before: the scrollbar of the kanban view in timeoff was not showing coz of which users were not able to see their timeoffs easily After: Fixed the scrollbar of the kanban view so that the user can be able to see their timeoffs which they were not able to do that easily Fix: Added the `overflow-x` as auto so that the scrollbar is visible. Task:5502863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245443
This update corrects a bug where archived journals were still appearing as selectable payment methods when creating company expenses. The fix ensures that only active journals are offered, improving the user experience and preventing incorrect payment selections. This was caused by a previous code change that didn't properly filter inactive journals.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
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
Forward-Port-Of: odoo/odoo#242743This update fixes an issue with how Saudi social insurance contributions are recorded in Odoo. The change ensures that employer payments are accurately assigned to the correct accounting accounts, improving financial reporting for Saudi businesses using this module. This resolves a discrepancy in the posting of social insurance contributions.
Original PR description
Fix the account configuration used by Saudi social insurance contribution salary rules for the company. This ensures employer contributions are posted to the correct accounting accounts. Task-5468575 Forward-Port-Of: odoo/enterprise#105182
This update resolves a test failure related to the audit trail functionality within the account module. Specifically, a change was made to ensure data flushing occurs during certain tests, improving the reliability of the audit trail reporting. This ensures accurate tracking of account transactions.
Original PR description
Since this commit https://github.com/odoo/odoo/pull/242248/changes flushing inside `test_cant_unlink_message1`, `test_cant_unown_message` is now required. https://runbot.odoo.com/odoo/runbot.build.error/237803 runbot/error-237803 Forward-Port-Of: odoo/odoo#246353
This update corrects a minor issue in the website product pricing calculation. An unnecessary 'target_currency' parameter was being passed, causing confusion. The change simplifies the process by removing this parameter, ensuring accurate pricing without impacting functionality.
Original PR description
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and…
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and [_get_additionnal_combination_info](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_template.py#L490), the target_currency is passed but it is unused parameter.
The product_pricelist price computation logic relies on the [currency](https://github.com/odoo/odoo/blob/saas-18.2/addons/product/models/product_pricelist.py#L162) and target_currency is not used anywhere in the pricing flow. As a result, passing target_currency adds confusion without affecting the outcome.
The target_currency parameter was unused in the method call flow and, due to this, it was always being passed as NULL. This made the parameter ineffective and confusing, while the actual logic expects a valid currency value.
This commit replaces target_currency with currency to avoid unused / misleading parameter.
Traceback
```py
2026-01-22 12:50:48,564 48232 ERROR currency_19 odoo.addons.website_sale.tests.test_website_sale_product_template: ERROR: TestWebsiteSaleProductTemplate.test_markup_data_uses_taxes_included_price_when_configured_on_website
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/addons/website_sale/tests/test_website_sale_product_template.py", line 81, in test_markup_data_uses_taxes_included_price_when_configured_on_website
markup_data = self.product._to_markup_data(self.website)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website_sale/models/product_product.py", line 162, in _to_markup_data
product_price = request.pricelist._get_product_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 121, in _get_product_price
return self._compute_price_rule(product, *args, **kwargs)[product.id][0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 220, in _compute_price_rule
price = suitable_rule._compute_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ProductPricelistItem._compute_price() got an unexpected keyword argument 'target_currency'
```
Before fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = None
uom = None
date = False
compute_price = True
kwargs = {'target_currency': res.currency(20,)}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
(Pdb)
```
After fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = res.currency(20,)
uom = None
date = False
compute_price = True
kwargs = {}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
res.currency(20,)
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
```
- opw - [5447980](https://www.odoo.com/odoo/project/70/tasks/5447980)
- upg - [3782135](https://upgrade.odoo.com/odoo/upgrade.request/3782135)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246180
Forward-Port-Of: odoo/odoo#242998This update streamlines the user experience by embedding relevant actions, like 'Create Vendor Bill,' directly into the appropriate journal folders (e.g., Purchase, Sales). This ensures users have the necessary tools available where they're working, improving efficiency.
Original PR description
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type…
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type (e.g., "Purchase", "Sales"). All relevant actions are also kept in the parent "Finance" for general accessibility. The purchase actions are also added to the "Inbox" folder. Why: The previous behavior was inefficient. A user uploading a vendor bill to the "Purchase" folder would not see the "Create Vendor Bill" action. He would only see it when he is in the parent "Finance" folder. By embedding it by default this streamlines the process by ensuring the necessary tools are available exactly where the user is working. How: The logic is implemented within the _documents_configure_sync method of the account.journal model. This is the ideal location because it handles the complete setup of a journal for the Documents app. This ensures that actions are embedded correctly both during module installation and dynamically whenever a new journal is created by a user. Notes: - Tests were rewritten to check these embeddings on install. And were refactored to be more maintainable and cover bank statements better. - The test for importing bank statements had to be moved to a separate testing module, as it needs the `account_bank_statement_extract` module, which is not in the dependencies of `account_move`. - The tests for bank statement processing errors was improved to match the tests in later versions Task-5410752 Related Task-5075610 Forward-Port-Of: odoo/enterprise#102039
This update fixes a misclassification of account 649 in the French Profit and Loss report. The change aligns the report with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within Wages and Salaries and Social Security Charges. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves a frustrating user experience issue where a notification about delayed translations would block access to editing features on multilingual websites. Previously, clicking 'Edit' after a translation update would simply hide the notification, preventing users from making necessary changes. This fix ensures notifications disappear correctly, allowing seamless website editing.
Original PR description
When we have a delayed translation, we get a notification saying that we should edit, or translate to apply the changes made in the default language. However, when we click on edit, the notification is still present, and it blocks the dropdown, so the user doesn't see it until the notification disappears. Steps to see the issue: - In a multilingual websites: - Add a content in the default language, 'A' - Translate the content in your other language 'B' - Come back to 'A', and edit the content, e. g. add some style - Come back to the language 'B' => A toaster notification appears, and if you click on "Edit" button, you cannot see what's below. task-5447519 Forward-Port-Of: odoo/odoo#245260
This update ensures that WebGL testing continues to function correctly in Chrome's headless mode (version 144+). Chrome's default settings now disable WebGL, so this change re-enables it for testing purposes, specifically to maintain functionality for features like image filters in the website builder. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves an issue in the Peppol demo mode where a branch company with the same VAT number as the parent company would receive an 'id_client already in use' error. The fix ensures each company receives a unique id_client, preventing data conflicts and improving demo stability. This ensures the demo accurately reflects the intended Peppol functionality.
Original PR description
Steps to reproduce in demo: 1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company (with same VAT number as the main company); 3. Activate Peppol in the branch and select "Send from parent company"; 4. Error message: "This id_client is already used on another user.". In demo edi_mode, when trying to connect a branch company with the same VAT than the parent company, the demo function took the same id_client for every company, which violates the unique constraint on id_client. task-5888203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246287
This update ensures that the current day location field is consistently included when retrieving data for the homeworking feature. Previously, this data was sometimes missing, causing issues when the feature was used in different parts of the system, such as the studio. This fix guarantees accurate location information is always available.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 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 Forward-Port-Of: odoo/odoo#246096 Forward-Port-Of: odoo/odoo#245740
This update fixes an issue where embedded actions within folders were hidden from the interface, preventing users from managing or deleting them. The change ensures that embedded child actions are now correctly displayed and accessible, streamlining the process of managing actions within documents. This improves usability and reduces potential data management issues.
Original PR description
### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#105800 Forward-Port-Of: odoo/enterprise#100395
This update resolves a user experience inconsistency within the account_peppol module. Previously, the system used 'demo' for user neutralization, while the edi_mode was set to 'test'. This change ensures a clear and consistent approach, simplifying the setup and operation for users.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update resolves an issue where a technical error during bill import could lead to duplicate entries in the PEPPOL system. The fix ensures that the import process doesn't block confirmation and allows for unlinked bills, preventing potential data inconsistencies. It also handles unexpected errors after move creation to maintain data integrity.
Original PR description
A UserError there can cause duplicates in peppol fetching. It should never block an ack. We can leave them unlinked We also do the same for any unexpected error that occurs after we've created the move. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246233 Forward-Port-Of: odoo/odoo#246133
This update resolves a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update enhances the mobile signing experience by addressing layout issues and navigation problems. Specifically, it cleans up the user interface, clarifies empty states, and ensures smoother transitions during the signing process, leading to a more polished and user-friendly experience.
Original PR description
Before: - Several mobile screens had layout issues such as extra white space, misaligned elements, and uneven spacing. - During signing, the "Next" navigation appeared abruptly without a smooth transition. After: - Improved mobile layouts to remove unnecessary white space and keep grid alignment consistent. - Added placeholders on relevant screens (e.g. Documents folder, Authorized Users, redirect link) to clarify empty states. - Fixed transition issues when navigating between fields during the signing flow. Impact: - Provides a cleaner and more polished mobile signing experience. - Improves usability by making empty states clearer and navigation smoother. Task: 5493477 Forward-Port-Of: odoo/enterprise#104606
The Point of Sale system now gracefully handles errors during initialization, preventing the app from getting stuck on a loading screen. Users are presented with an option to clear local data and refresh, particularly beneficial for mobile users who don't want to manually reset their data. This enhances the user experience and improves POS reliability.
Original PR description
Inconsistent data in the localDB or local storage can cause the POS to fail before it can get initialized. When this happens the page just stays showing the loading screen forever. Now when an error happens while initializing the POS the loader will disappear and the app will give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242532
This update addresses a potential error in Odoo that could occur when attempting to access related records through 'res_id' fields. Specifically, the system would fail if a 'res_id' was set to 0. This change ensures the system handles this scenario gracefully, preventing errors and improving data reliability.
Original PR description
`browse(x.mapped('res_id'))` may fail if there are res_ids that are equal to 0. Update existing code.
odoo/enterprise#105767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update addresses a potential issue where incorrect IDs were being used within Odoo's core modules. The fix ensures that all IDs are properly validated, enhancing data accuracy and reliability across various business processes. This improves the overall stability and trustworthiness of the system.
Original PR description
https://github.com/odoo/odoo/pull/246097
A recent issue preventing users from switching to superuser mode has been resolved. The problem stemmed from a simple typo – 'sesssion' instead of 'session' – in the code. This fix ensures a smoother and more reliable experience for all users.
Original PR description
Currently an error occurs when user tries to switch to superuser. Steps to replicate: - Make a DB and turn on debug mode. - Click on the bug icon and click `Become Superuser`. Error: `AttributeError: 'Request' object has no attribute 'sesssion'` Cause: - Session incorrectly spelled as `sesssion`. Fix: - Corrected `request.sesssion` to `request.session`. No Id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that tests for KPI reporting in the email system run consistently. Previously, demo data could create mail activities that interfered with test results. Now, the tests are run with a clean slate, guaranteeing accurate and reliable reporting.
Original PR description
Commit ff941e6555c12918803db4a72511c9381cc58c31 introduced a test that counts the amount of mail activities grouped by type. However, the test doesn't take into consideration that the demo data might have created some activities. With this commit, we ensure the tests run with a clean state by removing any pre-existing mail activities so that we have consistent and expected results. Runbot-build-error-id: [234966](https://runbot.odoo.com/odoo/runbot.build.error/234966)
This update corrects a bug where 'todo' and 'none' audit statuses on accounts were incorrectly grouped together in reports. Previously, sorting or filtering by 'todo' status didn't accurately reflect the actual status of accounts. This change ensures accurate reporting and filtering based on account status.
Original PR description
When going on the balance view of a working file, when trying to sort by the status or filtering on 'todo', the audit status with no value would still be here.
To Reproduce:
- Install the demo data
- Create a working file _ Click on Status
- The To Review and nothing are not sorted
- Add a domain ("audit_status", "=", "todo")
- THe audit status with no value are still hereThis update fixes a limitation in the document search feature, allowing users to now search across multiple user root folders. The original system missed a key test scenario, resulting in incomplete search results. This change ensures a more comprehensive and accurate search experience for all users.
Original PR description
Introduced with 7994db2c, where we forgot about the click all tests that would enable all filters at once. See runbot error 237504 Task-5893183
This update resolves a technical issue preventing users from correctly viewing product pages on the website. The problem stemmed from a missing button within the product display, triggered by the 'real_estate' module. This change ensures a smoother user experience when browsing products.
Original PR description
Steps to reproduce: - Install `real_estate` module(industry) - Website > Properties > Open any product Traceback: `ValueError: Expected singleton: product.template()` This error occurs when the [addToCart] value is `null`. We get `null` because the code is trying to find a button with the name `add_to_cart` inside the `parent`, but that button does not exist in the [template]. [addToCart]: https://github.com/odoo/odoo/blob/61bdc119bca73a7e9ee946d0695c6acc1453adbd/addons/website_sale/static/src/interactions/product_page.js#L329 [template]: https://github.com/odoo/industry/blob/92ff34e33cd166479449dae7ce37e37c9e409db2/real_estate/data/website_view.xml#L336-L344 sentry-7212605657
This update clarifies the name of a recruitment stage from "Initial Qualification" to "Qualification" within the Odoo HR recruitment module. This change improves the user experience and ensures consistency in stage labeling, making the recruitment process easier to understand and manage. This is a minor fix related to a previous enhancement.
Original PR description
This is a small follow-up PR to the original PR to simply rename a stage label. See https://github.com/odoo/enterprise/pull/105278 Task-ID: 5454691 Forward-Port-Of: odoo/odoo#246278
This update clarifies the terminology used in the recruitment process by renaming the "Initial Qualification" stage label to "Qualification". This change improves clarity and consistency for users managing recruitment workflows within Odoo Enterprise. It's a minor adjustment to enhance the user experience.
Original PR description
This is a small follow-up PR to the original PR to simply rename a stage label. See https://github.com/odoo/enterprise/pull/105278 Task-ID: 5454691 Forward-Port-Of: odoo/enterprise#105854
This update resolves a bug causing website tests to fail due to delayed loading of interactions within iframes. The fix intelligently waits for the interaction service to be ready, ensuring tests execute correctly. The removal of unnecessary timeouts further stabilizes the testing process.
Original PR description
__Before commit__ Hoot tests using interactions inside the iframe may fail because we do not wait for the interaction service to be ready before executing the tests. In particular, the `SharedPopup` interaction is sometimes started after we trigger a click to display it in the test. Since it has not had time to register the proper listener, the `d-none` class is never removed from the popup, so the test is stuck waiting for it to appear. __Fix__ When the JavaScript assets are included inside the iframe, the attribute `is-ready` is added to the iframe body. In this case, we wait for it to appear instead of uselessly adding it artificially. Waiting for all interactions to load may take a bit of time, so a large timeout is set to wait for the `is-ready` attribute. The timeouts inside the tests are now removed since they were there to fix this bug without success. runbot-237554 Forward-Port-Of: odoo/odoo#246327
A bug was causing the input field for campaign testing to disappear when cleared. This meant users had to close and reopen the dialog to use it again. This fix adds a simple adjustment to ensure the input field remains visible and functional, improving the user experience for campaign setup.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
This update resolves a technical problem on odoo.com where very large order IDs would cause errors in achievement reports. The change uses a more efficient calculation to ensure all IDs remain within the standard BIGINT limit, preventing report generation issues.
Original PR description
Before this commit, we had issues on odoo.com when the ids of the account move, account move line, sale order or sle order line were too high. We would end up with ids bigger than BIGINT limit. This commit ensure it does not happen anymore by using bitwise operation on ids istead of multiplying the values. task-5423978 Forward-Port-Of: odoo/enterprise#103264
This update resolves a technical issue preventing invoices from successfully validating with DIAN, Colombia's tax authority. The fix corrects a naming inconsistency in invoice tags, ensuring proper validation and compliance. This ensures invoices are processed correctly and avoids potential delays or rejections.
Original PR description
Problem: When validating invoices with DIAN, an error is received. Cause: Incorrect tags are being used in the invoices. These tags are checked when invoices are validated with DIAN. Solution: Use the correct tags in the invoices. schemeName should be used instead of scheme_name. Steps to reproduce: - Install l10n_co_dian module - Choose a Colombian company - Activate DIAN service in Settings - Create an invoice and send it while making sure the DIAN checkbox is ticked - Download the generated zip file and uncompress - Open the XML file and check for scheme_name. It should be replaced by schemeName. opw-5829958 Forward-Port-Of: odoo/enterprise#105841 Forward-Port-Of: odoo/enterprise#105659
This update resolves an issue where the sign-up tour could behave inconsistently, sometimes running within a webpage frame and other times directly. The fix ensures the tour runs reliably regardless of the user's interaction method, providing a smoother and more predictable experience for new users.
Original PR description
This commit fixes an indeterministic sign tour that could run either inside an iframe or directly in the main page. Since the execution context was unpredictable, both selectors were added to handle both cases reliably. runbot error-238443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246393 Forward-Port-Of: odoo/odoo#246032
This update fixes a memory error that occurred when loading website pages, specifically within the page manager. The change optimizes how the system retrieves page information, reducing the risk of performance issues and ensuring a smoother user experience. A new caching system has been implemented for faster page retrieval.
Original PR description
Before this commit, loading the list view of the website pages invoked a method called `_get_most_specific_pages`. This method caused a memory error due to loading the field called `key` for the pages being fetched. This field was related to a field called `key` in the model `ir.ui.view`, so a cache miss in the recordset causes a `SELECT *` query for the ir.ui.view potentially causing a memory error if the size of these views are big. A solution for this is to force the ORM to load only the `key` field by invoking **search_fetch** on the `ir.ui.view` model instead. In order to improve the retrieval of a given page key count, we now use a Counter map (=> constant time instead of linear search). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245600 Forward-Port-Of: odoo/odoo#240924
This update corrects a previous issue where paid event registrations automatically confirmed after a sale, leading to inaccurate notifications and a less effective attendee editor. Now, registrations remain in 'draft' mode until attendee information is entered, ensuring notifications are sent to the correct recipient and maintaining administrative control.
Original PR description
Problem: - In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used…
Problem: - In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant. Current behaviour: - Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient. Expected behaviour: - Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided. Solution: - Do not set ‘state=“open”’ for payment records created from a sale involving the data wizard for records. Ensure they remain in “draft”. - Confirm registrations once attendee details are present. Advantages: - Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner. - Meets functional expectations for administrative control and proper recipient targeting. Tests to reproduce the error: - Create quote with payment entry - Confirm SO - Enter attendee details and confirm - Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee. @Tecnativa TT58160 @pedrobaeza please review --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244525 Forward-Port-Of: odoo/odoo#230500
This update ensures that customers purchasing event tickets through POS are accurately registered as attendees. Previously, the system didn't consistently link customer information to event registrations, leading to inaccurate attendee tracking. This fix aligns the POS registration process with website registration behavior, improving data accuracy and reporting.
Original PR description
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks…
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks for name but is not required * Open pos and sell on ticket * Do not put name info * Select a customer for the order * Validate order * Check registrations > Observation: The customer is not registered as the attendee Why the fix: ------------ We compare the scenarios with the same flow but from website registrations. On the website if there is no user registered: - If information is not filled, nothing will be registered on the registration - If information is filled it will be used to populate attendee fields If there is a user registered while on website: - If no information is filled, attendee fields will be populated with the data from the connected user - If information is filled, it will be used for attendee fields - If partial information is filled, it will be used for attendee fields but will also be completed with data coming from the connected user To achieve the same behavior from the pos we first need to register the customer as the partner for the event. During event creation we also remove values regarding attendee name, email, phone and company if they were not provided during the order. From the website they are not used during creation if they were not given by the customer. However, in the pos this information is present anyway (as empty string or False) as they are fields on the model "event.registration" and are still send to the backennd even if we remove the information here https://github.com/odoo/odoo/blob/787621e44a9cef30469849929df267cae9e977f2/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L127 We do the fix server-side as a fix in the frontend would not be as straightforward. A customer might be on the order before selecting event ticket and it's easy but one might also add the customer after the ticket was selected. opw-5137197 Forward-Port-Of: odoo/odoo#242783 Forward-Port-Of: odoo/odoo#234871
This update resolves an issue where switching product variants caused a technical error when product images were intentionally hidden (set to 'none'). The fix ensures a smoother user experience by correctly handling scenarios where images aren't displayed, preventing tracebacks and improving product browsing.
Original PR description
When product images are hidden (image_width='none' or missing), switching between product variants caused a traceback. Steps to reproduce: =================== - Go to a product page with variants -…
When product images are hidden (image_width='none' or missing), switching
between product variants caused a traceback.
Steps to reproduce:
===================
- Go to a product page with variants
- Edit mode & change the image to hidden
- Change variant
-> Traceback
Cause:
======
- The server doesn't send `carousel` data when images are hidden
(product_page_image_width='none')
- However, `_getProductImageContainerSelector()` still returned a valid
selector ("#o-carousel-product" or "#o-grid-product")
- `querySelector` found the existing (but empty) image container in the DOM
- `_updateProductImage()` was called with `undefined` as newImages parameter
- the re-queried images element crashed
Solution:
=========
In old version it was jquery and it was only checking for the existance
of the Old images (See [1]).
Now it will check both old and new images.
[1]: https://github.com/odoo/odoo/blob/77bfe416d08eefc720f12899490d3d39efacb74a/addons/website_sale/static/src/js/website_sale.js#L294
opw-5499004
Forward-Port-Of: odoo/odoo#246081This update resolves a visual issue in the website builder where gaps appeared between related options, particularly when using nested settings. The fix ensures that connector lines are consistently displayed, improving the overall usability and appearance of the builder. This enhancement contributes to a more polished and professional website design.
Original PR description
Steps to reproduce: - Open the website builder and drop a "Cover" snippet on the page. - In "Background > Image", choose "Position: Repeat pattern" to reveal the "Width/Height" sub-options. - Issue: the vertical connector line between the "Filter" and "Position" options is broken. After this commit, the gap is removed. Options at the same level are now properly connected, even when one of them contains sub-options. task-5155955 | Before | After | | ------------- | ------------- | | <img width="286" height="424" alt="image" src="https://github.com/user-attachments/assets/db035598-5094-4ec3-a42b-dc86bd871b9b" /> | <img width="285" height="422" alt="image" src="https://github.com/user-attachments/assets/d0229c5b-d3ea-41a2-9ed7-6155fc34d280" /> | Forward-Port-Of: odoo/odoo#246090 Forward-Port-Of: odoo/odoo#241092
This update fixes an issue where automatic reconciliation was blocked when an invoice's reference matched its payment reference. The change allows the system to correctly identify and match invoices, streamlining the reconciliation process and eliminating manual intervention. This resolves a reported problem on odoo.com.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA) Forward-Port-Of: odoo/enterprise#105878 Forward-Port-Of: odoo/enterprise#105648
This update resolves a technical issue that was preventing the Account Status Badge from displaying correctly in some instances. The fix ensures the system handles missing configuration data gracefully, preventing a traceback and improving the user experience. This ensures accurate reporting and a more reliable application.
Original PR description
If this.env is not present, the config will be undefined and when accessing the viewType it will raise a traceback. task-5417418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a previous issue where audit reports couldn't be created for periods that didn't align with fiscal years. It now supports fiscal year periodicity and custom periods, ensuring that audit reports accurately reflect financial data and provide clearer analysis for users. This enhancement improves the reliability of financial reporting.
Original PR description
It wasn't possible to create audits on a period that didn't match a fiscal period. task-5417418 Forward-Port-Of: odoo/enterprise#103212
A recent issue prevented users from printing bank statements through the list view. This fix resolves a technical error related to how the system handles statement IDs during printing, ensuring statements can now be printed correctly. This improves the user experience for generating financial reports.
Original PR description
When trying to print a statement via the list view, we get a traceback. This is because the module `account_bank_statement_import` inherits the `view_bank_statement_tree` and use `accountMoveUploadListView` which use `AccountMoveListController`. Therefore, when calling `get_extra_print_items` from the controller, we call it with model `account.move` but with a statement id, which leads to either wrong behavior or access error. Steps: - Make sure account_bank_statement_import is installed - Have 2 companies - Create a bank statement for company B, make sure it has the same id as any account move from company A - From the bank statement list view, select the statement - Click on the print button -> Traceback opw-5427019 Forward-Port-Of: odoo/odoo#245207
This update ensures that search views remain consistent when navigating from pivot or graph reports to detailed views. Previously, the system defaulted to a generic search view, leading to an inconsistent user experience. This fix corrects the process to correctly pass the intended search view, improving report accuracy and usability.
Original PR description
Clicking on a pivot cell or graph bar/pie opens a new view, but the search_view_id was not being passed. As a result, the default search view was used, even when the action defined a specific one. This caused inconsistent search views between the pivot/graph view and the drilled-down view. This PR fixes the issue by correctly passing the current action's search_view_id when opening a new view from pivot/graph. Steps to reproduce: - install website_sale - goto website > reporting > online sales - click pivot cell - the new opened list view does not have same search view as before <img width="1920" height="563" alt="image" src="https://github.com/user-attachments/assets/e54656bb-088f-464b-8de2-a88a3a3ab22d" /> <img width="1920" height="635" alt="image" src="https://github.com/user-attachments/assets/e95ed61b-7573-4d58-9875-827c3124a039" /> task-[5469929](https://www.odoo.com/odoo/project/1519/tasks/5469929) Forward-Port-Of: odoo/odoo#243233
This update resolves an issue causing errors when adding transcription snippets to new, unsaved records. The fix ensures proper record identification and saving, preventing errors and improving the stability of the AI transcription component. It also corrects a localization issue in the test environment.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. The PR also adapts `voice_transcription_plugin.test.js` to add the locale to the date that is inserted when starting a transcription, avoiding local test fails. task-5788331 Forward-Port-Of: odoo/enterprise#105026
This update streamlines database synchronization by removing outdated XMLRPC support and improving error handling. The system now handles more databases synchronously and presents errors in a user-friendly way, enhancing the overall stability and reliability of the Odoo Enterprise SaaS platform.
Original PR description
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to…
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`. In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code. The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page. ### [FIX] databases: disable the KPI-selection wizard With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field. Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view. The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2). Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314) ### [FIX] databases: handle fetch errors better With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user. ### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action. With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action. Forward-Port-Of: odoo/enterprise#105176
This update resolves an issue where duplicate "Applicant created" messages were appearing in the applicant's chatter log. The fix prevents the system from posting the applicant creation subtype multiple times, ensuring a cleaner and more accurate record of applicant activity. This improves the user experience and data consistency.
Original PR description
Steps to reproduce: 1. Create a new applicant in recruitment. 2. Open the applicant’s chatter. 3. See multiple “Applicant created” messages for the same creation. Bug cause: The applicant creation flow posts the `mt_applicant_new` subtype more than once (create + extra write/track), and the frontend renders the subtype description, so each duplicate post shows “Applicant created” again. Solution: - Post the `mt_applicant_new` subtype only once during applicant creation. - Avoid re-posting it in subsequent writes/tracking so chatter shows a single creation log. Task Id: 5454691
This update fixes a potential issue with how Odoo handles deleting records linked through inherited fields. Previously, the system assumed inherited records were always single records, which could cause problems when deleting related records. Now, the system correctly handles RecordLists, ensuring data integrity during cascade deletions.
Original PR description
Usually (always?) the "inverse" for an inherited field will be a one2many. Even if in practice it is a one2one. The cascade deletion of the inverse should thus handle RecordList instead of assuming they're always single records. related: 478647c4526f42a2455a599555748c844a6f20cf task-5013894
This update resolves an issue where blockquote content was being lost when emails were sent. The fix adds a Bootstrap column class to the blockquote structure, ensuring it's correctly processed and included in the final email. This ensures all email content, including blockquotes, is delivered as intended.
Original PR description
Problem: When sending an email containing a blockquote, its content is missing in the received email. Cause: The `bootstrapToTable` conversion logic strictly filters the children of `.row` elements and only keeps nodes that have valid Bootstrap column classes. In the `s_blockquote` snippet, the content was wrapped in a plain `<div>` placed directly inside a `.row`, so it was ignored during conversion. Solution: Add the `col-12` class to the inner `<div>` of the blockquote snippet so it is recognized as a valid Bootstrap column and preserved during conversion. Steps to reproduce: - Create a new email marketing. - Add the "Blockquote" snippet. - Send the email. - Observe that the received email loses the blockquote content. opw-5883624 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246263
This update fixes an issue where highlight effects weren't consistently applied to multi-line text on websites, particularly in smaller viewports. The change adds a vertical position check to the text detection process, ensuring highlights are correctly applied regardless of text layout. This improves the overall user experience and consistency of website highlighting.
Original PR description
Steps to reproduce: 1. Go to Website (Edit mode) and drop a title block. 2. Select the title, set a highlight effect, and save the page. 3. Load the page in a reduced viewport in a way that makes the highlighted text split into multiple lines. 4. The highlight won't be applied correctly (only the last line will be detected). The current line detection mechanism relies on the horizontal comparison of rects (see `rectToBatch()`), which returns wrong results when applied to centered text content. The goal of this commit is to add a y-coordinate (vertical) check to detect new lines more reliably in `rectToBatch()`. This improves robustness for multi-line selections with unusual layouts. related to opw-4865891 Forward-Port-Of: odoo/odoo#245142 Forward-Port-Of: odoo/odoo#219234
This update resolves an issue where scheduled email notifications and related activities continued to run even after records were deleted. The fix prevents errors caused by attempting to process notifications for non-existent records, improving notification reliability and preventing confusing error messages for users. It ensures that notifications are skipped when records are deleted, avoiding unnecessary processing and potential issues.
Original PR description
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS Fix various use case in mail * notifications sent for scheduled messages; * failure notifications management; * activities mark as done; Task-5138556 Forward-Port-Of: odoo/odoo#244248 Forward-Port-Of: odoo/odoo#233071
This update addresses a potential issue where deleted records in Odoo could still be accessed, leading to errors. The fix ensures that related records are properly handled during cascade deletions, preventing data access attempts after records are removed. This improves data integrity and stability.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104589 Forward-Port-Of: odoo/enterprise#101185
This update adjusts the color used to highlight the 'Looking for Help' live chat description in the user interface. The previous bright yellow color was found to be distracting. This change ensures a more professional and less visually jarring experience for users.
Original PR description
Text was using `.text-warning`, which is too distracting. Part of Task-5867464 Before / After <img width="960" height="387" alt="Screenshot 2026-01-30 at 16 27 00" src="https://github.com/user-attachments/assets/9cc1129c-5169-4ef0-a84e-dfbb866ddcea" /> <img width="961" height="384" alt="Screenshot 2026-01-30 at 16 26 31" src="https://github.com/user-attachments/assets/e858cc16-14cd-4149-98bd-cbbb44ee5cb1" />
This update fixes an issue where Stripe account creation could fail intermittently, leading to duplicated accounts. It ensures that a transaction is always created upon account setup, guaranteeing proper Stripe integration even if subsequent steps fail. Additionally, the system now sanitizes URLs to prevent errors when requesting Stripe account links.
Original PR description
## [FIX] hr_expense_stripe: Fix account duplication Add a transaction commit when the account is created, to ensure that even if any further action fails the stripe account is properly set on the company. This will prevent users from creating accounts every time if the account creation part succeeded ## [FIX] hr_expense_stripe: Sanitize values for webhook url Sometimes the web.base_url is the http version of the database url, where the https is properly setup. At account creation we test the https connection, and allow the creation of the account forcing https on IAP side. But when we request the links for the account, the database will still send the http version of the url, refused by stripe. This adds a sanitization of the URLs on the database side Forward-Port-Of: odoo/enterprise#105858
This update resolves an issue where the Datev export process incorrectly accessed parent tax groups when dealing with tax groups that had child tax groups. The fix ensures that the export accurately reflects the child tax groups, improving the reliability of financial data sent to Datev. This was identified and corrected as part of a broader effort to ensure data integrity.
Original PR description
Issue: Before this commit, when a tax type is group and has children, we access the parent, even though the dict has only the children Fix: as a solution, we map through the originated tax list received from the compute all function opw-5480918 opw-5874567 Forward-Port-Of: odoo/enterprise#105638
This update removes unnecessary timezone information from avatar cards when the user's local time zone matches their own. Previously, displaying the timezone added visual clutter. This change ensures a cleaner and more user-friendly experience on the avatar card.
Original PR description
Before this commit, the local time zone was shown on avatar card even when this is the same as current user. The intent of showing of local timezone is to see when it differs. When this is the same, this just adds noise to the card. This commit hides the showing of local timezone when this is the same as current user. Part of Task-5867464 Before / After <img width="310" height="206" alt="Screenshot 2026-01-30 at 17 24 04" src="https://github.com/user-attachments/assets/c47f885d-fb98-48f8-91fb-24d6a33e4c9a" /> <img width="311" height="193" alt="Screenshot 2026-01-30 at 17 23 50" src="https://github.com/user-attachments/assets/26fe6cf8-f2b1-40a3-b478-065ea88e01af" />
This update resolves a performance issue in the project timesheet report that prevented it from loading with large datasets. The team optimized the query by using a more efficient join method, resulting in a faster loading time of approximately 2 seconds. This improves the user experience for reports with many records.
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report…
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052 Forward-Port-Of: odoo/enterprise#105696 Forward-Port-Of: odoo/enterprise#102283
This update resolves an issue where editing a bank statement line caused unnecessary recalculations of all related lines, including reconciled ones. The change now ensures that only the edited line is recomputed, significantly improving performance and stability when managing bank statements. This prevents slowdowns and ensures accurate reconciliation processes.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885 Forward-Port-Of: odoo/enterprise#106017 Forward-Port-Of: odoo/enterprise#105754