Daily updates from Odoo
Saturday, March 21, 2026
79 changes
24 changes
Resolved issues and error corrections
This update resolves an error occurring when setting tax return periods for Dutch companies within the Odoo Enterprise system. The issue stemmed from a misconfigured function call during a forward port, leading to a runtime error. This fix restores the correct function call, ensuring accurate tax return period configuration.
Original PR description
Currently, an error occurs when configuring tax return periods for a Netherlands company. - This PR [97615](https://github.com/odoo/enterprise/pull/97615) introduced the…
Currently, an error occurs when configuring tax return periods for a Netherlands company. - This PR [97615](https://github.com/odoo/enterprise/pull/97615) introduced the `_get_tax_tags_for_nl_sales_report()` function - In the 19.1 fw port, the implementation is different. This function is neither added nor called. Instead, `_get_ec_sales_tax_tags()` is called in its place. - In the 19.2 fw the function is still missing, but it is called, so it does `Traceback` `AttributeError: 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report'` We fix this by using `_get_ec_sales_tax_tags()` in `19.2`, just as `v19.1` does. **Steps to reproduce:** - Install `l10n_nl_reports` and `accountant` modules - Set up an `NL company`. - Go to `Accounting > Tax Returns > Set Periods`. - Set the date - Click `Apply` Tickets links: [6035534](https://www.odoo.com/odoo/project.task/6035534), [6045553](https://www.odoo.com/odoo/project.task/6045553), [6045241](https://www.odoo.com/odoo/project.task/6045241), [6037249](https://www.odoo.com/odoo/project.task/6037249) opw-6035534 opw-6045553 opw-6045241 opw-6037249
This update resolves a technical issue in the Odoo Co Vietnam receipt generation process. A redundant attribute was identified in the template, which was corrected by moving the relevant content to a different HTML element. This ensures the receipt generation process runs smoothly and reliably.
Original PR description
`class` cannot be set on the `t` element. Moving to the `div`. runbot-242041 runbot-242042
This update fixes a technical error that prevented users from saving 'planning.slot' form views when adding resources. The issue stemmed from attempting to access deleted record references, causing a system error. This change ensures smoother operation when managing resources within the planning module.
Original PR description
This error occurs upon saving a `planning.slot` form view. Steps to reproduce: - Install `planning_field_service` module - Settings > Technical > Discuss > `Subtypes` - Delete `Field Service Resources Changed` & `Field Service Status Changed` - Planning > New(open form view) > Add `Resources` and Save Traceback: `ValueError: External ID not found in the system: planning_field_service.mt_intervention_resources_changed` The error occurs because, in the `_track_subtype` [method], we attempt to retrieve a reference to records that have already been deleted. [method]: https://github.com/odoo/enterprise/blob/7e1a72d75ca672ea3660cc236f93571a441bb734/planning_field_service/models/planning_slot.py#L145-L150 sentry-7338382431
This update fixes a previous issue where the tax returns journal wasn't automatically translated into all supported languages. The team has refactored the code to use a standard translation method, ensuring the journal is correctly translated for all users and languages within Odoo Enterprise.
Original PR description
Currently, the tax returns journal is created in the code and not via the standard `@template` function that makes sure it is always translated in the installed languages. So for now it was only translated in language of the current user. We refactored the code so the journal gets created via the standard `@template` function and thus automatically gets translated into all the installed languages. task-5921458 Forward-Port-Of: odoo/enterprise#111261 Forward-Port-Of: odoo/enterprise#107465
This update corrects a problem where the company logo was appearing too large in various Odoo reports. The fix targeted a generic CSS selector that was affecting multiple reports, ensuring a consistent and appropriate logo size across all generated documents. This improves the visual presentation of financial reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432 Forward-Port-Of: odoo/enterprise#110858
This update corrects a visual issue in the Helpdesk ticket templates where links were incorrectly styled as buttons. The change ensures buttons are properly recognized by the editor, preventing links from appearing as buttons and improving the user experience when editing ticket messages. This resolves a display inconsistency.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#111215 Forward-Port-Of: odoo/enterprise#107888
This update corrects a technical issue in the Peruvian VAT (ISC) tax implementation. A previous update removed a key element needed for accurate tax calculations, leading to potential errors. This fix reintroduces the 'TierRange' key, ensuring correct VAT calculations for Peruvian businesses.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598 Forward-Port-Of: odoo/enterprise#111061
This update corrects a technical issue where archived partner data was incorrectly being used when automatically detecting bank statements. Now, partner retrieval only considers currently active partners, ensuring accurate data assignment and preventing potential errors in financial reporting. This improves data reliability.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#111259 Forward-Port-Of: odoo/enterprise#110446
This update cleans up the error messages displayed in the account reports, making them easier to understand for users. The VIES check hyperlink has been removed to simplify the interface and will be reintroduced in a future release. This change improves the user experience and reduces potential confusion.
Original PR description
The company data check message was on multiple line. image The VIES check hyperlink wasn't Markup, since we cant easily display it, we will remove it in stable. Forward-Port-Of: odoo/enterprise#106154
This update resolves issues where the timesheet timer wasn't accurately tracking time spent when employees were checked out for attendance, and changes weren't consistently saved across all timesheets. Now, changes are reliably saved for all timesheets, regardless of whether they are new or existing, ensuring accurate time tracking and reporting.
Original PR description
This PR fixes two bugs in the timesheets systray: - The timer does not take into account the moments when you are checked out on attendance - When closing the systray without saving, changes are only saved for a new timesheet, not on existing ones Task-6042077
This update resolves a technical issue where the 'Roles' filter in the Planning module was incorrectly passing record IDs as strings. This prevented users from properly filtering resources by role. The fix ensures that record IDs are correctly interpreted as numbers, improving search functionality.
Original PR description
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the…
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the selection dialog 4. In the pop-up window, observe that a default filter is already applied 5. Click on the Roles filter in the search panel Observation: ------------------------------------------ The filter on the Roles field applies an 'Invalid Record ID' in the domain Issue: ------------------------------------------ the default filter on `role_ids` passes the role ID as a string (e.g., 4) instead of an integer (4). This happens because the `filter_domain` uses `[self]`, and `self` is substituted with `label.trim()` in `_getFieldDomain`, which is always a string even when the underlying value is a numeric ID https://github.com/odoo/odoo/blob/accaa246d5818572996660f967624978e906b5c3/addons/web/static/src/search/search_model.js#L1747-L1750 Solution: ------------------------------------------ Replace `[self]` with `[raw_value]` in the `filter_domain` of the `role_ids` search field, the `raw_value` variable holds the actual typed value (integer ID) instead of the string label. opw-6003611 Forward-Port-Of: odoo/enterprise#109781
This update significantly speeds up the process of expanding project tasks to include users. Previously, a slow search query was triggered repeatedly, impacting performance with a large number of tasks. The change now uses a more efficient search method, reducing task expansion time from 30 seconds to just 1.4 seconds for 300,000 tasks.
Original PR description
Before this commit, expanding the `user_ids` involved fetching all the tasks satisfying a domain by a search call and returning only the active users by accessing the field `user_ids` from the fetched recordset of tasks. This approach introduced slowness with a big number of `project.task` since for each batch of **1000** records, a `__get__` call on the field will trigger an `SQL` query. I have updated the code to have the inverse field `task_ids` in the `res.users` model and did the search, the other way around searching directly the `res.users` model. | Tasks | Before | After | | :--- | :--- | :--- | | 300K | 30s | 1.4s | opw-5942477 Forward-Port-Of: odoo/enterprise#110641
This update resolves a critical issue where the WhatsApp Business Account webhook would crash when multiple phone numbers were linked to the same account. Odoo’s design allows for multiple phone numbers per account, but this change prevents the system from attempting to access security information from multiple records, which was causing the error. This ensures the webhook process is stable and reliable for users with multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
This update resolves a small technical issue on the Odoo website that was preventing a specific design element from displaying correctly. The fix involved correcting a typo in a class name, ensuring the website's visual presentation is consistent and accurate. This change doesn't impact user functionality.
Original PR description
task-6047633 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254817
This update adjusts the report bubble layout to accommodate more address lines without increasing the logo size. The change utilizes a smaller logo version to reduce vertical space, ensuring a cleaner and more readable report. This improves the presentation of address information in reports.
Original PR description
The bubble layout was changed in commit[1] but the logo size is too big to accomodate a sufficient amount of address lines. task-5951770 [1]: odoo/odoo@8eb61a245cd3b650e309fdb55d24654c34d785cd Enterprise PR: https://github.com/odoo/enterprise/pull/110858 | Before | After | |--------|--------| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/bb2671c3-62c8-45df-8039-4a9455d21982" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/d36ca5fe-24b3-4a74-8323-2c587d11495e" />| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/2b1c7ce9-2d14-47ab-9fc0-b4bca33e412f" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/df189280-b274-4dea-9ec1-9482c47b00e5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249432
This update fixes an issue where refund orders were displaying inaccurate margin values. The change ensures margin calculations are now correctly derived from the order's line data, regardless of whether the order is a refund. This improves the accuracy of financial reporting for refund transactions.
Original PR description
Refund orders were reporting incorrect values because the sign was derived from `is_refund`, which is not reliable. Replace with `SIGN(qty) * SIGN(price_unit) * ABS(...)` so the sign is computed directly from the line data in both `pos_order_report` and `sale.report`. opw-6017438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253023
This update ensures that when importing tasks from Excel, the specified recurrence settings are correctly applied, rather than defaulting to standard recurrence values. Previously, importing tasks without a recurrence ID would overwrite custom recurrence settings with defaults. This change improves data accuracy and consistency within Field Service.
Original PR description
### Steps to reproduce: - Create a xlsx sheet with some fsm_tasks values with recurrence values - Import the sheet to Field Service > Tasks - Navigate to the created tasks - Notice the recurrence values is the default ones not the ones in the imported sheet ### Cause: If we are importing records without recurrence_id value we will set the recurrence fields' values to the default values while we might already have values for those fields ### Fix: Check if we have values for recurrence fields we don't set the defaults and let the create method create the project.task.recurrence record and set the recurrence_id opw-5925546 Forward-Port-Of: odoo/odoo#254742 Forward-Port-Of: odoo/odoo#249104
This update fixes a reporting issue where clicking on initial demand links opened the wrong account.move view without relevant data. Now, the link redirects to the correct account.move line, displaying information related to the initial inventory balance, improving reporting accuracy and usability.
Original PR description
Currently the initial demand click will open the account.move view without filter. So you don't know what is related to the initial balance or not. This commit updates the action to use a domain on the accounts used by inventory valuation. Also it shows the account.move.line instead. It also add a date if needed to be concistent with the reprot. Task: 6024514 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#253907
This update corrects a misunderstanding in the Odoo system regarding Quebec Sales Tax (QST) registration numbers. The tooltip has been adjusted to accurately reflect that both PST and QST numbers should be entered in this field, ensuring proper tax reporting for Quebec businesses. This change improves data accuracy and compliance.
Original PR description
Currently, the `l10n_ca_pst` field label and help message implies that it is only for the PST number; however, in Quebec the proper name for such a value is the Quebec Sales Tax or (QST) registration number. As such, by updating the help message we clarify to the users that both PST and QST should be placed here. task-5866356 Forward-Port-Of: odoo/odoo#254943
This update enhances the HTML Builder by gracefully handling errors when using outdated snippets. Instead of failing silently, the system now displays a warning notification to the user, guiding them to update the snippet. This improves the user experience and prevents builder actions from being blocked by version mismatches.
Original PR description
Since [1], the warning to inform the user that a snippet is outdated has been removed. After this commit, if a builder action fail on outdated snippets (mismatched vcss/vxml/vjs versions), we show a warning notification instead of propagating the error. The notification informs the user that an error occurred on an outdated snippet, and prompts them to drag a new version of the snippet. This is achieved by wrapping try-catch blocks around all builder action lifecycle methods (apply, clean, load, getValue, isApplied) and implementing an error handling method that detects if the snippet is outdated. task-4297808 [1]: https://github.com/odoo/odoo/pull/224382 Forward-Port-Of: odoo/odoo#254785 Forward-Port-Of: odoo/odoo#230816
This update corrects a bug where the messaging menu counter was incorrectly displaying an inflated count when the Discuss app wasn't in use. The fix ensures the counter accurately reflects active conversations, even for archived channels, improving the user experience. It also addresses a related issue with muted channels.
Original PR description
Before this commit, when page loading in the webclient while not using Discuss (Discuss app closed, no chat window and bubble), the messaging menu counter could be wrong. Steps to reproduce: - Open…
Before this commit, when page loading in the webclient while not using Discuss (Discuss app closed, no chat window and bubble), the messaging menu counter could be wrong. Steps to reproduce: - Open Discuss app - Make a new channel - Post a message in this channel - Mark conversation as unread - Open Advanced settings of this channel - Archive this channel - Go back to home menu - (make sure no chat windows and chat bubbles are open) - Reload the page => The counter of messaging menu should be over-estimated by 1. For example if all conversations are read, counter is 1 instead of 0. Opening the messaging menu refreshes the counter to correct value 0. This happens because when using Discuss, the counter is deduced from all channels that have been fetched and for which current user is a member of these channels. Implicitly, archived channels are filtered out. However when not using discuss, the channels as member have not been fetched, and instead an estimation of the counter is fetched from server. This counter was computed on channel members that have unread messages. When a channel is archived, that doesn't mean the members are archived too. In the steps listed above, the self member is still active. As a result, the self member of this archived channel had contribution to the counter estimation, hence the value of 1 instead of 0. This commit fixes the issue by keeping computation on channel members but it checks also that the channel is active, as the resulting counter is based on active channels. This commit also fixed a similar issue where the counter was wrongly taking muted channels into account on the global counter when not using Discuss. This lead to a similar problem on non-archived but muted channels were they contribute in the estimated counter but not in the actual in-use counter. Task-6014754 Forward-Port-Of: odoo/odoo#254231
This update resolves a visual issue where the FileUploader component was causing extra spacing within the user interface. The original fix inadvertently introduced this problem, and this PR corrects it by neutralizing the element's layout impact while maintaining its intended functionality. This ensures a consistent and clean user experience.
Original PR description
This PR completes the changes introduced in: https://github.com/odoo/odoo/commit/2cbb735f5eecb7c31db8245b8d598d7193992a05 ### Issue: A `<div>` was added to prevent click propagation in the FileUploader, but it introduced unintended extra spacing in several parts of the UI ### Cause: The added `<div>` affected the layout by taking up space where it should not ### Fix: A specific class is added to neutralize the layout impact of this element while preserving the click propagation behavior ### Steps to reproduce: - Install `hr' - Create a new Employee - Go in Private Information > Work Permit - Upload a file Before the fix, the edition's buttons are in another line opw-5918379 Forward-Port-Of: odoo/odoo#254982
This update adds a crucial test to ensure that changes to the database code don't unintentionally break the sequence feature. The test uses a 'savepoint rollback' to verify that data is correctly restored if a test operation fails, providing greater stability and reliability. This prevents potential disruptions to the system.
Original PR description
The aim of this commit is to ensure the feature doesn't get silently broken in case some underlying code gets reworked. task-id: None Forward-Port-Of: odoo/odoo#255053
This update removes unnecessary debugging code (console.log statements) from the spreadsheet tests. These logs were accidentally included in the final pull request and could potentially cause issues with test reporting. This ensures the tests run smoothly and accurately.
Original PR description
some debugging lines were left in the final PR. Task-0 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#255103
11 changes
Resolved issues and error corrections
This update resolves an issue where tax calculations for Peruvian VAT (ISC) were incorrect due to a missing configuration element. The PR reintroduces a key component needed for accurate tax determination, ensuring compliance with Peruvian tax regulations. This ensures accurate VAT reporting for Odoo Enterprise users operating in Peru.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598 Forward-Port-Of: odoo/enterprise#111061
This update cleans up the formatting of messages related to return checks in the accounting reports module. The VIES check hyperlink has been removed to simplify the user experience and will be reintroduced in a future release. This change improves the clarity and usability of the reporting functionality.
Original PR description
The company data check message was on multiple line. image The VIES check hyperlink wasn't Markup, since we cant easily display it, we will remove it in stable. Forward-Port-Of: odoo/enterprise#106154
This update resolves a technical issue where the 'Roles' filter in the Planning module was incorrectly passing record IDs as strings, leading to search problems. The fix ensures that record IDs are correctly interpreted as numbers, improving the accuracy and reliability of the role-based search functionality.
Original PR description
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the…
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the selection dialog 4. In the pop-up window, observe that a default filter is already applied 5. Click on the Roles filter in the search panel Observation: ------------------------------------------ The filter on the Roles field applies an 'Invalid Record ID' in the domain Issue: ------------------------------------------ the default filter on `role_ids` passes the role ID as a string (e.g., 4) instead of an integer (4). This happens because the `filter_domain` uses `[self]`, and `self` is substituted with `label.trim()` in `_getFieldDomain`, which is always a string even when the underlying value is a numeric ID https://github.com/odoo/odoo/blob/accaa246d5818572996660f967624978e906b5c3/addons/web/static/src/search/search_model.js#L1747-L1750 Solution: ------------------------------------------ Replace `[self]` with `[raw_value]` in the `filter_domain` of the `role_ids` search field, the `raw_value` variable holds the actual typed value (integer ID) instead of the string label. opw-6003611 Forward-Port-Of: odoo/enterprise#109781
This update significantly speeds up the process of expanding project tasks to include users. Previously, a slow search query was triggered repeatedly for large numbers of tasks. The change now uses a more efficient search method, reducing task expansion time from 30 seconds to just 1.4 seconds for 300,000 tasks.
Original PR description
Before this commit, expanding the `user_ids` involved fetching all the tasks satisfying a domain by a search call and returning only the active users by accessing the field `user_ids` from the fetched recordset of tasks. This approach introduced slowness with a big number of `project.task` since for each batch of **1000** records, a `__get__` call on the field will trigger an `SQL` query. I have updated the code to have the inverse field `task_ids` in the `res.users` model and did the search, the other way around searching directly the `res.users` model. | Tasks | Before | After | | :--- | :--- | :--- | | 300K | 30s | 1.4s | opw-5942477 Forward-Port-Of: odoo/enterprise#110641
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix optimizes the process to avoid unnecessary calls, ensuring smoother and more reliable handling of multicurrency accounting data. This improves the stability of the system when dealing with complex financial configurations.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111361 Forward-Port-Of: odoo/enterprise#111101
This update resolves an issue where the WhatsApp Business Account webhook would crash when multiple phone numbers were linked to the same account. Odoo's design allows for multiple phone numbers per account, but this change prevents the system from encountering errors when processing webhooks triggered by these configurations. This ensures more reliable WhatsApp integration for our users.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
This update fixes a previous issue where clicking on the 'Initial Demand' in the stock valuation report opened the wrong account.view without relevant filters. Now, the click redirects to the correct account.move.line, displaying the initial balance and related information, improving the report's usability and accuracy.
Original PR description
Currently the initial demand click will open the account.move view without filter. So you don't know what is related to the initial balance or not. This commit updates the action to use a domain on the accounts used by inventory valuation. Also it shows the account.move.line instead. It also add a date if needed to be concistent with the reprot. Task: 6024514 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#253907
This pull request updates the core spreadsheet component within Odoo. It includes several bug fixes and improvements related to formula handling, clipboard pasting, chart display, and dark mode compatibility. These changes enhance the spreadsheet's functionality and usability for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/96788195e8 [REL] 19.1.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/96788195e8 [REL] 19.1.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cf6623c833 [FIX] Formulas: fix missing debugger char in formula reconstruction [Task: 6019586](https://www.odoo.com/odoo/2328/tasks/6019586) https://github.com/odoo/o-spreadsheet/commit/d94c753b98 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) https://github.com/odoo/o-spreadsheet/commit/2efaf919b0 [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009) https://github.com/odoo/o-spreadsheet/commit/e9dfa413aa [FIX] filters: allow criterion filter in dashboard [Task: 6017734](https://www.odoo.com/odoo/2328/tasks/6017734) https://github.com/odoo/o-spreadsheet/commit/5e7fb8cc7b [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296) https://github.com/odoo/o-spreadsheet/commit/d15681ef92 [FIX] composer: composer hover in dark mode [Task: 5928811](https://www.odoo.com/odoo/2328/tasks/5928811) https://github.com/odoo/o-spreadsheet/commit/e7624a90ee [REV] composer: use opacity rather than color alpha [Task: 5928811](https://www.odoo.com/odoo/2328/tasks/5928811) https://github.com/odoo/o-spreadsheet/commit/f542f0d387 [FIX] standalone_composer: wrong composer content on start edition [Task: 6022743](https://www.odoo.com/odoo/2328/tasks/6022743) https://github.com/odoo/o-spreadsheet/commit/b8f8da346e [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a layout issue caused by a recent change designed to prevent unwanted clicks in the FileUploader. The fix adds a class to correct the spacing, ensuring the UI remains properly aligned and functional. This improves the user experience when uploading files.
Original PR description
This PR completes the changes introduced in: https://github.com/odoo/odoo/commit/2cbb735f5eecb7c31db8245b8d598d7193992a05 ### Issue: A `<div>` was added to prevent click propagation in the FileUploader, but it introduced unintended extra spacing in several parts of the UI ### Cause: The added `<div>` affected the layout by taking up space where it should not ### Fix: A specific class is added to neutralize the layout impact of this element while preserving the click propagation behavior ### Steps to reproduce: - Install `hr' - Create a new Employee - Go in Private Information > Work Permit - Upload a file Before the fix, the edition's buttons are in another line opw-5918379 Forward-Port-Of: odoo/odoo#254982
This update adds a crucial test to ensure that changes to the database code don't unintentionally break the sequence feature. The test uses a 'savepoint rollback' to verify the system can recover from potential issues, enhancing stability and reliability. This prevents silent failures and ensures data integrity.
Original PR description
The aim of this commit is to ensure the feature doesn't get silently broken in case some underlying code gets reworked. task-id: None Forward-Port-Of: odoo/odoo#255053
This update resolves an issue where creating multiple stock valuation closings with different accounting dates resulted in an error. The fix ensures the system correctly considers the accounting date when validating closing entries, preventing the 'Invalid Operation' error. This improves the reliability of inventory valuation processes.
Original PR description
**Issue**: Making two stock valuation closings with different accounting dates in the past, on the same day, leads to an "Invalid Operation" error. **Steps to reproduce**: - In settings, set…
**Issue**: Making two stock valuation closings with different accounting dates in the past, on the same day, leads to an "Invalid Operation" error. **Steps to reproduce**: - In settings, set inventory valuation at invoicing - Create 2 bills of a storable product:: - `Accounting date` = `bill date` = today - 2 days - `Accounting date` = `bill date` = today - 4 days - Go to Accounting > Review > Inventory > Inventory Valuation - Set the day to today - 3 days, generate and post the entry - Go back the Inventory Valuation - Set the day to today - 1 day, generate the entry -> Invalid Operation error: the system thinks it exists a closing entry after the selected date. **Cause**: The regression was introduced by commit https://github.com/odoo-dev/odoo/commit/594654deb84ba45e9a6a765b89de79e4ce4e4b50 Indeed, `_get_last_closing_date` was modified to prioritize the creation date of the closing instead of its accounting date: https://github.com/odoo/odoo/blob/594654deb84ba45e9a6a765b89de79e4ce4e4b50/addons/stock_account/models/res_company.py#L336 As a consequence, the second closing with at_date = today - 1 day was compared against last_closing_date = today (creation date): https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/res_company.py#L53-L55 **Solution** To avoid to revert this commit https://github.com/odoo-dev/odoo/commit/594654deb84ba45e9a6a765b89de79e4ce4e4b50 fix, both creation and accounting date are used. opw-5559264 Forward-Port-Of: odoo/odoo#249734
2 changes
Resolved issues and error corrections
This update corrects a minor bug in the SendCloud delivery service that was preventing proper processing of shipments. The issue stemmed from incorrect Python slicing, which caused an error when attempting to retrieve data. The fix ensures reliable delivery processing.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class. Forward-Port-Of: odoo/enterprise#111254
This update resolves an issue where the WhatsApp webhook functionality crashed when a WhatsApp Business Account was linked to multiple phone numbers. Odoo's design allows for this, but the original code incorrectly attempted to access security information from multiple records, leading to a system error. This fix ensures the webhook process is stable and reliable, even with multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
2 changes
Resolved issues and error corrections
This update corrects a bug in the Sendcloud delivery service that was preventing accurate data retrieval. The original code incorrectly sliced a list, leading to an error when attempting to access the first element. The fix ensures the correct data is retrieved, improving the reliability of delivery tracking.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class. Forward-Port-Of: odoo/enterprise#111254
This update resolves an issue where the WhatsApp webhook functionality crashed when a WhatsApp Business Account was linked to multiple phone numbers. Odoo’s design allows for this, but the system incorrectly attempted to access security information from multiple records, leading to a failure. This fix ensures the webhook process is stable and reliable, even with multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
2 changes
Resolved issues and error corrections
This update corrects a minor bug in the SendCloud delivery service that was preventing proper processing of delivery requests. The issue stemmed from incorrect slicing of data within the Odoo system, which caused an error. The fix ensures accurate delivery processing and avoids disruptions.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class. Forward-Port-Of: odoo/enterprise#111254
This update resolves a critical issue where the WhatsApp webhook functionality crashed when a WhatsApp Business Account was linked to multiple phone numbers. Odoo’s design allows for this, but the original code incorrectly attempted to access security information from multiple records, leading to a system error. This fix ensures the webhook process is stable and reliable, even with multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
24 changes
Resolved issues and error corrections
This update resolves a performance issue in the Followup Report, which was significantly slower in version 19.1 compared to 19.0. By simplifying the filtering process, this change optimizes report loading times, preventing potential cron job timeouts and improving overall system responsiveness.
Original PR description
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1…
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out. This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field. While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime. Forward-Port-Of: odoo/enterprise#110966
This update fixes a performance issue with the budget report, ensuring it runs efficiently when the account_budget_purchase module is active. Previously, a change introduced a bug that caused slow report generation. This fix restores the optimized performance previously achieved in another module.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127 Forward-Port-Of: odoo/enterprise#110859 Forward-Port-Of: odoo/enterprise#109322
This update clarifies error messages when payments are declined due to country restrictions. Previously, the message was generic ("Country not allowed"). Now, the system uses the actual vendor location to provide a more relevant and helpful error message, improving the user experience for international payments.
Original PR description
A company in belgium creates a card, it's "allowed countries" is set to Belgium by default. If said card is used to pay online on a website ending with .be, it is understandable that the user believes the vendor to be located in Belgium If it is not the case (the vendor is actually in Luxembourg), the payment is refused but the message on the refused expense is unclear "Country not allowed" The change adds the data received to make the decision in the error message task: 5478443 Forward-Port-Of: odoo/enterprise#110613 Forward-Port-Of: odoo/enterprise#103974
This update resolves a validation error with ARCA (the Argentinian tax authority) that prevented invoices from 'Final Consumers' without VAT/CUIT numbers from being processed correctly. The system now automatically handles these transactions, sending a valid 'null' value to ARCA, ensuring invoices are successfully validated and submitted.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error. Forward-Port-Of: odoo/enterprise#106881
This update corrects a recent change that disabled a key feature – the display of seconds – in MRP modules. To ensure accurate time tracking within MRP processes, this setting has been re-enabled. This ensures MRP modules accurately reflect time-based activities.
Original PR description
Previously, showSeconds was True by default. It has now been set to False by default so we need to enable it for MRP modules. Forward-Port-Of: odoo/enterprise#111269
This update fixes an issue where the Spanish balance sheet incorrectly excluded certain retained earnings, leading to inaccurate equity calculations. The change ensures all relevant equity accounts are included, guaranteeing consistent and reliable equity totals for Spanish businesses. This improves the accuracy of financial reporting.
Original PR description
Description of the issue this commit addresses: The ES balance sheet “prior periods” line only matched code 12, so retained/unaffected earnings posted on other codes were skipped, which could understate or skew equity totals. --- Desired behavior after this commit is merged: The line now includes both accounts with code 12% and accounts of type equity_unaffected, so carried-forward results are always included and equity totals stay consistent. --- task-6047627 Forward-Port-Of: odoo/enterprise#111249
This update resolves an error that occurred when creating payments for invoices using the Bacs Direct Debit method. The issue was triggered when a user removed the bank account number from the relevant journal. Now, the system correctly prevents the payment creation and displays a clear error message, ensuring accurate invoice payment processing.
Original PR description
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the…
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`. - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero. - `Confirm` the invoice. - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`. `ValueError: Expected singleton: res.partner.bank()` This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment method. The constraint check bacs bank account trigger [1], but since the journal has no bank account number, it raises an error here [2]. Similar error also occurs when validating a batch payment [3]. This commit ensures that if the journal has no bank account, or if the bank account is invalid, the system raises the same validation error. In batch mode, it raises a UserError when the account is missing. [1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58 [2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19 [3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74 sentry-7259107152 Forward-Port-Of: odoo/enterprise#107235
This update resolves a problem where the company logo was appearing too large on various financial reports. The fix targeted a generic CSS selector that was affecting multiple reports, ensuring consistent logo sizing across the enterprise platform. This improves the visual presentation of key financial documents.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432 Forward-Port-Of: odoo/enterprise#110858
This update fixes a previous issue where the tax returns journal wasn't automatically translated into all supported languages. The team has now implemented a standard translation process, ensuring the journal is correctly translated for all users and languages, improving accuracy and usability.
Original PR description
Currently, the tax returns journal is created in the code and not via the standard `@template` function that makes sure it is always translated in the installed languages. So for now it was only translated in language of the current user. We refactored the code so the journal gets created via the standard `@template` function and thus automatically gets translated into all the installed languages. task-5921458 Forward-Port-Of: odoo/enterprise#111261 Forward-Port-Of: odoo/enterprise#107465
This update resolves issues related to processing physical cards through Stripe, specifically for UK users. It includes fixes for missing ETA information and incorrect shipping status handling, ensuring accurate expense tracking and preventing errors during card creation. Additionally, improved logging has been added to aid in debugging test failures.
Original PR description
Forward-Port-Of: odoo/enterprise#110880 Forward-Port-Of: odoo/enterprise#110263
This update fixes an issue in the GSTR report testing process. Previously, the tests were incorrectly deleting tax amounts. Now, the system removes taxes from the account move line, ensuring more accurate report calculations and compliance. This change improves the reliability of the GSTR reports.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111384 Forward-Port-Of: odoo/enterprise#105174
This update streamlines the new user sign-up experience by removing unnecessary steps in the automated tour. This improves the onboarding process, making it faster and more intuitive for new customers to get started with Odoo Enterprise. The change is a simple fix to enhance user experience.
Original PR description
runbot-238363 Forward-Port-Of: odoo/enterprise#110843
This update corrects a minor issue where ticket buttons in the Helpdesk email templates were incorrectly identified as links. The change ensures buttons are properly recognized and function as intended within the editor, improving the user experience when editing ticket messages. This resolves a visual inconsistency and ensures buttons work as expected.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#111215 Forward-Port-Of: odoo/enterprise#107888
This update corrects a technical issue in the Peruvian tax implementation (l10n_pe_edi) that resulted in incorrect tax calculations for Tiered Sales Tax (ISC). The original refactor removed a key element needed for accurate tax generation, and this PR restores it to ensure proper tax reporting for Peruvian businesses.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598 Forward-Port-Of: odoo/enterprise#111061
This update corrects a technical issue where archived partners were incorrectly identified during bank statement retrieval, leading to inaccurate partner assignments. Now, the system only considers active partners when searching for bank statements, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of our accounting processes.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#111259 Forward-Port-Of: odoo/enterprise#110446
This update removes outdated code related to a previous worksheet feature. The removal of a redundant context key ensures the system runs more efficiently and reliably. This change improves the overall performance of the web studio interface.
Original PR description
Since the worksheet rework, the context key `worksheet_no_generation` that used to skip the model generation has now become useless. This commit removes last lines of code using it. *https://github.com/odoo/enterprise/commit/49a84d3ffea49cf8f7fea904e7082b101158bbe9 Forward-Port-Of: odoo/enterprise#110339
This update addresses a technical issue that caused tracebacks in the timesheet assistant when a user didn't have an assigned employee within the company. The fix ensures the assistant functions correctly for all users, preventing errors and improving the user experience. This resolves a minor instability.
Original PR description
This PR fixes two tracebacks when the current user has no employee in the current company and tries to open either the timesheets assistant or systray Task-6041462 Forward-Port-Of: odoo/enterprise#110815
This update resolves an error that occurred when setting tax return periods for Dutch companies in the Odoo Enterprise system. The issue stemmed from a misconfiguration during a recent update, and this fix restores the correct function call to ensure accurate tax return period setup. This prevents a crash when users try to configure these periods.
Original PR description
Currently, an error occurs when configuring tax return periods for a Netherlands company. - This PR [97615](https://github.com/odoo/enterprise/pull/97615) introduced the…
Currently, an error occurs when configuring tax return periods for a Netherlands company. - This PR [97615](https://github.com/odoo/enterprise/pull/97615) introduced the `_get_tax_tags_for_nl_sales_report()` function - In the 19.1 fw port, the implementation is different. This function is neither added nor called. Instead, `_get_ec_sales_tax_tags()` is called in its place. - In the 19.2 fw the function is still missing, but it is called, so it does `Traceback` `AttributeError: 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report'` We fix this by using `_get_ec_sales_tax_tags()` in `19.2`, just as `v19.1` does. **Steps to reproduce:** - Install `l10n_nl_reports` and `accountant` modules - Set up an `NL company`. - Go to `Accounting > Tax Returns > Set Periods`. - Set the date - Click `Apply` Tickets links: [6035534](https://www.odoo.com/odoo/project.task/6035534), [6045553](https://www.odoo.com/odoo/project.task/6045553), [6045241](https://www.odoo.com/odoo/project.task/6045241), [6037249](https://www.odoo.com/odoo/project.task/6037249) opw-6035534 opw-6045553 opw-6045241 opw-6037249 Forward-Port-Of: odoo/enterprise#110820
This update resolves a technical issue within the l10n_co_edi_pos module related to how a template was being constructed. The fix ensures proper formatting of POS receipts, preventing potential display problems. This change improves the reliability of the receipt generation process.
Original PR description
`class` cannot be set on the `t` element. Moving to the `div`. runbot-242041 runbot-242042 Forward-Port-Of: odoo/enterprise#111450
This update fixes a technical error that prevented users from saving planning slot forms when attempting to add resources. The issue stemmed from attempting to access records that had already been deleted. This change ensures smoother operation and prevents data saving failures in specific scenarios.
Original PR description
This error occurs upon saving a `planning.slot` form view. Steps to reproduce: - Install `planning_field_service` module - Settings > Technical > Discuss > `Subtypes` - Delete `Field Service Resources Changed` & `Field Service Status Changed` - Planning > New(open form view) > Add `Resources` and Save Traceback: `ValueError: External ID not found in the system: planning_field_service.mt_intervention_resources_changed` The error occurs because, in the `_track_subtype` [method], we attempt to retrieve a reference to records that have already been deleted. [method]: https://github.com/odoo/enterprise/blob/7e1a72d75ca672ea3660cc236f93571a441bb734/planning_field_service/models/planning_slot.py#L145-L150 sentry-7338382431 Forward-Port-Of: odoo/enterprise#110824
This update corrects a technical error in the Planning module's role search filter. Previously, the filter incorrectly used string IDs, causing issues with selecting roles. This fix ensures the filter uses correct integer IDs, improving the reliability of role selection within the Gantt view.
Original PR description
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the…
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the selection dialog 4. In the pop-up window, observe that a default filter is already applied 5. Click on the Roles filter in the search panel Observation: ------------------------------------------ The filter on the Roles field applies an 'Invalid Record ID' in the domain Issue: ------------------------------------------ the default filter on `role_ids` passes the role ID as a string (e.g., 4) instead of an integer (4). This happens because the `filter_domain` uses `[self]`, and `self` is substituted with `label.trim()` in `_getFieldDomain`, which is always a string even when the underlying value is a numeric ID https://github.com/odoo/odoo/blob/accaa246d5818572996660f967624978e906b5c3/addons/web/static/src/search/search_model.js#L1747-L1750 Solution: ------------------------------------------ Replace `[self]` with `[raw_value]` in the `filter_domain` of the `role_ids` search field, the `raw_value` variable holds the actual typed value (integer ID) instead of the string label. opw-6003611 Forward-Port-Of: odoo/enterprise#109781
This update significantly speeds up the process of expanding project tasks to include related users. Previously, a slow search query was triggered repeatedly, impacting performance with a large number of tasks. The change now uses a more efficient search method, resulting in a 10x performance improvement.
Original PR description
Before this commit, expanding the `user_ids` involved fetching all the tasks satisfying a domain by a search call and returning only the active users by accessing the field `user_ids` from the fetched recordset of tasks. This approach introduced slowness with a big number of `project.task` since for each batch of **1000** records, a `__get__` call on the field will trigger an `SQL` query. I have updated the code to have the inverse field `task_ids` in the `res.users` model and did the search, the other way around searching directly the `res.users` model. | Tasks | Before | After | | :--- | :--- | :--- | | 300K | 30s | 1.4s | opw-5942477 Forward-Port-Of: odoo/enterprise#110641
This update resolves issues where the timesheet timer wasn't accurately tracking attendance and changes weren't consistently saving to all timesheets. Specifically, it now correctly pauses the timer when checked out and ensures all timesheet edits are saved regardless of whether they're new or existing records, leading to more reliable timesheet data.
Original PR description
This PR fixes two bugs in the timesheets systray: - The timer does not take into account the moments when you are checked out on attendance - When closing the systray without saving, changes are only saved for a new timesheet, not on existing ones Task-6042077 Forward-Port-Of: odoo/enterprise#111096
This update simplifies the softphone's user interface by removing complex z-index management, resolving stacking issues that caused disruptions with modals and calls. It ensures the softphone consistently appears as an overlay, improving usability and stability without impacting core functionality.
Original PR description
Before this commit, the `Softphone` component was instantiated as part of the `SoftphoneContainer`, main component of the backend. After this commit, the `SoftphoneContainer` now renders nothing and…
Before this commit, the `Softphone` component was instantiated as part of the `SoftphoneContainer`, main component of the backend. After this commit, the `SoftphoneContainer` now renders nothing and manages the `Softphone` component by showing it, or not, as an *overlay*. This comes with several functional and technical advantages / fixes. TECHNICAL: The z-index of the main softphone component changed multiple times over the years. Commit [1] forced the softphone on top of all modals always, commit [2] changed it to be below of all modals always without any kind of explanation, big refactorings at [3] and [4] kept kinda the same "below all modals" behavior, then finally commit [5] recently made it more complex by forcing the softphone on top of modals during calls and, to keep things working, it forced all "voip dropdowns" on top of *everything* at all times... all of that messing with z-indexes which is basically never a good idea. The result is that it was now needed to identify "voip dropdowns" with a specific "o-voip-dropdown" class, which is a source of mistake and complexity especially when using standard components that could open standard dropdowns themselves. With this commit: no more extra classes and no more messing with z-indexes at all. FUNCTIONAL: A) Stacking bug Messing with z-index as explained above led to wrong stacking order: - Open the softphone - Open the availability dropdown at the top left (in prod mode) - Open the user preferences modal (in Odoo navbar) (or any other) => Bug: it is between the softphone and its dropdown (this can be seen by moving the modal or being on a smaller screen but also by the fact the dropdown is not faded and can still be interacted with). B) Softphone / Modal / Calls flow As proven by the [1] -> [5] series, there is no good "softphone always at the bottom/top" rule. What is really wanted is the softphone to act as any other overlay in Odoo: when it opens, it is at the top. Then if other things are opened, they also open at the top. The only exception at the moment being "what if I receive a call while I have dialogs that are opened?": simple, this commit closes the softphone and re-opens it so it is now at the top of overlays again, just like if the user asked that overlay to open. Then during the call, if the user wants to open a modal again, it opens above the call to be usable (which [5] "broke"). Then if the user wants to access what is below (the modal or the softphone), just like always, the user must close what is on top (the modal / the softphone). We could also later have a button to "move the softphone on top" just like when receiving a call, that might also be a good idea to not have to close top modal to use the softphone... but in general we just rely on users closing what is in front of them. Recently we also introduced the PiP mode at [6] which minimizes the need of wanting to keep the whole softphone on top. [1]: https://github.com/odoo/enterprise/commit/12b3c8d1cdfda64bbe13528f08c0cb11bcbfb466 [2]: https://github.com/odoo/enterprise/commit/767e9123fe627313c75f8eb2c324ea9d8e6e09f6 [3]: https://github.com/odoo/enterprise/commit/bbdb033031720365c448c6f3de40906ee0c4243e [4]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd [5]: https://github.com/odoo/enterprise/commit/eb5a1e9b41f5b08821ad5e8a6e6e32d7bad07f46 [6]: https://github.com/odoo/enterprise/commit/2170ada30120f9d60bb039d5b384d5a081c85509 task-6052118
14 changes
Resolved issues and error corrections
This update cleans up the error messages displayed in the account reports, making them easier to understand for users. The VIES check hyperlink has been removed from the stable version due to display limitations. This change focuses on improving the user experience and clarity of account reporting.
Original PR description
The company data check message was on multiple line. image The VIES check hyperlink wasn't Markup, since we cant easily display it, we will remove it in stable.
This update resolves a technical issue where the Planning module's role search filter was incorrectly passing record IDs as strings, causing errors. The fix ensures that record IDs are correctly interpreted as integers, improving the reliability of role selection within the Gantt view.
Original PR description
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the…
Steps to reproduce: ------------------------------------------ 1. Install Planning module 2. Click on any shift in Gantt view > Edit 3. In the Resource field, click on Search More to open the selection dialog 4. In the pop-up window, observe that a default filter is already applied 5. Click on the Roles filter in the search panel Observation: ------------------------------------------ The filter on the Roles field applies an 'Invalid Record ID' in the domain Issue: ------------------------------------------ the default filter on `role_ids` passes the role ID as a string (e.g., 4) instead of an integer (4). This happens because the `filter_domain` uses `[self]`, and `self` is substituted with `label.trim()` in `_getFieldDomain`, which is always a string even when the underlying value is a numeric ID https://github.com/odoo/odoo/blob/accaa246d5818572996660f967624978e906b5c3/addons/web/static/src/search/search_model.js#L1747-L1750 Solution: ------------------------------------------ Replace `[self]` with `[raw_value]` in the `filter_domain` of the `role_ids` search field, the `raw_value` variable holds the actual typed value (integer ID) instead of the string label. opw-6003611
This update fixes an issue where portal users weren't able to view timesheets linked to projects with 'Invited internal and portal users' visibility. The change expanded the domain to include both 'portal' and 'invited_users' visibility options, ensuring shared timesheets are correctly displayed to portal users.
Original PR description
Steps to reproduce: - Create Project A with visibility set to `Invited internal and portal users.` - Create a Helpdesk Team and assign Project A to it. - Create a helpdesk ticket. - Log a timesheet…
Steps to reproduce:
- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.
Cause:
- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.
- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`
- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.
Solution
Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`
- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.
task-5924243This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update resolves an issue where the website's tour process was experiencing delays loading translations, particularly in recent Chrome versions. The fix introduces a temporary step to ensure translations load before the tour begins, preventing interruptions and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update fixes a bug where project timesheets didn't accurately reflect changes in employee costs when switching workers on a manufacturing order. The fix automatically adjusts the AAL (analytic accounting line) linked to the work center, ensuring accurate timesheet calculations and reporting. This improves the reliability of project cost tracking.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#109695
This update resolves an issue preventing new employee creation when generating BVG-LLP reports in the Swiss module. The fix addresses a technical problem with how Odoo compares report data, ensuring correct employee creation functionality. This ensures accurate payroll calculations for Swiss companies.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335This update fixes an issue with the numbering of report lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was corrected. This ensures the report data is presented in a clear and accurate format for Vietnamese users.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a problem in the GSTR 2B report testing process. Previously, the tests were incorrectly deleting tax amounts. Now, the system properly removes taxes from the account move line, ensuring accurate report calculations and compliance. This resolves a potential discrepancy in tax reporting.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111198 Forward-Port-Of: odoo/enterprise#105174
This update resolves a potential error in the automatic import of bank statements when multiple journals share the same IBAN but use different currencies. The fix prevents a 'singleton error' by streamlining the process of retrieving essential data, ensuring accurate journal matching and statement dispatching.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111250 Forward-Port-Of: odoo/enterprise#111101
This update corrects a sizing problem affecting the company logo on various Odoo reports. The previous CSS selector was too broad, causing it to incorrectly resize logos across multiple report templates. This change ensures consistent and accurate logo display in all financial reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432 Forward-Port-Of: odoo/enterprise#110858
This update resolves an issue where tax calculations for invoices in Peru (PE) were incorrect due to a missing configuration. The team re-introduced a key element, 'TierRange,' within the tax category settings, ensuring accurate tax calculations for ISC (Impuesto Sobre la Renta) taxes on PE invoices. This ensures compliance and accurate financial reporting for our Peruvian customers.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598 Forward-Port-Of: odoo/enterprise#111061
This update corrects a bug in the SendCloud delivery service that was caused by incorrect Python slicing. The fix ensures that the correct element is retrieved, preventing an error and maintaining proper service functionality. The issue was not caught during testing due to a configuration oversight.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class. Forward-Port-Of: odoo/enterprise#111254