Friday, February 20, 2026
27 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where tasks remained linked to sales orders even after the associated sales order item was removed. Now, tasks can be properly detached from sales orders when no items are linked, allowing users to accurately bill tasks and manage them independently. This improves task management and billing accuracy.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty the Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487 opw-5215989 Forward-Port-Of: odoo/odoo#249107 Forward-Port-Of: odoo/odoo#241446
This update resolves an issue where tasks remained linked to sales orders even without associated sales order items, preventing proper billing. The change ensures tasks can be correctly detached from sales orders when no items are linked, streamlining the billing process for field service tasks. This improves user efficiency and accuracy.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107716 Forward-Port-Of: odoo/enterprise#103487
A recent update caused a crash when users tried to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function now correctly handles list duplication, preventing unexpected errors and improving the overall stability of the spreadsheet experience. This resolves a frustrating user experience issue.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This update resolves a technical issue that could cause errors when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and prevents unexpected tracebacks. This improves stability and usability for users managing barcode configurations.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update resolves an incorrect reliance on Peppol BIS3 constraints within the RO and HR EDI modules. Previously, an unnecessary dependency caused issues with sending invoices, particularly to physical persons. This fix ensures proper functionality and compliance with standard EDI formats.
Original PR description
The CIUS RO and CIUS HR depends on the BIS3 which is fundamentally incorrect. This was probably made out of lazyness to redefine things that are almost the same in both these CIUS and the BIS3. Now, in previous PR [1], we added contraints for the Peppol BIS 3 that are impacting those formats. Indeed, the EndpointID can be empty in the context of CIUS RO and CIUS HR. In particular, it's breaking the sending to physical person at the moment. [1]: https://github.com/odoo/odoo/pull/246961 opw-5943698 Forward-Port-Of: odoo/odoo#249089
This update resolves a bug that caused forum posts to fail to create when Odoo was running in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable experience for users.
Original PR description
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249477 Forward-Port-Of: odoo/odoo#244063
A recent update to the Point of Sale system introduced a double confirmation issue when using CTRL+Enter in a popup dialog. This resulted in duplicate entries being created, such as multiple floors. This fix prevents this duplication, ensuring data integrity and accurate record-keeping.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134
This update resolves an issue where the 'Update Prices' button disappeared after saving a quotation. The fix adds a field to the view that ensures the button remains visible, allowing users to easily adjust prices within the quotation record. This improves the user experience and streamlines the quotation process.
Original PR description
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new…
Steps to produce: --- - Install sales module. - Go to Settings and enable Pricelists (make sure we have 2 pricelists so that we able to change the pricelist value in quotation). - Create a new quotation > Add a customer and product. - Change the pricelist. - Save the record. Issue: --- - After saving the quotation, the `Update Prices` button becomes invisible. Root cause: --- - The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0 **Enterprice PR:** https://github.com/odoo/enterprise/pull/107621 opw-5927659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Update Rental Prices' button disappeared after saving a rental order in the Odoo Enterprise system. The fix adds a field to the view that ensures the button remains visible when a rental period is changed and the order is saved. This improves usability for users managing rental agreements.
Original PR description
Steps to produce: --- - Install `sale_renting` module. - Rental > Open any order > Change the rental period. - Save the record. Issue: --- - After saving the order, the `Update Rental Prices` button becomes invisible. Root cause: --- - The field `show_update_duration`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_duration` field to the view to ensure its value is properly maintained. This allows the `Update Rental Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/enterprise/commit/b90bbdef10a7a37fb065626ba995811ab388c7a1 opw-5937145 ---
This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, overriding the system's exchange rates. The change ensures that expense amounts are accurately converted to the company's base currency, improving the reliability of financial reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the journal entries, which blocked the search function. Now, all journal entries are searchable by move, partner, account, and label.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update resolves an issue related to how Odoo handles customizations for UBL (Universal Business Language) invoices. Specifically, it corrects a problem with retrieving customization IDs, ensuring that UBL invoice processing across various international accounting modules (like ANZ, Japan, My, and SG) functions correctly. This ensures accurate invoice generation and compliance with local regulations.
Original PR description
no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249192 Forward-Port-Of: odoo/odoo#248992
This update ensures that invoices generated for Spain (using the facturae module) comply with Spanish tax regulations. Previously, the XML format included excessive decimal places, causing validation errors. This change limits the decimal places to two for EUR invoices, resolving the validation issue and ensuring accurate submission to the Spanish tax authority.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#248882
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. Now, the system correctly uses the employee's actual 40-hour week, ensuring accurate holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#107858 Forward-Port-Of: odoo/enterprise#106205
This update fixes an issue where clicking the 'More options' button in the HTML editor would cause the editor to lose focus. The fix ensures the editor remains focused after the button is clicked, improving the user experience. Additionally, the powerbox filtering now correctly displays commands based on user input.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#244454
This update resolves an issue where the 'Expenses Report' feature couldn't process receipts with encrypted PDFs. The fix skips these files and logs a note in the report, preventing errors and ensuring all receipts can be included. This improves the reliability of expense reporting.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: 1) With a version of PyPDF2 lower than 2.12.1 (e.g. 1.26.0), a PdfReadError is raised: "File has not been decrypted". 2) With version 2.12.1 of PyPDF2, if PyCryptodome library is not installed, a DependencyError is raised: "PyCryptodome is required for AES algorithm". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249365 Forward-Port-Of: odoo/odoo#248869
This update corrects a default VAT setting in the Odoo Estonia module to reflect the recent change in Estonian VAT law (24% instead of 22%). This ensures accurate sales and purchase tax calculations for users operating in Estonia. The change was backported from a previous Odoo commit.
Original PR description
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22%…
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22% rate for sales and purchases. Steps to Reproduce: 1. Install l10n_ee on a fresh database. 2. Go to Accounting > Configuration > Settings. 3. Observe that the default Sales and Purchase taxes are set to 22%. 4. Create a new product; observe it automatically assigns the 22% tax. Solution: - Updated account.tax-ee.csv to set active=False for 22% tax templates and ensure 24% templates are active. - Modified template_ee.py to update account_sale_tax_id and account_purchase_tax_id to point to the new 24% tax IDs. - Updated EU_TAX_MAP in l10n_eu_oss to reflect the 24% destination rate for Estonia across all EU member states. backport of: https://github.com/odoo/odoo/commit/55e3853313969918005757203fc63ee1bd0a3b43 opw-5407921 Forward-Port-Of: odoo/odoo#249385 Forward-Port-Of: odoo/odoo#248156
This update corrects an issue where pick-up point names and days of the week were incorrectly capitalized in the website's 'Click and Collect' feature, particularly in Dutch. The fix ensures consistent and proper formatting of pick-up point information regardless of the selected language, improving the user experience.
Original PR description
Issue: --- In pick-up point list, the case formatting should be: 1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized. 2- Weekdays should must be always capitalized regardless of language. Steps to reproduce: --- 1- Create a second Company named `store`. 2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points) 3- In the website, add Dutch lang. 4- In website, open a product and, open the `Click and Collect`. Outcome: --- Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang. Cause: --- Due to CLDR, luxon doesn't capitalize weekdays in some languages. opw-5941830 Forward-Port-Of: odoo/odoo#249078
This update corrects a discrepancy in how the private car daily allowance is calculated and displayed on payslips. Previously, the displayed amount didn't always match the calculated quantity multiplied by the amount. This change ensures that payslip figures accurately reflect the daily allowance, improving payroll reporting and financial accuracy.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
This update fixes a bug where inactive accounts were excluded from key financial reports (P&L, Balance Sheet, Accounts Coverage). The change addresses a shift in how Odoo identifies accounts and ensures all accounts, including inactive ones, are accurately reflected in these reports. This improves the reliability of financial reporting.
Original PR description
Purpose: In P&L, Balance Sheet and Accounts Coverage Report, inactive accounts are not considered. Root cause: `deprecated` field on `account.account` is replaced with `active`, and orm search by default returns only active records. Solution: add `active_test=False` in the context. task- 5906024
This update resolves an error that prevented users from setting accounting periods when creating tax returns in Invoicing. The issue stemmed from incorrect module initialization, now corrected to ensure proper onboarding progress tracking. This ensures smooth tax return setup for users.
Original PR description
Currently, an error occurs when a user tries to set the accounting period. **Step to Reproduce:** 1. Install Invoicing without demo data and log-in as a super user. (from v19.0, no need to log-in as super user) 2. Invoicing > Accounting > Tax Returns. 3. Set an Opening Date in the wizard and try to apply the accounting period. **Error:** `ValueError - Expected singleton: onboarding.progress()` **Cause:** PR 1, added `_initiate_account_onboardings()` in the accountant (**accounting**) module. However, the onboarding progress should be initialized in the account (**invoicing**) module. **Fix:** This commit ensures that `_initiate_account_onboardings()` is called from the `account` module instead of the `accountant` module. [1] - odoo/enterprise#101442 Enterprise PR: https://github.com/odoo/enterprise/pull/107476 sentry-7064593163
This update resolves an issue where setting accounting periods for tax returns sometimes failed when the Invoicing module was also installed. The change ensures that a key setup process is consistently executed, improving the reliability of tax return configuration. This aligns with recent community updates.
Original PR description
To align with the changes introduced in **community PR** [1], this commit moves the `_initiate_account_onboardings()` method in the `account` module to ensure it is executed even when Invoicing is installed. [1] - https://github.com/odoo/odoo/pull/248790 sentry-7064593163
This update fixes a visual issue where date picker arrows appeared reversed when the website was displayed in RTL (Right-to-Left) languages like Arabic. The fix ensures that date pickers function correctly regardless of the user's language setting, improving usability for international users. This was achieved by applying the necessary styling to the main container component.
Original PR description
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ###…
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ### Issue: When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example): https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76 Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them. ### Solution: The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically. opw-5498615 Forward-Port-Of: odoo/odoo#248554 Forward-Port-Of: odoo/odoo#246190
This update ensures the 'Request Signature' menu item consistently appears on form views when a chatter is present. Previously, the system wasn't reliably checking for chatter, leading to the menu item sometimes being missing. This change improves the user experience by guaranteeing the signature option is available where it should be.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#97401
This update fixes a technical issue related to invoice generation when using BIS3 files for B2C transactions. Previously, checks for R010/R020 were always performed, even when not needed. This change ensures these checks only occur when PEPPOL data is present, streamlining the process for B2C customers who manually import their invoices.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249751
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data transmission. This change is critical for compliance with Dutch tax regulations.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries, regardless of whether the hours spent are positive or negative, are limited to a maximum of six digits. Previously, users could enter excessively large negative values without any error message. This fix prevents data inconsistencies and ensures accurate timesheet reporting.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781