Monday, March 2, 2026
50 changes · saas-19.2
Resolved issues and error corrections
This update ensures that check printing in the Philippines accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly deduct withholding, leading to potential discrepancies. A new test case has been added to verify this fix.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108859 Forward-Port-Of: odoo/enterprise#108611
This update resolves an issue that prevented users from starting the Colombian Electronic Invoicing certification process when no certificate was initially configured. The fix ensures the system handles the absence of a certificate gracefully, preventing a technical error and allowing users to complete this important compliance step.
Original PR description
When no certificate is found in the company, clicking on ``Begin Certification Process`` raises a traceback. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data - Switch to the CO Company - Go to Invoicing > Configuration > Settings > Colombian Electronic Invoicing - Set the Testing ID for Operation mode - In Certificates, delete the existing certificate - Click on Activate the certification process > Begin Certification Process > Ok Traceback: ```py UnboundLocalError cannot access local variable 'cert_sudo' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/6294be57cf1aa577ec546a958514bc8ec6705935/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1459 The variable ``cert_sudo`` is used outside of the for loop. If no certificate is found, ``cert_sudo`` will be undefined, leading to the UnboundLocalError. sentry-7256943298 Forward-Port-Of: odoo/enterprise#107094
This update fixes an issue where POS receipts incorrectly showed the standard 21% tax label, even when a fiscal position had been set to 6%. The change ensures that the tax group label on POS receipts accurately reflects the fiscal position configured for each order, improving accuracy and compliance.
Original PR description
Steps: - Install l10n_be_pos_restaurant. - Create a restaurant POS configuration with presets. - Assign a fiscal position to one preset that replaces 21% tax with 6%. - Open a POS session and process an order using that preset. Issue: - The POS receipt still displays the 21% tax's tax group label, even though the 6% tax is correctly applied. Cause: - Fiscal position was not taken into account when computing the tax group label for POS receipt orderlines. Fix: - Apply the fiscal position when determining the POS receipt tax group label. Task-5899938 Forward-Port-Of: odoo/odoo#251136 Forward-Port-Of: odoo/odoo#248571
This update resolves an issue where tasks remained linked to sales orders even without associated order items, preventing proper billing. The change ensures tasks can be cleanly detached from sales orders when no items are linked, streamlining the billing process for non-billable tasks while maintaining functionality for adding materials to existing orders.
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#107990 Forward-Port-Of: odoo/enterprise#103487
A recent update to the Point of Sale system meant a warning was no longer displayed when attempting to cancel paid orders. This change occurred because the system now only updates draft orders. This fix restores the warning, ensuring users are alerted before cancelling paid orders to prevent errors.
Original PR description
From 18.2, the warning to prevent users to cancel paid or posted orders from backend was no longer displayed. It's caused because it was handled in the write() method from pos.order model. But, since a recent change, we call write() method only on draft orders. So, if there is no draft orders selected, the warning doesn't appear. task: 5959917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250969 Forward-Port-Of: odoo/odoo#250074
This update fixes an issue where project billing amounts weren't accurately reflecting transactions in the Odoo system. The change ensures that the system correctly identifies and matches analytic accounts across purchase orders and vendor bills, leading to accurate project profitability reporting. This improves the reliability of financial data.
Original PR description
### Steps to reproduce: - Create a billable Project - Navigate to Accounting > Configuration > Analytic Accounting > Analytic Plans - Change the order of the project plan - Create a Purchase order and set the created project and a department in analytic distribution - Create a Vendor Bill with the same analytic distribution and match with the PO - Confirm the Vendor Bill - Check the project dashboard - Notice the amount is under To Bill not Billed ### Cause: In this commit https://github.com/odoo/odoo/pull/241571/changes/ef080f94609f1057c6d86af68bee605dcaeb287b we introduced a fix to search for the analytic account in purchase lines' analytic distribution when we have multiple accounts for the same purchase line if it is shown as the first number of the key but since it is not mandatory to have the project account id at the start of the key ### Fix: We now search for the id in the whole not only the start of it. opw-5350246 Forward-Port-Of: odoo/odoo#245793
This update fixes an error in the Profit & Loss reports for Spanish fiscal localization packages. Accounts 7950 and 7957 were previously incorrectly placed in section 10, which is now corrected to section 6 according to official Spanish tax regulations. This ensures accurate reporting for Spanish businesses.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108820 Forward-Port-Of: odoo/enterprise#107949
This update fixes a minor typo in the Helpdesk module's result pages. The change ensures consistent and accurate display of dates, addressing a potential issue that arose after a recent update to the core Odoo system. This ensures a polished user experience for Helpdesk users.
Original PR description
Before this commit and since the merge of https://github.com/odoo/odoo/pull/156878, `date_published` has been replaced by epublished_date` field but the changes have not been made in website_helpdesk_slides module. This commit replaces `date_published` occurrences by `published_date`. task-[5945377](https://www.odoo.com/odoo/project/4105/tasks/5945377) Forward-Port-Of: odoo/enterprise#108253
This update fixes a bug in the pipeline dashboard that prevented accurate matching of the first list displayed. Previously, the dashboard didn't correctly identify and link related opportunities. This change ensures the dashboard displays accurate and complete pipeline data, improving sales visibility.
Original PR description
…oard Field matching was missing for the list #1 in the pipeline dashboard. Task: 5092979 Forward-Port-Of: odoo/enterprise#107516
This update resolves issues with the Belgian XBRL report, specifically correcting inaccurate translations and removing irrelevant company types. The changes also add crucial data points like Balance Sheet, P&L, and Explanatory Disclosures, ensuring the report meets regulatory requirements and provides more complete financial information.
Original PR description
This commit fixes several issues in the Belgian XBRL report. - Values in report like "false" were being wrongly translated. - Not all company types are valid/relevant. Removed invalid company types. task-5907118 Forward-Port-Of: odoo/enterprise#108556
This update adjusts the Italian tax system (l10n_it_edi) to align with a new law. As of January 1, 2025, forfettari (RF19) can now utilize simplified invoices regardless of the total invoice amount, removing a previous limit. This simplifies invoicing for this specific business segment.
Original PR description
Since 01/01/2025, Italian law allows forfettari (RF19) to use simplified invoices even if the total amount exceeds 400€. References: - https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2014-12-23;190;1;59#:~:text=L'emissione%20della%20fattura%2C%20ove%20prevista%2C%20può%20avvenire%20in%20modalità%20semplificata%20ai%20sensi%20dell'articolo%2021%2Dbis%20del%20decreto%20del%20Presidente%20della%20Repubblica%2026%20ottobre%201972%2C%20n.%20633%2C%20anche%20se%20di%20ammontare%20complessivo%20superiore%20al%20limite%20indicato%20nel%20comma%201%20del%20medesimo%20articolo%2021%2Dbis. - https://www.dkpost.it/fattura-semplificata-senza-limiti-per-i-forfettari/ - https://www.gazzettaufficiale.it/eli/id/2024/11/30/24G00196/sg Forward-Port-Of: odoo/odoo#250743 Forward-Port-Of: odoo/odoo#247264
This update resolves an issue where adding a column within a list item caused a system error. The fix separates column insertion within lists, preventing errors related to restoring selections on removed elements. This ensures the HTML editor consistently functions correctly when working with lists.
Original PR description
Problem: When trying to add a column under a list item, a traceback occurs. Cause: The list item is removed during the operation, but the selection that is restored still references the removed list item. As a result, the selection is restored on a disconnected element, causing a traceback. Solution: Handle column insertion inside lists separately. In this case, according to the specifications, we split the list and insert the columns between the resulting lists (or after the list if the cursor is in the last list item). This avoids restoring the selection on a removed node. Steps to reproduce: - Add any list. - Run `/column` while the cursor is inside a list item. - Observe the traceback. task-5916246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250847 Forward-Port-Of: odoo/odoo#248206
This update improves how product combo pricing is shown to users. Previously, combo products were labeled as 'free,' which caused confusion. Now, the backend displays 'item' and the POS frontend shows 'included' to accurately reflect that these products are part of the combo's price.
Original PR description
Description of the issue/feature this PR addresses: combo choice products are not free products. They are included in the combo product price. Therefore it creates misunderstanding for our users Current behavior before PR: Desired behavior after PR is merged: Change the "free" string into "item" in the backend and into "included" in pos frontend to align with the display in self --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248535 Forward-Port-Of: odoo/odoo#245279
This update resolves an issue where event email templates incorrectly used the sender's company instead of the event's company, causing incorrect styling and potential access errors in multi-company environments. The fix ensures event templates now correctly reference the event's company, guaranteeing accurate styling and proper access permissions.
Original PR description
Steps to reproduce: 1. Create a multi-company environment with at least two companies. 2. Create a new user with Company 1 as default and access to Company 2. (+ Admin rights for events.) 3. Connect…
Steps to reproduce: 1. Create a multi-company environment with at least two companies. 2. Create a new user with Company 1 as default and access to Company 2. (+ Admin rights for events.) 3. Connect to the user and switch to Company 2. 4. Go to Events > Any event on this company with at least 1 attendee. 5. Go to the attendee form and in the chatte go to send message and expand. 6. Finally, try to select an email template from the 3 dots. This issue was introduced by commit aff20f8, which added logic to style email buttons using company-specific colors. The bug occurs because the template incorrectly retrieves the company of the current user sending the email instead of the company linked to the event registration (object.company_id). This leads to two problems in a multi-company environment: 1. The button colors will always be based on the user's default company, leading to incorrect styling. 2. It can provoke an access rights error when trying to read the email colors of a company that is not the one we've currently selected. To fix this, we should ensure that the email templates for events use the company associated with the event registration (object.company_id) when styling the email buttons. This way, the correct company context is used, ensuring proper access rights and more accurate button styling. opw-5256010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236764
This update ensures overtime calculations are accurate when creating or modifying time off requests, especially when existing attendance records are present. The system now automatically recomputes overtime whenever a time off record is created, updated, or deleted, preventing incorrect overtime charges.
Original PR description
If you don't have time off app, the option Timing - when Employee is off, should not be available. Creating a time off on a day when there is already an attendance record should automatically recompute the overtime if this rule is on the employee. Forward-Port-Of: odoo/odoo#251064 Forward-Port-Of: odoo/odoo#240940
This update fixes an issue where SII invoices weren't correctly formatted, preventing successful transmission of invoices. The change updates XML tags related to withholdings in the DTE template to align with SII's specifications, ensuring invoices are accepted by the SII system. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This pull request updates the core spreadsheet component within Odoo. It includes several performance improvements and bug fixes related to spreadsheet functionality, ensuring a smoother and more reliable user experience when working with spreadsheets. These changes focus on enhancing the core spreadsheet engine.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/146d7e00b5 [REL] 19.2.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits:
https://github.com/odoo/o-spreadsheet/commit/146d7e00b5 [REL] 19.2.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/cdbf5b4f5e [REV] borders: revert infinite borders [Task: 5932734](https://www.odoo.com/odoo/2328/tasks/5932734)
https://github.com/odoo/o-spreadsheet/commit/8e2daf8b4c [PERF] import: {... } instead of Object.assign [Task: 5957630](https://www.odoo.com/odoo/2328/tasks/5957630)
https://github.com/odoo/o-spreadsheet/commit/e197523f55 [FIX] logging: log "ms" [Task: 5959504](https://www.odoo.com/odoo/2328/tasks/5959504)
https://github.com/odoo/o-spreadsheet/commit/9dfcc3f9c9 [FIX] dynamic_tables: trim overlap on the correct side [Task: 5905900](https://www.odoo.com/odoo/2328/tasks/5905900)
https://github.com/odoo/o-spreadsheet/commit/253ad0d65d [PERF] cell: faster symbol check [Task: 5956800](https://www.odoo.com/odoo/2328/tasks/5956800)
https://github.com/odoo/o-spreadsheet/commit/1621a662f1 [FIX] side_panel: restore scroll position on pivot tab change [Task: 5900595](https://www.odoo.com/odoo/2328/tasks/5900595)
https://github.com/odoo/o-spreadsheet/commit/b76a2027a0 [FIX] side_panel: restore vertical scrolling for chart side panel tabs [Task: 5900595](https://www.odoo.com/odoo/2328/tasks/5900595)
https://github.com/odoo/o-spreadsheet/commit/5adcabfaa2 [PERF] formulas: Force the use of the cache for linear search functions [Task: 5956354](https://www.odoo.com/odoo/2328/tasks/5956354)
https://github.com/odoo/o-spreadsheet/commit/40b93f5230 [FIX] Evaluation: Provide cell position for isolated formula evaluation [Task: 5798610](https://www.odoo.com/odoo/2328/tasks/5798610)
https://github.com/odoo/o-spreadsheet/commit/ccde4cdc92 [PERF] recompute_zone: binary search with bit shift [Task: 5955352](https://www.odoo.com/odoo/2328/tasks/5955352)
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>This pull request reverses a recent change to the spreadsheet edition's border styling. The change caused visual inconsistencies and performance issues within the spreadsheet functionality. This reversion restores the original styling and addresses the identified problems.
This update resolves a bug that caused inventory valuation reports to fail when dealing with subcontracting manufacturing orders that had multiple destination receipts. The fix limits the records considered during valuation to the last 'done' receipt, ensuring accurate inventory calculations. This improves the reliability of inventory reporting.
Original PR description
With older subcontracting MOs, a singleton error will be thrown when the MO has more than one `move_dest_ids` and we try to do an inventory valuation Steps to reproduce: 1. A product with…
With older subcontracting MOs, a singleton error will be thrown when the MO has more than one `move_dest_ids` and we try to do an inventory valuation
Steps to reproduce:
1. A product with `qty_available`, that is not `lot_valuated`
2. The product has a stock move with a `production_id` where `is_in` is true
3. The stock move has more than 1 `move_dest_ids` where `done` and `is_subcontract` is true
4. Open an inventory valuation report from any date in the past. One can access inventory valuation reports from Accounting app > Review menu
> Inventory > Inventory Valuation. You will get a singleton error
Issue:
Followup to previous fix: dae71a2ba5a51ad5a07c4294ecdd6192d8752b07
Because older subcontracting MOs may have multiple destination receipts, a singleton error will occur if there are more than one of these `last_subcontract_done_receipt` records. This is due to the recordset calling `_get_value_from_account_move` on itself, which expects only 1 record and results in a singleton access error when it reaches: https://github.com/odoo/odoo/blob/e7ebe07e1d60659f3d468255808a305e7423741b/addons/purchase_stock/models/stock_move.py#L184
Solution:
Limit `last_subcontract_done_receipt` to 1 record. Because we have no way of knowing which receipt move is the absolute last done receipt, we assume it is the last one created that is also 'done'.
This solution was taken from @kihy-odoo on the PR https://github.com/odoo/odoo/pull/245662
opw-5489433
opw-5416006
Forward-Port-Of: odoo/odoo#250920This update fixes a calculation error in the Swiss VAT tax report, specifically for journal entries using tax grid 221. The formula was incorrectly calculating the ‘Supplies provided abroad’ line, resulting in a negative value. The change adjusts the formula from 221 to -221, ensuring accurate VAT reporting and compliance.
Original PR description
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies…
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies provided abroad`. 4. The value appears negative instead of positive. - This issue occurred due to the major tax revamp introduced in version 19 [commit](https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c) - To resolve this issue, the formula has been modified from `221` to `-221`. **Before fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/cea87440-9e7b-4d5e-80d9-6a3d745e5d71" /> **After fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/f69e3a62-ec6a-4a24-a0cc-b44fab16eefa" /> OPW: 5945876 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#250568
This update fixes an issue where timesheets weren't automatically marked as billable when linked to a specific task or project. The fix ensures that when a timesheet is associated with a task, the ‘is_billable’ field is correctly set to ‘True’, streamlining billing processes and improving accuracy.
Original PR description
Steps to reproduce: - Open Timesheet Assistant - Add new Timesheet - Choose a project or task so so_line of timesheet become True - is_billable is still False Source of the bug: - compute_is_billable was missing depends decorator task-5956059 Forward-Port-Of: odoo/enterprise#108295
This update fixes a technical error that prevented users from successfully using commands within the AI chat channels. The issue stemmed from an undefined 'message' variable during command execution, which has now been resolved. This ensures a smoother experience for users interacting with the AI.
Original PR description
When trying to use commands (for example '/help') in 'ai_chat' channels, an error occurrs. This happens because the 'message' returned from Thread.post method is undefined in that case. Forward-Port-Of: odoo/enterprise#107655
This update resolves an issue where the PIS status field on batch payments wasn't updating correctly after a refresh. The fix ensures the correct database ID is used when fetching the status, now allowing accurate PIS status updates for SEPA credit transfers and similar payments.
Original PR description
When clicking the refresh button next to the PIS status field on a batch payment (e.g., paid with SEPA credit transfer), the status is cleared and no new value is set. This occurs because `onClickFetchStatus` makes an ORM call to fetch the status using `this.props.record.data.id`, which is `undefined`. This commit fixes the issue by correctly using `this.props.record.resId` to pass the database ID to the RPC call. no task-id Forward-Port-Of: odoo/enterprise#108927
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the system used a default 38-hour week, leading to incorrect deductions. The fix ensures accurate recovery amounts based on each employee's actual working hours.
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#108876 Forward-Port-Of: odoo/enterprise#106205
This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Now, users can unlink a task from its sales order, preventing billing issues and allowing tasks to be easily reassigned. This ensures accurate task management and billing, particularly for field service tasks.
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#249574 Forward-Port-Of: odoo/odoo#241446
This update fixes alignment issues within the HTML editor's monospace banner, ensuring text columns line up correctly. Previously, tabs caused misalignment, now the editor replaces tabs with four spaces for consistent formatting. This improves the overall readability and appearance of content within the editor.
Original PR description
Tabs are aligned on 40px boundaries. This leads to misalignment of characters when using the monospace banner. This commit fixes this by replacing all tabs inside monospace banners by four spaces. Steps to reproduce: - Go to a "To do" note - Insert a monospace banner - Type some text on several lines - Type tab at the begin of some lines => Character columns were misaligned. task-5916747 Forward-Port-Of: odoo/odoo#251065 Forward-Port-Of: odoo/odoo#248227
This update resolves a bug where tests for the account invoice extraction feature were failing due to a conflict with another Odoo module activating the EUR currency. The fix ensures the USD currency is consistently used, making the tests reliable and preventing disruptions to the system. This improves the stability of the enterprise version.
Original PR description
When the tests are run with all modules installed and demo data, some of them fail. One of the other modules activates the EUR currency, which causes the OCR to select it instead of leaving the default USD currency. - Test `test_bank_account` fails because, when the `currency_id` field is set, it triggers a re-computation of `partner_bank_id` which will reset its value to `False`. Runbot build error [240759](https://runbot.odoo.com/odoo/runbot.build.error/240759). - Test `test_invoice_ocr_note_author` fails because it's not expected that the `currency_id` is modified and logged in the tracking message. Runbot build error [238512](https://runbot.odoo.com/odoo/runbot.build.error/238512) (only in saas-19.2 and up, but it is mentionned here as the fix is the same). To make the tests more reliable, we now ensure only the USD currency is active. Forward-Port-Of: odoo/enterprise#108991 Forward-Port-Of: odoo/enterprise#108770
This update resolves an issue where non-administrator users were receiving access errors when viewing the accounting dashboard with the l10n_tr_nilvera module. The fix ensures that non-admin users can access the necessary features within the dashboard, improving usability for all users.
Original PR description
…nting dashboard # How to reproduce - Add the l10n_tr_nilvera module - Have at least one journal - Connect with a non-admin user - Go to the accounting dashboard # The problem An access right error message is displayed # Why When going to the accounting dashboard, both "_compute_show_fetch_in_einvoices_button" and "_compute_show_refresh_out_einvoices_status_button" are triggered. They both try to access the nilvera api key field of account.journal but only administrator users have access to that field. opw-5928715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249425
This update fixes an issue where UAE payroll rules were incorrectly reducing employer costs. A new ‘Net Cost’ salary rule has been added to accurately reflect employer contributions, ensuring correct cost reporting for employees and employers. This improves the accuracy of financial reporting within the Odoo Enterprise system.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761 Forward-Port-Of: odoo/enterprise#107090
This update corrects a bug where the website's 'scroll to top' links (e.g., '#top') were broken due to incorrect URL processing. The fix ensures these links function correctly, providing a seamless user experience for navigating to the top of the page. A new test confirms this resolution.
Original PR description
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and…
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and `#bottom`. A menu with the URL `#top` becomes `/current-page#top`, preventing it from functioning as a universal "scroll to top" link. __Cause:__ The server-side logic for processing menu URLs does not differentiate between page-specific anchors and generic anchors like `#top` or `#bottom`, treating all anchor links as belonging to the current page. __Fix:__ In the `save` method, exclude `#top` and `#bottom` from the logic that prefixes anchors with the current page's URL. This ensures these special anchors, typically set on the header and footer, work consistently across the entire website. A new unit test verifies that `#top` and `#bottom` menu URLs are saved correctly without being prefixed. task-5941115 Forward-Port-Of: odoo/odoo#251154 Forward-Port-Of: odoo/odoo#250136
This update resolves an issue preventing administrators from viewing all email messages. Previously, access restrictions caused errors when attempting to retrieve email data. The change restores administrator access to all email communications by re-enabling necessary security permissions.
Original PR description
The model mail.mail inherits from mail.message. However, the administrator that has access to mail.mail, does not necessarily have access to the message. Since we removed fetching all messages in sudo, we get errors when trying to read messages. To restore the previous behaviour, we add back a sudo on all inherited fields. task-5954851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue where users without HR permissions were encountering errors while trying to edit bank account information for contacts. The fix hides the bank account field for users lacking the necessary HR rights, ensuring a smoother user experience and preventing access errors.
Original PR description
**Steps to reproduce** - have `hr` and `account` installed - add a bank account to a contact - switch to a user with accounting rights but no HR rights - on the contact form, click on the tag of the bank account in the "Bank accounts" field - Access Error due to missing rights related to employee model **Cause** The `_compute_employee_id` method requires read access on the `hr.employee` model. **Solution** Hide the field for non-HR users. opw-5217072 Forward-Port-Of: odoo/odoo#247792
This update fixes an issue where the 'Missing Required Details' widget incorrectly appeared on the combo and product pages, especially on smaller screens. The change ensures the widget only displays when a required attribute is present and not selected, preventing confusion and ensuring users can properly complete their selections.
Original PR description
The "Missing Required Details" widget appeared when there was required attributes to choose in combo item or on the product page AND when the height of the screen was smaller than the content size. So sometimes, it was showing when it was not required and when we clicking on it, nothing was done because we saw everything on the screen. So, what I did, is basically change the condition for displaying the widget. Now it will appear only when a title of a required attributes is hidden by the header and this required attribute is not selected. part ot task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251176 Forward-Port-Of: odoo/odoo#244667
This update fixes a misleading warning message related to employee net wages. A recent code change improved the payroll system's accuracy by ensuring the warning only appears when a negative net wage is actually present. This ensures employees and administrators receive correct information.
Original PR description
As a result of a refactor in the hr_payslip.py model, this commit mainly adds a test to check the message is not displayed if we don't have net salary, and appears if the net is indeed negative. task-5484107 Forward-Port-Of: odoo/enterprise#103918
This update corrects a minor display error in the Gantt chart for employees with flexible working hours. The issue stemmed from incorrect timezone settings in test data, which caused the chart to misrepresent employee attendance progress. The fix ensures accurate progress visualization for all employees, regardless of their timezone.
Original PR description
[FIX] hr_attendance_gantt: fix gantt progress with flex emp test
Bug reproduction:
1 - Install and update hr_payroll,hr_contract_salary,l10n_us_hr_payroll,hr_attendance_gantt modules in localhost (version >= saas-19.2)
2 - Run test_gantt_progress_with_flexible_employees test and the expected result is 8 but it gives 9.
Bug cause:
Timezone of the test employees was UTC+1 and they should be UTC to match the range parameter of _gantt_progress_bar
Bug solution:
Change the timezone of the test employees to UTC.
task - 5865307This update corrects a display issue in the Odoo Enterprise SaaS version (19.2 and later). Specifically, certain fields related to EG's local tax regulations were incorrectly showing up on employee forms for companies outside of EG. This change ensures that these fields are only visible when the company's country is set to EG, maintaining data accuracy and user experience.
Original PR description
[FIX] some EG l18n fields are visible in other country's employee forms Bug reproduction: Go to >= saas~19.2 version, install EG and select company other than EG -> payroll -> personal -> there are EG: Social Sec. Number and NOSI Registration strings that belongs to EG. Bug cause: In EG view, they did not make the additional fields invisible if they belong to other company. Bug solution: Make the appended fields invisible when company country code is not EG. task - 5975886
This update fixes an issue where banner background colors weren't consistently matching the banner content. The change ensures that background shapes, particularly connection shapes, correctly inherit the color of the associated banner snippet, providing a more polished and accurate visual appearance for website banners.
Original PR description
Steps to reproduce the problem: - Add a "Banner Categories" snippet on your page. -> The background shape color is updated with the same color than the background of the snippet. Since [1], when a snippet with a background shape is dropped on the page, the system recomputes the color of the background shape so that, if the background shape is of type 'Connections', it is updated with the color of the connecting background snippet. The problem was that two hexadecimal colors were compared in a case sensitive way in the computation of the color. [1]: https://github.com/odoo/odoo/commit/e591ea77f4a800bf79cb19f80529eed0d8ded927 task-5977647
This update fixes an issue where payroll reports and payment exports incorrectly displayed employee names instead of the actual account holder's information. By prioritizing the linked bank partner, the system now accurately reflects payment details for employees with accounts held by others, ensuring compliance and accurate record-keeping across various regions (AU, BE, CH, IN, SA, US).
Original PR description
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip…
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV). 4. Observe that the employee's name is displayed instead of the account holder's information. Issue: Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder. Solution: Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner: - Updated QWeb templates to display bank.partner_id.name for account allocations. - Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID. - Ensured a fallback to the employee's legal name remains in place. opw-5357652 Forward-Port-Of: odoo/enterprise#108496 Forward-Port-Of: odoo/enterprise#106718
This update corrects a visual bug where single custom value attributes were incorrectly displayed on product pages. The fix ensures that these attributes are only shown in the primary attribute list where they should be set, improving the consistency and clarity of product information for customers. This change enhances the user experience on our website.
Original PR description
### Issue: Due to this bug, an attribute with a single custom value will be shown in specifications and single value attributes. #### Steps to reproduce: 1- Create a product. Add a `Free text`…
### Issue: Due to this bug, an attribute with a single custom value will be shown in specifications and single value attributes. #### Steps to reproduce: 1- Create a product. Add a `Free text` attribute. 2- Navigate to product page on the website. 3- From website editor, style tab, switch `specification` style. 4- With specification style set to `None`, you can see this attribute in single value attributes list. 5- With other 2 styles you can see this attributes in specifications. Expected: In both steps 4 and 5, this attributes shouldn't be displayed there because it is already displayed in main attributes where you can set the value. Initially fix was to filter `ProductTemplateAttributeLine` in `_prepare_single_value_for_display`, however it would cause empty specification sections. To avoid that we also need to filter out single custom value attributes in `_prepare_categories_for_display`. opw-5484721 Forward-Port-Of: odoo/odoo#251022 Forward-Port-Of: odoo/odoo#244234
This update corrects a bug where custom analytic distribution settings on sales order lines were being overwritten when using project-based sales. Now, any manually set distribution values will be preserved, ensuring accurate tracking of costs associated with project sales. This improves financial reporting and compliance.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250707 Forward-Port-Of: odoo/odoo#249747
This update significantly speeds up the loading times of key reporting menus like "Invoices to be Issued" and "Invoiced Not Delivered", particularly when dealing with large customer databases. The change eliminates redundant searches, reducing processing time from over 80 seconds to just 8.5 seconds and preventing memory errors.
Original PR description
### Problem Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus caused MemoryErrors and 80+ second load times on large databases. ### Root Cause `_read_group_for_accrual` loops…
### Problem
Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus
caused MemoryErrors and 80+ second load times on large databases.
### Root Cause
`_read_group_for_accrual` loops over each group result to manually sum
non-stored computed fields. On each iteration it called `search()` with
a domain containing `('invoice_to_be_issued', '=', True)`, triggering
`_get_accrual_line_ids` once per group instead of once per request.
### Fix
Move the `search()` call outside the loop so matching records are fetched
once per request. The per-group partition is then resolved using
`search_fetch` + `grouped`, which handles the field prefetching and
grouping into recordsets in one call.
### Before / After
| Metric | Before | After |
|-------------------------------|---------|--------|
| Total request time | 82s | 8.5s |
| `_get_accrual_line_ids` calls | 82 | 3 |
| MemoryError on large DBs | ✓ | ✗ |
opw-5392606
Forward-Port-Of: odoo/enterprise#108102This update fixes a mobile map layout issue where the pin list was too small, making it unusable. The team replaced the fixed list with a toggle button for accessing the pin list, enhancing the mobile map's usability and appearance. This improves the user experience for mobile map viewers.
Original PR description
**Problem:** Recent changes (https://github.com/odoo/enterprise/pull/104618) broke the mobile map layout, causing the pin list to shrink to an unusable 46px height on top of the map. **Solution:** Replaced the permanent list section with a toggle button to access the pin list on demand. Added polishing CSS to improve the general mobile aesthetic and usability of the map view. task-5126312
This update resolves a problem where the Italian fiscal printer wasn't printing correctly due to a delay in syncing order information. The fix ensures the ticket is printed only after the order is fully synchronized, preventing errors related to missing currency data. This improves the reliability of the Italian POS system.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. 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#247169
This update resolves a problem where Italian fiscal printers weren't working correctly. The fix ensures the order is fully synced before printing the ticket, preventing errors related to missing currency information. This improves the reliability of printing invoices for Italian businesses using the Odoo Enterprise system.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. Forward-Port-Of: odoo/enterprise#106455
This update corrects a previous issue where the system incorrectly predicted taxes on imported invoices. Now, the system accurately identifies and uses the tax information directly from the XML invoice file, ensuring correct tax calculations. This improves data accuracy and compliance.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%), even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. After this commit, the prediction is more rigorous and correctly relies on the tax information provided in the XML (restricted search domain) task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249930 Forward-Port-Of: odoo/odoo#246308
This update resolves an issue where users weren't receiving clear guidance when attempting to process after-departure payments. Now, the system displays a helpful error message, requiring a previous payslip for these payments. This ensures accurate payroll processing and avoids technical errors.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#108980 Forward-Port-Of: odoo/enterprise#107386
This update resolves an issue where tests within the Sale Stock module were temporarily disabled. The team has re-enabled these tests to ensure the module's functionality continues to operate correctly and reliably. This ensures ongoing quality control and stability for our sales and inventory processes.
Original PR description
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#246522
This update fixes an issue where the 'hours_per_day' and 'hours_per_week' fields weren't correctly recalculated when using the 'Define Amount of Hours per day' option in Working Schedules. The change ensures these values update dynamically when the duration is modified, providing accurate scheduling information.
Original PR description
### Issue: When creating a Working Schedule, and choosing the option "Define Amount of Hours per day" then the fields `hours_per_day` and `hours_per_week` are not recomputed correctly. ### Steps to…
### Issue: When creating a Working Schedule, and choosing the option "Define Amount of Hours per day" then the fields `hours_per_day` and `hours_per_week` are not recomputed correctly. ### Steps to reproduce: - Create a new Working Schedule - Tick the option "Define Amount of Hours per day" - Change the duration on a line - Hours per day and hours per week are not updated ### Cause: This [commit](https://github.com/odoo/odoo/commit/77f860f5d3757e5a56861ac1de95b9ad29ea0dff) introduced the possibility of defining `resource.calendar.attendance` with `duration_hours` instead of `hour_from`/`hour_to`. The fields `hours_per_week`/`hours_per_day` are recomputed when changing `hour_from`, `hour_to` or `duration_hours`. This recompute is done because an onchange is triggered and will recompute all compute fields displayed in the form view. As the fields `hour_from`/`hour_to` are not computed, they are not changed when changing `duration_hours` on the form view but they are when saving because of `_inverse_duration_hours()`. The compute method of `hours_per_week` only takes into account `hour_from`/`hour_to`. So if `duration_based` is False, then changing `hour_from` will recompute `hours_per_week` but changing `duration_hours` will not as `hour_from`/`hour_to` still have the previous values. ### Solution: We need the recomputation to be made on `duration_hours` when `duration_based` is True. As `duration_hours` is recomputed via `_compute_duration_hours()` when `hour_from`/`hour_to` change, we only use `duration_hours`. opw-5942240 Forward-Port-Of: odoo/odoo#251048 Forward-Port-Of: odoo/odoo#249446
This update fixes an issue where employees with future attendance records couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's status, preventing the error and restoring normal checkout functionality. This improves the user experience for employees managing their time.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867 Forward-Port-Of: odoo/odoo#248875
This update fixes a limitation in the eCommerce search bar's placeholder text, preventing it from being translated. The change replaces a technical method with a standard translation-friendly format, ensuring all placeholder text can now be localized for different languages. This improves the user experience for international customers.
Original PR description
The placeholder of the search bar for attributes in eCommerce was not translatable, because it was using a Python expression to set its value. This commit replaces the Python expression with a t-attf-placeholder, which allows the placeholder to be translated. opw-5978276 Forward-Port-Of: odoo/odoo#251288 Forward-Port-Of: odoo/odoo#251145