Daily updates from Odoo
Tuesday, February 10, 2026
190 changes
16 changes
Security fixes and vulnerability patches
This update resolves security issues related to copying spreadsheets and dashboards within the Enterprise edition. By removing unnecessary security checks, users can now copy these documents without requiring elevated permissions, streamlining the process and improving usability.
Original PR description
In order to be able to copy a spreadsheet or a dashboard on which the user has access to, without requiring a bunch of extra security rights, this fix removes the need to - when copying a dashboard, the copy of the field 'main_data_model_ids' that is only used on standard dashboards, would require the read right on ir_model for no good reasons - when copying any spreadsheety document (spreadsheet, dashboard, etc.) the remove the field spreadsheet_revision_ids from the data sent by the client, so the field security won't be triggered on an empty field Forward-Port-Of: odoo/enterprise#99931
New functionality added to Odoo
This update introduces a new module to generate a required .csv file (FAF) for the Federal Tax Authority (FTA) audits. This allows businesses to meet FTA reporting requirements and move closer to accreditation, ensuring ongoing compliance with UAE tax regulations. The generated file contains essential invoice data for the FTA audit process.
Original PR description
The Federal Tax Authority (FTA) requires businesses to generate a FAF (FTA Audit File) for audit and compliance purposes in a .csv format. There are two kinds, VAT and Excise. In this task, we aim to…
The Federal Tax Authority (FTA) requires businesses to generate a FAF (FTA Audit File) for audit and compliance purposes in a .csv format. There are two kinds, VAT and Excise. In this task, we aim to generate a successful VAT Audit File, whereas we we will work to support the Excise Taxes and it's audit file in a separate task. This will bring us a step closer to re-registering us as an Accredited Software Vendor with the FTA (https://tax.gov.ae/en/tax.support/tax.accounting.software.vendors/accredited.tax.accounting.software.vendors.aspx). As per the FTA, "The FAF should be a pure collection of data in the comma-separated values (csv) file format and should be broken down by, but not limited to, invoices, credit notes etc., to give all the required information to FTA to conduct the Audit. The taxpayer should not be able to modify any value in the FAF. The FAF should not be an image file." This PR introduces a new module l10n_ae_saft which allows the users to export the a FAF .csv file from the general ledger. task-5256491 Forward-Port-Of: odoo/enterprise#99228
Enhancements to existing features
This update enhances the bank reconciliation feature by prioritizing key information like date, label, and balance at the top of the list view. It also optimizes scrolling within the table, ensuring a smoother and more user-friendly experience for managing bank statements.
Original PR description
1. The bank statement line info (date, label and balance) are moved to the top now. 2. Scrolling only applies to the table rows (other elements are fixed). task-5212851 Forward-Port-Of: odoo/enterprise#103709
Resolved issues and error corrections
This update resolves a bug preventing users from installing modules after setting up the SEPA accounting module in Odoo Enterprise. The issue stemmed from a failure to automatically refresh the system's module registry, delaying the actual installation process. This ensures modules install correctly after SEPA configuration.
Original PR description
Encountered this bug while trying to reproduce a bug from one of my ticket. **STEP TO REPRODUCE** On a fresh db with module account_accountant. 1. Create a new company with country set to Belgium. After l10n_modules are install, and the chart template loaded: 2. Try installing a module, and notice you can't. **CAUSE** button_install() doesn't reload the registry, so the sepa modules states are set to `to install` but are not install until the registry is reloaded, which doesn't happen on its own. button_immediate_install() does the same as button_install(), and reload the registry which trigger the actual installation process. Forward-Port-Of: odoo/enterprise#106033
This update resolves a test failure caused by a recent change to the _is_downpayment method. The commit simply adds the necessary update to the test suite to account for this new method extension, ensuring the system continues to function correctly.
Original PR description
The PR odoo/odoo#244443 introduces a new extension to the method _is_downpayment hence the test fails since it is not patched. This commit adds the new extension to the patched list. task-5135918 Forward-Port-Of: odoo/enterprise#106618 Forward-Port-Of: odoo/enterprise#105165
This update resolves an issue where accents in legal names were being removed, preventing proper recognition by Mexican tax authorities (SAT). The fix restores the correct handling of accented characters, ensuring accurate data submission for Mexican e-invoices. This ensures compliance with Mexican tax regulations.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update corrects a bug in the salary configurator where the fuel card benefit would incorrectly appear enabled if no company car was chosen. The fix ensures the field is properly initialized and remains disabled until a car is selected, preventing inconsistencies and ensuring accurate reporting.
Original PR description
On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load. Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages. task-5156562 Forward-Port-Of: odoo/enterprise#105037
This update adjusts the taxonomy used for Dutch tax reports to align with the latest NT20 standard. This change ensures continued compliance with Dutch tax regulations and maintains compatibility with older versions of the reporting system. No new functionality was added.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where the yearly employer cost calculations in the HR contract salary module were inaccurate. The fix re-introduced a previously reverted change that correctly included representation fees, ensuring accurate cost projections. This improves the reliability of financial reporting.
Original PR description
This PR converted fields/benefits into properties: https://github.com/odoo/enterprise/pull/96385 Then, this PR reverted the changes: https://github.com/odoo/enterprise/pull/101672 But the representation fees benefits was forgotten. This was causing the yearly employer cost to be computed without the representation fees.
This update simplifies the sales order reporting for subscription customers. The 'remaining hours' field, which could be misleading due to the recurring nature of subscriptions, has been hidden when a line is linked to a subscription. This ensures a cleaner, more intuitive experience for our customers.
Original PR description
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference…
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic. In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle. To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription. opw-5246238 Forward-Port-Of: odoo/enterprise#106807 Forward-Port-Of: odoo/enterprise#99813
This update resolves an issue where invoices with note or section lines at the top would cause export errors. The fix filters out these lines during currency rate calculations, ensuring invoices are correctly generated and sent for export. This prevents disruptions in invoice processing and reporting.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update fixes a reporting issue related to withholding taxes for Spanish businesses (l10n_es_reports). It ensures that specific tax types (347) are correctly handled in accounting moves, improving the accuracy of financial reports. This change addresses a technical detail impacting Spanish tax compliance.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106889 Forward-Port-Of: odoo/enterprise#105597
This update resolves a potential instability issue in the document search functionality. The team corrected a programming error that could have resulted in missing context information, leading to errors. This change ensures a more reliable search experience.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
This update simplifies the salary configuration process by hiding temporary offers created by the salary simulator from the user interface. These offers are automatically removed after a month by a scheduled task, so this change only improves clarity and prevents user confusion.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#104493
This update fixes an issue where the system incorrectly calculated employee expenses when both a private and company car were declared as part of the same occupation. The change ensures accurate expense reporting by properly accounting for both vehicle types, improving payroll accuracy and compliance.
Original PR description
…occupation Forward-Port-Of: odoo/enterprise#106865
This update ensures that screenshots taken during the trial mode of Odoo Enterprise capture the correct end-result data. Previously, the system lacked the database URL needed to fetch this data. Now, the database URL is forwarded, allowing for accurate and complete trial mode screenshots.
Original PR description
During the trial flow, we don't know the db url when making the ws request. To still be able to take screenshots of the end result in trial mode, we forward the db_url when getting the result back.
6 changes
Enhancements to existing features
This update adapts the French reporting process to changes in how financial data is exported from Odoo. Instead of downloading entire files, data is now streamed to the user, improving efficiency and reducing download times. This change ensures accurate and timely reporting for French customers.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#106108 Forward-Port-Of: odoo/enterprise#102783
Resolved issues and error corrections
This update resolves an issue where accents in legal names for Mexican tax documents (CFDI) were being incorrectly removed. This fix ensures that the system correctly recognizes and processes names containing characters like 'ë', which is essential for accurate tax reporting and compliance with Mexican regulations. The change impacts the l10n_mx_edi module.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update adjusts the taxonomy used for Dutch tax reports from NT19 to NT20, a standard change required for compliance. The update only involves namespace adjustments and maintains compatibility with older versions of the XBRL template. This ensures continued accurate reporting for our Dutch clients.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where invoice exports were failing when invoices contained a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update resolves a potential instability in the document search functionality. Previously, the system relied on a private internal method to access context information, which could sometimes return null values. This change utilizes a public API to ensure a reliable context is always available, improving search stability and preventing errors.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
This update fixes critical issues related to rental scheduling, preventing users from creating conflicting shifts and ensuring resources are properly allocated. The changes improve the accuracy of shift availability and prevent incorrect order creation, ultimately streamlining the rental process.
Original PR description
## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift Before this commit, the user could update the shift linked to a rental order and creating a conflict with another shift…
## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift Before this commit, the user could update the shift linked to a rental order and creating a conflict with another shift for the same resource and so, it would be impossible for the resource to be in 2 spaces at the same time (or it is impossible to rent a room to 2 different customers). This commit returns an Validation Error if the user updates the planned dates of a rental shift and creates a conflict. ## [FIX] sale_renting_planning: add problematic shifts only if rental order Before this commit, the previous fix making sure the error, saying no resource is available during the generation of a shifts when the user confirms a sale order, is only displayed when the `Sync Shifts and Rental Orders` is enabled, could potentially never display the error when it should be expected because we only check if the last SOL of the batch to generate shifts has the feature enable or not. This commit makes sure the error is correctly displayed as expected. ## [FIX] sale_renting_planning: update condition of Rental buttons in shift Before this commit, the user could click on Create order button for an open shift is the role having the rental feature enabled. To problem is a resource is required to make sure the rental order can be delivered. About the other button shown, `Add to Last Order` one, this one could be clicked even if the shift is in conflict with another shift and so, it will display a warning saying no resource is available. This commit makes sure - `Create Order` button in shift form view is not visible when the shift is a open shift. - `Create Order` and `Add to Last Order` buttons in shift form view are not displayed when the shift is in conflict. task-5065930
9 changes
Resolved issues and error corrections
This update resolves an issue where accents in legal names were being incorrectly removed, preventing proper recognition by Mexican tax authorities (SAT). The fix restores the correct handling of accented characters, ensuring accurate data submission for Mexican e-invoices. This improves compliance and avoids potential processing delays.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update fixes a reporting issue related to withholding taxes for Spanish businesses (l10n_es_reports). Specifically, it ensures that the 'type for 347' field is left blank when processing invoices with withholding taxes, aligning with Spanish tax regulations. This ensures accurate financial reporting.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106796 Forward-Port-Of: odoo/enterprise#105597
This update corrects a bug where the email address for Belgian customers wasn't being included in VAT reports. The fix automatically pulls the email from the customer's contact information, ensuring accurate reporting and compliance. This prevents missing email data in crucial financial documents.
Original PR description
**Steps to reproduce:** - Install l10n_be_reports and contacts - Switch to a Belgian company (e.g. BE Company CoA) - Go to Contacts - Open the company contact (i.e. BE Company CoA) - Add an invoice address withtout email - Create an invoice: * Customer: [a Belgian customer with a VAT number] * Invoice Lines: [a line with a tax] - Confirm the invoice - Go to "Accounting / Reporting / Belgium / Partner VAT Listing" - Export the XML **Issue:** In the XML, "<EmailAddress>" is empty althouth it is mandatory. **Cause:** The email is retrieved from the invoice address, but there is no fallback on the parent contact if it is empty. **Solution:** Fallback on the email of the parent contact as it is the case for the phone. opw-5870750 Forward-Port-Of: odoo/enterprise#106831 Forward-Port-Of: odoo/enterprise#105654
This update fixes an issue where anonymous users booking appointments skipped the address form during payment, leading to incorrect tax calculations. The fix ensures the address form is always displayed, guaranteeing accurate pricing and fiscal position application for all appointment bookings. This improves the overall user experience and financial accuracy.
Original PR description
**Steps to reproduce:** - Install Website/Appointment/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled -…
**Steps to reproduce:** - Install Website/Appointment/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled - Publish the event - Book an appointment with up-front payment enabled as a anonymous user - The process bypasses the address form and goes directly to payment - The resulting sale order will have no fiscal position - Prices won't be impacted by taxes related to the user billing address **Issue:** Address form is skipped before payment for appointment booking of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit). **Fix:** Set _needs_customer_address to True by default to avoid such issues in dependant modules. Might need to remove this feature in master as the workarounds are not that clean (geao_ip, check on fiscal position enabled, overwrite everywhere, others ?). related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d opw-5143124
This update adjusts the taxonomy used for Dutch tax reports from NT19 to NT20, a standard change required for compliance. The update only involves namespace adjustments and maintains compatibility with older versions of the XBRL template. This ensures continued accurate reporting for our Dutch clients.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update resolves an issue where the document search functionality could fail due to incorrect access to contextual data. By switching to a reliable public API, the system now consistently provides the necessary information for accurate document searches, enhancing stability and reliability.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
This update fixes an issue where credit notes were incorrectly displaying negative tax amounts in the tax totals widget. The fix ensures accurate tax calculations and reporting for Brazilian credit notes, improving financial accuracy and reporting reliability. This resolves a discrepancy between calculated tax and its display.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#106579
A warning was incorrectly appearing in the Belgian tax report when dealing with carryover lines, suggesting an issue where negative values were being generated. This update removes the misleading warning, ensuring the report accurately reflects the intended calculations for carryover lines. This improves the reliability of the Belgian tax reporting process.
Original PR description
The Belgian tax report was displaying a warning when a negative amount originated from all the lines even from carryover ones. This warning was misleading, as carryover lines are not supposed to generate a declared negative value. task-5411005
7 changes
Resolved issues and error corrections
This update resolves a problem where reports would display an outdated variant while waiting for the latest data to load. Now, reports will correctly wait for the full variant to load before displaying, ensuring accurate and consistent reporting. This improves the user experience and data reliability.
Original PR description
Previously, when a report was loading if a variant was selected, it would display the first one when it loaded and display the second one when it loaded. With this, we wont show the first one as we are waiting for the new one. To reproduce: - load the Demo data on the demo company - Add time.sleep(5) in _get_lines - load the Generic Tax report and wait for it to load - click on the Group by: Account > Tax and wait for 3s - click on the Group by: Tax > Account - Watch the Account > Tax load and still being displayed for 3s while the Tax > Account variant is loading. Forward-Port-Of: odoo/enterprise#105522
This update fixes an issue where credit notes were incorrectly displaying negative tax amounts in the tax totals widget. The fix ensures that tax calculations are accurate, presenting the correct tax liability for credit notes in the reporting interface. This improves the accuracy of financial reporting.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#106579
This update resolves an issue where accents in legal names were being incorrectly removed, preventing proper recognition by Mexican tax authorities (SAT). The fix ensures that names with accents, such as 'ë', are correctly processed, ensuring accurate tax reporting and compliance. This change impacts the l10n_mx_edi module.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update adjusts the taxonomy used for Dutch tax reports from NT19 to NT20, a standard change required for compliance. The update only involves namespace adjustments and maintains compatibility with older versions of the XBRL template. This ensures continued accurate reporting for our Dutch customers.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first item. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update fixes an issue where task scheduling incorrectly limited the duration, resulting in tasks being planned for only 25-26 November instead of extending into December. The fix removes previously used time slots before rescheduling, ensuring tasks are accurately planned for the required hours. This prevents underestimation of project timelines.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#101262
This update resolves a potential instability issue in the document search functionality. The team corrected a programming error that could have resulted in a missing context, leading to errors. Now, the document search process is more reliable and robust.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
34 changes
Security fixes and vulnerability patches
This update resolves security issues related to copying spreadsheets and dashboards. It simplifies the copying process by removing unnecessary security checks, allowing users to copy documents without requiring excessive permissions. This enhances usability and reduces potential security risks.
Original PR description
In order to be able to copy a spreadsheet or a dashboard on which the user has access to, without requiring a bunch of extra security rights, this fix removes the need to - when copying a dashboard, the copy of the field 'main_data_model_ids' that is only used on standard dashboards, would require the read right on ir_model for no good reasons - when copying any spreadsheety document (spreadsheet, dashboard, etc.) the remove the field spreadsheet_revision_ids from the data sent by the client, so the field security won't be triggered on an empty field Forward-Port-Of: odoo/enterprise#106348 Forward-Port-Of: odoo/enterprise#99931
Enhancements to existing features
This update introduces a more precise rental calendar system, replacing previous limitations with a resource calendar. This allows for granular control over availability, enabling scheduling of rentals based on specific dates and times, such as excluding certain days or periods.
Original PR description
Replace the unavailability days by a proper calendar. Task-5083109
This update enhances the professionalism of appraisal request emails sent to users, making them more formal. Additionally, the email content within the chat interface is now consistently visible across both light and dark themes, improving user experience. This ensures a polished and accessible process for requesting appraisals.
Original PR description
[IMP] hr_appraisal: improve appraisal request email
- When user requests appraisal (e.g. Mitchell Admin), we changed email subject and body wording to make it more formal
- When user requests appraisal, the email body in chatter not observable in UI well due to colors, now it is visible in both light/dark versions.
task - 5498786This update enhances Odoo's spreadsheet functionality by allowing users to include property fields within list views. This means data from related records can be directly displayed and edited within spreadsheets, improving data management and reporting. It's a key improvement for users working with complex data sets.
Original PR description
With this commit, we now support property fields in spreadsheet lists. Task: [3329490](https://www.odoo.com/web#id=3329490&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update adjusts how GST, TDS, and TCS reports are displayed within Odoo Enterprise. Previously, these reports were automatically visible, but now they require enabling within the settings menu. This change enhances control and streamlines the user experience for Indian businesses.
Original PR description
Before this commit:
- GST Reports are visible by default if l10n_in_reports module is installed.
- TDS / TCS Reports are visible by default.
After this commit:
- GST Reports only get visible upon enabling the functionality from setting.
- TDS / TCS Reports only get visible upon enabling the functionality.
- Improve the indian integration block in settings.
task-5248629This update enhances the bank reconciliation feature by prioritizing key information like date, label, and balance at the top of the list. It also optimizes the scrolling experience to only apply to the table data, making it easier to navigate and review transactions.
Original PR description
1. The bank statement line info (date, label and balance) are moved to the top now. 2. Scrolling only applies to the table rows (other elements are fixed). task-5212851 Forward-Port-Of: odoo/enterprise#103709
This update adjusts a key parameter within the Australian Payroll module to comply with the 2026 PEA (Pay As You Earn) tax rules. This ensures accurate payroll calculations and adherence to Australian tax regulations for our Australian clients. The change is a necessary update to maintain compliance.
Original PR description
This task updates PEA rule parameter value task-5884083 Forward-Port-Of: odoo/enterprise#106925 Forward-Port-Of: odoo/enterprise#105896
This update enhances the Open Items report by simplifying its presentation and improving color-coding for overdue amounts and negative balances. The changes also extend functionality to include payables and synchronize the report with the Partner Ledger, ensuring consistent reporting across key financial views.
Original PR description
Rework the followup report (renamed into "Open Items"): - Remove Due/Overdue grouping lines - Change the color of due date in case of overdue - Change the color of the amount if negative to blue - Account types now also include payables Some of these changes also apply to the Partner Ledger, and the code has therefore been updated to generalize to both reports (and even the customer statement report). The smart button on the partner form view leading to the Open Items Report has also seen slight visual changes, and since now the Open Items Report properly displays payables, this smart button leads to the same amount as displayed for suppliers. task-5867498
Resolved issues and error corrections
This update fixes an issue where users could see contract templates from multiple companies when creating a new offer. Now, the system automatically limits the displayed templates to only those relevant to the company the offer is being created for, ensuring accuracy and preventing confusion.
Original PR description
Currently, if you have more than one company active and go to an employee to make a new offer, you see all of the templates for all of the companies. If you select a template for a different company from the current one, the company on the employee also changes, which we don't want. With this PR, the list of templates is limited to the ones related to the company currently in use. Task: 5062941
This update ensures that all field definitions for Odoo bundles are loaded together, regardless of the order they're loaded. Previously, loading bundles sequentially could cause some definitions to be missed, leading to inconsistent behavior. This change improves the stability and reliability of Odoo across different features.
Original PR description
The JS models field definitions are applied once when the page loads. If the first bundle is loaded and a second bundle is loaded later, the field definitions in the second bundle will be missed. For example, this could happen when the live chat is loaded first and the portal chatter is loaded later. This change ensures that all model and field definitions are loaded together by including the `common` folder in all related bundles, regardless of the module in which they are defined. task-5895454 [Community PR](https://github.com/odoo/odoo/pull/247141)
This update fixes an issue where users without admin sign rights couldn't access the sample template. The change ensures that users can correctly create and manage sign items within the copied template, allowing them to proceed with signature requests. This improves the user experience for all users.
Original PR description
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our…
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it. 2. Add some sign items to the template, and send it for a signature request. 3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'. Access Error: Blame the following rules: - sign.item: group_sign_user: Create and manage template items **Cause** When the template has an associated sign request, it is copied. The problem is that the user currently doesn't have enough rights to create sign items for the copied template: https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101 **Change** Change the `user_id` of the new template to allow creating the sign items for it. opw-5254566 Forward-Port-Of: odoo/enterprise#105656 Forward-Port-Of: odoo/enterprise#102227
This update simplifies the creation of new employee records in the Swiss payroll module. The system now automatically generates a unique employee ID and sets the initial marital status to the employee's birthday if they are single, reducing manual data entry and improving accuracy.
Original PR description
For quality of life improvement, the unique employee identification is now automatically generated and initial marital status date is set to the birthday by default if the person is single Forward-Port-Of: odoo/enterprise#106752
This update resolves an incompatibility between Odoo's discount handling and Avalara's requirements. Negative discount amounts, which are used for various discount types, are now automatically distributed across valid lines before being sent to Avalara. This ensures seamless integration and accurate tax calculations.
Original PR description
Avalara doesn't allow lines with negative amounts, making it incompatible with Odoo's way to handle each different type of discount line (fixed, global, etc.). To target this, from now on at the moment of taxes computation, the negative amounts will be distributed among each valid line before sending to Avalara. The lines dispatched will be set to zero using the `manual_tax_amounts` target: master task-3452935
This update corrects missing translations within the French reporting module (l10n_fr_reports). The change ensures accurate and localized reporting for French-speaking users of Odoo Enterprise. This improves the overall user experience and compliance with French accounting regulations.
Original PR description
See: https://github.com/odoo/enterprise/commit/1591288736e998fc3d6cf50af96827de7472e6bc
This update ensures that a failure message is now correctly shown when a quality check is marked as failed within the manufacturing process. The previous issue prevented the message from appearing, impacting user visibility of quality control results. The fix corrects a technical detail in how the system handles quality check failures, ensuring accurate feedback for users.
Original PR description
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t…
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown. **Steps to produce:** * Install `Quality` and `Manufacturing` with demo data * Go to MRP > Configuration > Operations > Manual Assembly * Create a pass/fail quality point with a failure message * Create and confirm an MO for `Table Top` * Go to Shop Floor > Activate work centers if inactive > Manual Assembly * Fail the assembly using the quick-action button Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing) **Observed Behavior:** * No failure message is displayed when the quality check is failed. **Root cause:** * This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears. **Solution:** * Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions. **Before:** <img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" /> **After:** <img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" /> [1]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 [2]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 [3]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 [4]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 [5]: https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161 opw-5403465 Forward-Port-Of: odoo/enterprise#106829 Forward-Port-Of: odoo/enterprise#102095
This update resolves an issue where Modelo 390 reports were generating empty BOE files due to incorrect date handling. The fix ensures the reports accurately reflect the specified year, aligning with Spanish tax regulations and producing valid tax filing documents. This improves the accuracy of tax reporting for Spanish companies.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374 Forward-Port-Of: odoo/enterprise#106795 Forward-Port-Of: odoo/enterprise#104928
This update resolves an error in the calculation of payslips for employees on secondary contracts in Kenya. The fix replaces a missing variable with the total taxable gross, ensuring accurate payroll processing for this specific business scenario. This improves the reliability of HR and payroll data.
Original PR description
Steps to reproduce: With a Kenyan company, create an employee. Check the "Secondary Contract" on the employee form view. Create a payslip and compute. There is an error in the payslip computation. Cause: There is an undefined variable "remaining_gross". Fix: Replace it by the total taxable gross. Task: 5462310 Forward-Port-Of: odoo/enterprise#106430 Forward-Port-Of: odoo/enterprise#103229
This update hides potentially confusing live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, even though they weren't functional for non-users. This change enhances the user experience and reduces the risk of accidental actions by unauthorized users.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105995 Forward-Port-Of: odoo/enterprise#82963
This update resolves an issue where the restaurant appointment tour would fail after a page refresh. The fix ensures the tour's simulated time persists, allowing appointments to be correctly displayed and the tour to function consistently. This improves the user experience for scheduling restaurant reservations.
Original PR description
The `RestaurantAppointmentTour` fails when page refreshes reset the mock clock to system time, causing the frontend to filter out mock appointments and the tour to timeout. Refactor the tour to use the new `withTimeFreeze` helper, ensuring the simulated date persists across reloads so appointments remain visible. runbot-232601 Related Community PR: odoo/odoo#247596 Forward-Port-Of: odoo/enterprise#106724
This update fixes an issue where the XML export for VAT listings in the accounting module was incomplete, only showing the initial batch of partners. The change ensures that all partners, regardless of the 'Load More' setting, are included in the generated XML file. This improves the accuracy and completeness of VAT reporting.
Original PR description
# Steps to reproduce: * Install **Accounting** and **l10n_be_reports**. * Enable **debug mode**. * Go to **Accounting → Reporting → Belgium → Partner VAT Listing**. * Create invoices with invoice…
# Steps to reproduce: * Install **Accounting** and **l10n_be_reports**. * Enable **debug mode**. * Go to **Accounting → Reporting → Belgium → Partner VAT Listing**. * Create invoices with invoice lines with no product set on it, just a label, so that **more than 10 Belgian partners** appear in the report and ensure each partner has a **VAT number**. * Open the report **Options** tab and set **Load More Limit** to **5**. * Click **Load More** until all partners are visible. * Click **Returns** and create a return for the month you have created invoices for, and submit it. * Download the generated XML. # Observed behavior: * The XML file contains only the first batch of partners. * Partners shown after clicking **Load More** are missing from the export. # Cause: * In v17, the XML export button was defined as: https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59 * This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927) method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production. * In v19, the architecture changed: - The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py) - The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`. - The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`. * Why the test changed: - In v17 test: `export_mode = 'file'` was set to mimic the `export_file` → `partner_vat_listing_export_to_xml` flow. - In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself. # Fix: * Enable **export mode** when generating the XML. * Ensures all partners are included regardless of the load limit. opw-5494247 Forward-Port-Of: odoo/enterprise#106134
This update ensures that screenshots taken during the trial mode of Odoo Enterprise capture the correct end-result data. Previously, the system lacked the database URL needed to fetch this data. Now, the database URL is forwarded when retrieving the result, resolving this issue and improving the trial experience.
Original PR description
During the trial flow, we don't know the db url when making the ws request. To still be able to take screenshots of the end result in trial mode, we forward the db_url when getting the result back.
This update resolves a bug preventing users from installing modules correctly when using the SEPA accounting module in Belgium. The issue stemmed from a failure to automatically refresh the system's module list, delaying the actual installation process. This fix ensures modules install correctly, improving overall system stability.
Original PR description
Encountered this bug while trying to reproduce a bug from one of my ticket. **STEP TO REPRODUCE** On a fresh db with module account_accountant. 1. Create a new company with country set to Belgium. After l10n_modules are install, and the chart template loaded: 2. Try installing a module, and notice you can't. **CAUSE** button_install() doesn't reload the registry, so the sepa modules states are set to `to install` but are not install until the registry is reloaded, which doesn't happen on its own. button_immediate_install() does the same as button_install(), and reload the registry which trigger the actual installation process. Forward-Port-Of: odoo/enterprise#106033
This update resolves a problem where long item codes were causing tax calculations to fail due to AvaTax API limitations. The system now automatically shortens item codes to 50 characters before sending them to the API, ensuring accurate and successful tax processing. This prevents errors and maintains the integrity of our AvaTax integration.
Original PR description
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50…
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50 characters or fewer to comply with Avalara's field length constraints. Actual Behaviour before the Fix: When an itemCode exceeded 50 characters, the system attempted to send the request as-is. This resulted in the AvaTax API returning an error, causing the transaction or tax calculation to fail. Behaviour with the Fix: The system now ensures that the itemCode adheres to the 50-character limit before the API call is made, by trancating the code to the first 50 characters if it exceeds 50 characters. This prevents API rejection and ensures successful tax processing for items with long identifiers. Steps to reproduce: 1. Create or select a product/item with a reference (or barcode if using UPC) longer than 50 characters. 2. Trigger an action that calculates tax via the AvaTax integration (e.g., creating an invoice or updating a line item). 3. Observe the API response. - Before fix: API returns a validation error regarding the itemCode length. - After fix: Request is successful as the itemCode is properly handled/validated. opw-5406451 Forward-Port-Of: odoo/enterprise#106667 Forward-Port-Of: odoo/enterprise#105017
This pull request implements critical updates to the Odoo Enterprise system's Belgian payroll reporting (l10n_be_hr_payroll) to ensure accurate reporting for 2025 and 2026 tax declarations. Specifically, it fixes validation schemas, declaration values, and exoneration calculations related to the 281.10, 281.45, and 281 private car reporting requirements, aligning with the latest tax regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#106773 Forward-Port-Of: odoo/enterprise#106703
This update resolves an issue where accents in legal names were being incorrectly removed, preventing proper recognition by Mexican tax authorities (SAT). The fix restores the correct handling of accented characters, ensuring accurate data submission for Mexican e-invoices. This ensures compliance with Mexican tax regulations.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update adjusts the taxonomy used for Dutch tax reports from NT19 to NT20, a standard change required for compliance. The update only involves namespace adjustments and maintains compatibility with older versions of the XBRL template. This ensures continued accurate reporting for Dutch tax filings.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update simplifies the sales order interface for subscription customers. The 'remaining hours' field, which could be misleading due to subscription renewal cycles, has been hidden when a line is linked to a subscription. This ensures a cleaner, more intuitive experience for our customers and avoids potential confusion.
Original PR description
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference…
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic. In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle. To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription. opw-5246238 Forward-Port-Of: odoo/enterprise#106807 Forward-Port-Of: odoo/enterprise#99813
This update resolves an issue where invoice exports were failing when invoices contained a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of the invoicing process.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update resolves a technical error that was preventing correct display names from being set for spreadsheet cell threads. The fix ensures that only one display name is used, preventing a crash and improving stability of the spreadsheet edition. This change ensures data is displayed correctly.
Original PR description
**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947 Forward-Port-Of: odoo/enterprise#106785 Forward-Port-Of: odoo/enterprise#106230
This update clarifies the terminology used in the recruitment stage labeling within the Odoo Enterprise system. The 'Initial Qualification' label has been renamed to 'Qualification' for better consistency and understanding. This change improves the user experience for recruiters and hiring managers.
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 simplifies the salary simulation process by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change only improves clarity and prevents confusion for users.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#104493
This update resolves a potential instability issue in the document search functionality. The team corrected a programming error that could have resulted in a missing context, leading to errors. Now, the document search model reliably accesses the necessary context information.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
This update resolves a technical issue that prevented the accurate calculation of document counts during system upgrades. The problem occurred when the system expected a single partner record, but multiple records were found, leading to an error. This fix ensures accurate document counts are calculated.
Original PR description
When trying to compute the document count during the upgrade, we encountered a ValueError because multiple records were found for a partner. The system expected a singleton ``` File…
When trying to compute the document count
during the upgrade, we encountered a ValueError
because multiple records were found for a partner. The system expected a singleton
```
File "/home/odoo/src/enterprise/19.0/documents_hr/models/hr_employee.py", line 34, in _compute_document_count
('partner_id', '=', self.work_contact_id.id)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_misc.py", line 112, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(11393, 11612, 13026, 13085, 13066, 11674, 13007, 11240, 11420, 13086, 2687, 8998, 10309, 8195, 8468, 6439, 8151, 6580, 7928, 10301, 11058, 10515, 5274, 9243, 8141, 8435, 8889, 7761, 7733, 8443, 8545, 9252, 8457, 9980, 5495, 11424, 6458, 10558, 11070, 8924, 11731, 11528, 11615, 11766, 13021, 13080, 11758, 11742, 9306, 8826, 11004, 9393, 8879, 9317, 11652, 13075, 11744, 11160, 11644, 11763, 11416, 11618, 11732, 7931, 3846, 8442, 10299, 7916, 8429, 8057, 11061, 9342, 6435, 6553, 6512)
```
Forward-Port-Of: odoo/enterprise#101902This fix addresses an error where yearly employer cost calculations were inaccurate due to a forgotten representation fee benefit. The PR reverts a previous change and re-integrates the necessary calculation, ensuring correct cost projections. This improves the reliability of financial reporting within the HR module.
Original PR description
This PR converted fields/benefits into properties: https://github.com/odoo/enterprise/pull/96385 Then, this PR reverted the changes: https://github.com/odoo/enterprise/pull/101672 But the representation fees benefits was forgotten. This was causing the yearly employer cost to be computed without the representation fees. Forward-Port-Of: odoo/enterprise#105517
6 changes
Resolved issues and error corrections
This update simplifies the salary simulation process by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, but previously their presence caused confusion. This change improves the user experience by removing unnecessary information.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873
This update resolves an issue where the system incorrectly calculated employee expenses when both a private and company car were used during the same pay period. The fix ensures accurate expense tracking by properly accounting for both vehicle types, improving payroll accuracy and compliance.
Original PR description
…occupation
This update fixes a user interface issue where the 'Some required fields are not filled' warning appeared twice when the salary configurator form was submitted with empty required fields. The fix removes redundant validation and clears existing warnings to ensure a cleaner user experience. This improves usability and prevents confusion.
Original PR description
On submitting the salary configurator form, keeping the required fields empty, the warning “Some required fields are not filled” is displayed twice. [Steps to reproduce](https://drive.google.com/file/d/1bKeXhtXN5nY5pdVYhPiau7pDwGnrzgg4/view?usp=sharing) ## Root cause The same warning message was added for radio field validation, causing duplicate alerts to appear. ## Fix Removed the radio validation and centralized with other fields validations. ## Additionally Remove existing alerts to prevent stacking of warnings on multiple clicks on button. task-[5113853](https://www.odoo.com/odoo/project/1251/tasks/5113853)
This update resolves an issue where accents in legal names were being incorrectly removed, preventing proper recognition by Mexican tax authorities (SAT). The fix restores the correct handling of accented characters, ensuring accurate data submission for Mexican e-invoices. This ensures compliance with Mexican tax regulations.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update ensures that the IoT printer 'Test' buttons now correctly align with the system's 'use_lna' configuration setting. Previously, this button's behavior was inconsistent. This change improves the reliability and predictability of the printer test functionality.
Original PR description
Ensure the IoT printer Test buttons use LNA when triggered, aligning behavior with `point_of_sale.use_lna` configuration. Task-5886700 Related: https://github.com/odoo/odoo/pull/246446
This update corrects a previous issue where the payslip report displayed the company's working schedule instead of the employee's. The report has been updated to accurately reflect the employee's individual working schedule, ensuring payroll reports are more accurate and relevant.
Original PR description
-The display for working schedule info in the payslip report was referring to the company's working schedule. -The report has been adjusted to include the employee's working schedule. -Task #5900303
6 changes
Enhancements to existing features
This update ensures UrbanPiper receives the correct product tags by dynamically syncing them from product settings. Previously, tags were hardcoded, leading to issues with tax calculations. Now, users can define tags based on their needs, streamlining the integration with UrbanPiper and improving data accuracy.
Original PR description
Before this commit: ------------------------------------------ - The UrbanPiper payload used a hardcoded tag when the tax percentage was not 5%. - There was no mechanism to add additional tags based on providers, even though UrbanPiper supports multiple tags. After this commit: ------------------------------------------ - Tags are now dynamically handled using the Tag field in the product. - Users can define tags according to their tax configurations and aggregator requirements. - UrbanPiper only accepts relevant tags (default or provider-specific). task - 5154061
Resolved issues and error corrections
This update resolves a crash that occurred when using the budget filter within accounting reports. The fix ensures the system handles report configurations without all required budget columns gracefully, preventing errors and improving report stability. This enhancement ensures users can consistently utilize the budget filter functionality.
Original PR description
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation…
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation Engine = External Value** and **Formula = 0** on report line. * Add a report column with **Figure Type = Monetary**. * Create a menu item for the report. * Open the report and click **Budget**. * Create a new budget filter and click **Create**. **Observed behavior:** * The system crashes with `TypeError: 'NoneType' object is not subscriptable`. * The error occurs while accessing budget column values. **Cause:** * Budget comparison logic assumes required budget columns always exist. * When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway. **Fix:** * Add a safety check to skip budget comparison when required columns are missing. * Prevents the crash and allows budget filters to be created safely. opw-5357339
A test was failing due to a default pricelist being applied, which incorrectly inflated the total sale order amount. This update forces an empty pricelist during testing, ensuring accurate tax calculations and consistent test results. This resolves a discrepancy between expected and actual order totals.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692This update adjusts the taxonomy used for Dutch tax reports to the latest NT20 standard. This change ensures continued compliance with Dutch tax regulations and maintains compatibility with older versions of the reporting templates.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of our invoicing processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update resolves an error that occurred when saving settings in branch companies of Guatemalan businesses. The system incorrectly flagged the 'Service Provider' field as required, even when it was hidden. The fix ensures this field is only required for the main company, streamlining the process for branch office management.
Original PR description
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no…
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made. ### **Steps to reproduce:** 1) Install `l10n_gt_edi` and switch to a GT company. 2) Create a branch of the GT company. 3) In the parent company, go to Accounting Settings, set the Guatemala Localization to 'Demo', and save. 4) Switch to the branch company. 5) Open Accounting Settings and click Save. ### **Observed Behavior:** An error occurs because `l10n_gt_edi_service_provider` is empty but required. ### **Root Cause:** The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails. [1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22 ### **FIX:** Update the `required` domain to include `l10n_gt_edi_is_root_company`. This ensures the field is only mandatory in the root company where it is actually visible and configurable and also set the `l10n_gt_edi_service_provider` for branch company same as parent company. **opw-5385819**
6 changes
Resolved issues and error corrections
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The change ensures that the employee's work email field is properly cleared during the contract signing process, preventing this duplication. This improves data accuracy and consistency for employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797
This update fixes an issue where draft journal entries in the payroll accounting module were incorrectly using the end of the month instead of the payslip pay period date. This ensures accurate accounting records and proper financial reporting for employee payroll.
Original PR description
Steps to Reproduce: - install payroll accounting module - create or update existing employee contract - change schedule pay to semi-monthly - create a payslip and validate it. - create draft entry and open the journal entry Issue: - The accounting date of the draft entry is the last date of the month. - It should be the end date of payslip pay period. Reason: - While creating draft entry it takes the last date of the month instead of the end date of the payslip Solution: - assign end date of payslip pay period instead of last date of the month task-5419465
This update addresses an issue where rounding units were unexpectedly appearing in financial reports and views. By adding a new name to the rounding units, the changes prevent their display, resulting in cleaner and more accurate reporting. This enhances the overall clarity and professionalism of our financial data presentation.
Original PR description
adhoc-ticket-side: 82382
This update fixes a display issue in the order web preview where tax names weren't correctly shown. Previously, the preview showed the tax description instead. The fix ensures that the configured tax name is displayed, providing accurate tax information in the portal preview for sales orders.
Original PR description
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `industry_fsm_sale` module. - Go to Invoicing > Configuration >…
Currently, the `Tax name` configured on taxes is not applied in the web preview of orders. **Steps to reproduce:** - Install the `industry_fsm_sale` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Create a new tax, `Tax Type: Sale`and set `Description`. - Open Field Service, create a new task, and set a Customer and Sales Order Item (using a sale order with the newly created tax). - Click the gear icon > Share > Copy to copy the portal link. - Open the link in a new window and observe the Taxes value. **Observation:** - Web portal preview incorrectly displays `description` instead of `tax name`. **Root Cause:** At [1], the project portal web preview template uses `description or name`, which causes an incorrect tax description to be displayed in the preview. **Fix:** This commit ensures that `Tax Name` is used when rendering taxes in the portal preview. Related community PR: https://github.com/odoo/odoo/pull/241850 [1]: https://github.com/odoo/enterprise/blob/6d5e02b61f90ec490fdad72d87ea73d1c6adcfac/industry_fsm_sale/views/project_portal_templates.xml#L77-L79 opw-5411496
This update resolves a reporting issue where the tax amount for EU imports was incorrectly duplicated in the Spanish VAT reports (mod 390). The fix corrects a misconfiguration in the tax template, ensuring accurate reporting of import duties for Spanish companies using the l10n_es module.
Original PR description
How to reproduce: - Install the l10n_es module - Swithc to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for O% EU G, there is two tags for the mod 390, the one for grid 26 being wrong opw-5867849
This update incorporates new statistical trade codes (2026) required for accurate reporting based on European Union regulations. These codes, sourced from the National Bank of Belgium, ensure Odoo Enterprise complies with international trade statistics reporting standards. This change improves the accuracy of financial data for businesses involved in cross-border transactions.
Original PR description
This commit adds 2026 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes opw-5504187