Daily updates from Odoo
Navigate
Branch
Monday, March 2, 2026
238 changes
27 changes
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
24 changes
Enhancements to existing features
This update enhances how Odoo identifies partners in Saudi Arabia. Previously, partner identification relied solely on VAT. Now, it also considers the Identification Scheme and Identification Number, leading to more accurate distinctions between companies and individuals, especially when VAT information is unavailable.
Original PR description
Before this commit: - Partner identification relied only on the VAT field. After this commit: - Partner identification in Saudi Arabia also considers Identification Scheme and Identification Number. - This improves detection of companies vs individuals when VAT is missing. task-5866942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 account for these deductions. 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 error that occurred when users attempted to initiate the Colombian Electronic Invoicing certification process without a pre-existing certificate. The fix prevents a traceback by ensuring the system handles the case where no certificate is found, improving the user experience and preventing process interruptions.
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 corrects a previous issue where archived accounts could be incorrectly assigned as default journal accounts. Previously, the system allowed inactive accounts to be used, leading to potential inconsistencies. This change ensures that only active accounts are considered for journal defaults, maintaining data accuracy and stability.
Original PR description
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account…
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account is assigned by the onchange method. ### Issue: - Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange] (https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals. - This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts. ### Solution: - Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior. OPW-5501539 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#246725
This update fixes an issue where the 'Missing Required Details' widget incorrectly appeared on the self-order system, especially on smaller screens. The change ensures the widget only shows when a required field is hidden and hasn't been selected, providing a smoother user experience.
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#244667
This update resolves a bug that caused inventory valuation reports to fail when stock moves associated with subcontracting had multiple destination receipts. The fix limits the record considered during valuation to the last 'done' receipt, ensuring accurate inventory reporting. This improves the reliability of inventory valuation processes.
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 an issue where accounting users without HR permissions would encounter an error when trying to edit a contact's bank account. The fix hides the bank account field for users lacking the necessary HR rights, ensuring data integrity and preventing unexpected 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 resolves an issue where overtime calculations failed when an employee had multiple versions with differing rulesets. The fix ensures that only the correct ruleset is used during overtime generation, preventing errors and guaranteeing accurate compensation. This improves the reliability of our attendance tracking system.
Original PR description
_ ## Short functional explanation of the error When we generate overtime for an employee who has 2 different versions. If each version has a different overtime ruleset and an attendance exists during…
_ ## Short functional explanation of the error When we generate overtime for an employee who has 2 different versions. If each version has a different overtime ruleset and an attendance exists during the time frame of each version. When trying to generate overtime for the ruleset of the first version, a traceback occurs. ## Reproduction Steps 1. Create an employee. Create 2 different versions for this employee. On each version, set a different overtime ruleset. 2. Create 2 attendances: one during the time frame on which the first version applies, and one during the time frame on which the second version applies. 3. Go to overtime rulesets. Click on the ruleset you applied on the first version and click Reenerate Overtimes. ### Expected behavior The overtimes are regenerated correctly. ### Unexpected behavior A traceback occurs: `ValueError: Expected singleton: hr.attendance.overtime.ruleset(7, 6) ` ## Origin of the issue In the code, we retrieve the version applying to the attendance for which we want to compute overtimes, to get the ruleset with which we will compute the compensation for overtimes: https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/addons/hr_attendance/models/hr_attendance.py#L303-L306 However, `version = inter._items[0][2]` returns both versions, thus obtaining both rulesets and creating the error when trying to accss the field `self.ruleset_id.rate_combination_mode` later, as self.ruleset_id will contain both rulesets. __ opw-5443700 Forward-Port-Of: odoo/odoo#249736
This update corrects an issue where the IoT module couldn't properly access a key token. By directly accessing the token from the pos_self_order service, the system now reliably retrieves and utilizes this data, ensuring smoother operation of IoT-connected point-of-sale systems. This improves data accuracy and functionality.
Original PR description
Access token is not accessible from pos_config, it should be accessed from pos_self_order service directly. Forward-Port-Of: odoo/enterprise#109158
This update fixes an error in the Spanish Profit & Loss reports where accounts 7950 and 7957 were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
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 bug in the pipeline dashboard that prevented accurate matching of leads within the first list. The change ensures that the dashboard displays correct data, improving the visibility and accuracy of sales pipeline information. This resolves a previously reported issue impacting sales performance.
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 enhance the report's data quality and reliability for financial reporting compliance.
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 integration to comply with a new law. Starting January 1, 2025, forfettari (RF19) can now utilize simplified invoices regardless of the total amount. This simplifies invoice processing 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 stable column insertion functionality within list items.
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 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 rights.
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 corrects a bug where custom analytic distribution settings on sales order lines were being overwritten when using product-partner combinations with Analytic Distribution Models. Now, user-defined distributions are 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 fixes an issue where SII invoices weren't correctly formatted, preventing successful submission. The change updates XML tags related to withholding taxes 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 update resolves an error that occurred when generating the Reception Report through Odoo's Web Studio. The issue stemmed from an incorrect data type being passed to a database query, preventing the report from loading. The fix removes problematic data types to ensure proper report generation.
Original PR description
Currently an error occurs when user tries to open reception report through web studio. Steps to replicate: - Install stock, web_studio with demo. - Open receipts and turn on studio mode. - Go to…
Currently an error occurs when user tries to open reception report through web studio. Steps to replicate: - Install stock, web_studio with demo. - Open receipts and turn on studio mode. - Go to reports and try to open `Reception Report`. Error: ``` psycopg2.ProgrammingError: can't adapt type 'NewId' ``` Cause: - Error occurs after this [PR] that prevents passing of falsy ids to orm. - As a result the [line] passes `api.NewId()` that is received as `docids` in the function `_get_docs()` performs search using the `NewId` [here] which causes this error to occur. - In the previous version the id passed was passed a static list `[0]` and then changed to `api.NewId()` which works perfectly fine with `browse()` but with any other operation that fires direct queries like `search()` or `_read_group()` it will cause this error to occur. Solution: - Removed NewIds from docids before the search. [PR]: https://github.com/odoo/enterprise/pull/95117/changes#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R645 [line]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/web_studio/controllers/report.py#L649 [here]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/stock/report/report_stock_reception.py#L190 sentry-7236339558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet component to the latest version (19.1.8). It includes several performance improvements and bug fixes related to spreadsheet calculations and rendering, ensuring a smoother user experience when working with spreadsheets in Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/308237a70c [REL] 19.1.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/308237a70c [REL] 19.1.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5f09698747 [REV] borders: revert infinite borders [Task: 5932734](https://www.odoo.com/odoo/2328/tasks/5932734) https://github.com/odoo/o-spreadsheet/commit/4d6dd66e7f [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/e0169c6507 [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/8ffb04ba31 [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/31c21dd164 [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/8bc66cca9b [PERF] recompute_zone: binary search with bit shift [Task: 5955352](https://www.odoo.com/odoo/2328/tasks/5955352) https://github.com/odoo/o-spreadsheet/commit/943331f6d9 [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/ca96bd9a84 [FIX] package: saas-19.1 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update reverses a recent change to the spreadsheet edition's styling, specifically related to borders. The change was reverted to restore the previous visual appearance. This ensures consistent and expected formatting within the spreadsheet functionality.
This update fixes a bug where restarting the chat bot after a page reload caused duplicate actions. Previously, reloading the support page and restarting the bot would result in multiple questions being presented simultaneously. The fix removes a redundant call to start the bot during the restart process, ensuring a smoother user experience.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 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#250782 Forward-Port-Of: odoo/odoo#250623
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 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 Forward-Port-Of: odoo/enterprise#108933 Forward-Port-Of: odoo/enterprise#106974
This update resolves an issue where users weren't receiving clear guidance when a previous payslip was missing for after departure payments. Now, a helpful error message is displayed, guiding users to add a required reference payslip. This ensures accurate payment 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 fixes an issue where the shipping weight for deliveries wasn't accurately calculated when products were placed into packages. The fix ensures that the total weight of items in a package is correctly reflected in the delivery's shipping weight, improving order accuracy and fulfillment.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#249029
Forward-Port-Of: odoo/odoo#2389173 changes
Resolved issues and error corrections
This update fixes a visual inconsistency in the Discuss app's dark mode. The background colors of the navbar buttons and breadcrumbs were previously mismatched compared to the main control panel. This change ensures a more polished and professional user experience across all Odoo modules in dark mode.
Original PR description
The background color of navbar buttons and breadcrumbs in discuss app differed from that of control panel. This PR aligns and syncs these colors for a consistent UI. | Before | After | |--------|-------| |<img width="467" height="99" alt="image" src="https://github.com/user-attachments/assets/2def30f8-18aa-4399-a5d1-1cdc70b4cd81" /> |<img width="458" height="111" alt="image" src="https://github.com/user-attachments/assets/5578cd25-7686-4543-a8dc-3e0fe5aeb4fc" />| This PR contains backport of #217608 task-[4936733](https://www.odoo.com/odoo/project/1519/tasks/4936733) task-[5487197](https://www.odoo.com/odoo/project/1519/tasks/5487197) Forward-Port-Of: odoo/odoo#250601
This update adjusts Odoo to comply with a new Italian law, effective January 1, 2025. It now allows forfettari (RF19) to 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 ensures that transactions imported via the Odoo cron process are correctly split according to the journal configuration, mirroring the behavior of manual imports. Previously, the cron process bypassed this splitting logic, leading to incorrect accounting. This fix improves the accuracy of financial data processing.
Original PR description
When importing CODA files manually, transactions are correctly split according to the journal configuration. However, when processed via the cron, the splitting logic is bypassed because the journal recordset is empty at the time of parsing. This occurs because the journal is identified only after the file has been parsed, which is too late for the cron flow. This commit ensures the journal is available early enough to respect the "Split Transactions" setting regardless of the import method. opw-4954539 Forward-Port-Of: odoo/enterprise#107560 Forward-Port-Of: odoo/enterprise#106344
1 change
Resolved issues and error corrections
This update resolves an issue where HR document sharing links wouldn't work for employees without a user account. The fix ensures that documents can be shared correctly, even when an employee leaves the company, streamlining the offboarding process.
Original PR description
purpose: when an employee leaves the company, it's expected to send the HR Documents Access Link. But, an error occurs if the employee is not linked to a user. fix: - made the error appear only when the employee doesn't have a private email and not depend on the employee being linked to a user - made the documents check for `work_contact_id` to get the partner related to the employee instead of `user_partner_id` task-id: 5876084 Forward-Port-Of: odoo/enterprise#105652
33 changes
New functionality added to Odoo
This update incorporates essential testing for the Stripe expense module, addressing a previous oversight in the original development task. The changes include fixes for a parameter type issue and a billing state requirement, ensuring the module functions reliably and securely. This improves the overall stability and quality of the expense reporting process.
Original PR description
Add tests for the module, as it wasn't included in the original task Forward-Port-Of: odoo/enterprise#108053 Forward-Port-Of: odoo/enterprise#106191
This update includes sample data for a project's profitability dashboard, ensuring the section displays correctly. This addition facilitates future feature development and aids in identifying potential issues within the dashboard functionality. It's a small improvement to support ongoing development and testing.
Original PR description
This commit's purpose is to add demo data to a project in order to have all the profitability section appears. This will help with the creation of new features and the detection of bugs.
This update adds flexibility to how Labour Welfare Fund (LWF) deductions are handled in employee payroll. Businesses can now choose between monthly, half-yearly, or yearly cycles for LWF deductions, aligning with employee contracts. This improves payroll accuracy and reporting for companies operating in Russia.
Original PR description
- Introduced the Deduction Cycle option under Labour Welfare Fund (LWF) settings in employee payroll. - Default cycle set to monthly, with options for half-yearly and yearly. - Updated LWF salary rule: follow the selected deduction cycle from the employee contract. - Adjusted deduction logic to handle monthly, half-yearly (June & December), and yearly (December) cycles. task-4222503
Enhancements to existing features
This update improves the Work Entries Gantt view by displaying warning icons directly on employee rows. This allows operators to quickly identify employees with missing data (like contracts) without navigating to individual employee forms, streamlining their workflow and improving data visibility.
Original PR description
Operators processing work entries often need to see if an employee has blocking data issues (like missing contracts) directly from the Gantt view, without opening the individual employee form. This commit enhances the Work Entries Gantt view to display these warnings inline. Changes: 1. **Gantt Renderer:** - Extended `WorkEntriesGanttRenderer` to fetch warning data during the `onWillStart` lifecycle. - Modified the XML row header to display an orange warning triangle next to the employee name if issues exist. - Added a click handler to the icon that redirects the user to the Employee form (where the detailed banner from `hr` will be visible). 2. **Backend Logic:** - Added `get_gantt_employee_warnings` to `hr.employee`. This method is optimized for the Gantt view, returning a simple list of error strings for the visible employees, separate from the detailed JSON logic used in the form view. task-5118781
Resolved issues and error corrections
This update ensures that check printing accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly account for 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 error that occurred when users attempted to initiate the Colombian Electronic Invoicing certification process without a valid certificate. The fix prevents a traceback by ensuring the system handles the case where no certificate is found, improving the user experience and preventing process interruptions.
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 clarifies the help text within the Odoo Enterprise payroll module. A previously inaccurate statement was removed to ensure users receive correct information. This change improves the overall usability and accuracy of the payroll functionality.
Original PR description
the last sentence is not always the case so we needed to remove it. task-5423317
This update addresses a recent issue causing tour navigation failures within the Industry FSM modules. The problem stemmed from a removal of a step in a tour file, specifically impacting 'patched tours'. This fix ensures tours function correctly, improving the user experience for those utilizing Industry FSM.
Original PR description
This commit fixes the tours that were failing in `industry_fsm` and `industry_fsm_sale`. The root cause was because of the removal of some step in `industry_fsm_tour`, which is used in patched tours. task-5945991
This update fixes an error in the Spanish Profit & Loss reports where accounts 7950 and 7957 were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
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 result page related to date formatting. The change ensures consistent display of helpdesk items. This was necessary following a recent update to the Odoo system.
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 where scrap orders created from the shopfloor didn't trigger notifications. The change ensures that users receive a confirmation message when a scrap order is successfully registered, improving workflow visibility. This resolves an issue reported previously and ensures consistent notification behavior.
Original PR description
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to…
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to Reproduce: ========================= - Install the mrp_workorder module. - Create a Manufacturing Order for any product (e.g. [FURN_7023] Wood Panel). - Open the shopfloor view. - Click the three-dot menu to access more options. - Create and confirm a scrap order. - No acknowledgement/notification is shown to the user. Cause of the issue: ========================= The method responsible for triggering the notification was renamed in [this PR](https://github.com/odoo/enterprise/pull/85706), but the notification condition was still referring to the old method name. As a result, the notification was never triggered. With This Commit: ========================= Align the method name used in the notification condition so that, when a scrap order is created from the shopfloor, the user correctly receives the notification: `The scrap order has been successfully registered.` Community PR: https://github.com/odoo/odoo/pull/250024 Task: 5958933 Forward-Port-Of: odoo/enterprise#108259
This update enhances the accuracy of payment reference checks by tailoring validation to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system verifies the reference format against the specific country of the bank account, with a fallback for unsupported countries, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#109070 Forward-Port-Of: odoo/enterprise#107116
This update resolves issues with the Belgian XBRL report, specifically correcting inaccurate translations and removing irrelevant company types. The changes enhance the report's data quality and compliance, ensuring more reliable financial reporting.
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 fixes an issue where employees without recorded leave time were not visible in the Gantt view. Now, all employees will be displayed, ensuring a more complete and accurate representation of the workforce. The change improves usability and provides a clearer picture of employee availability.
Original PR description
When going on *Time Off / Management / Time Off > Gantt view*, employees without records (i.e.: leaves) would not be shown. This PR aims to display those employees without records, even supporting any eventual will to paginate the gantt view. To ensure intuitivity, those recordless employees are shown only if the domain passed to the gantt only filters based on fields related to `employee_id`. task-5477588
This update introduces NACE (a European economic classification) codes into the Belgian HR payroll module. This enhancement allows for more detailed reporting and analysis of employee salaries by industry sector, improving compliance and providing valuable business insights. The changes also include updates to flat rate calculations.
This update fixes an issue where payroll rates weren't accurately calculated for employees on attendance-based contracts. The system now correctly uses the planned working schedule's hours per day to determine rates for salary and allowances, ensuring accurate pay calculations when attendance is the primary work source.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#109048 Forward-Port-Of: odoo/enterprise#103282
This update fixes a bug in the pipeline dashboard where one of the lists wasn't correctly matching data. This ensures that all sales opportunities are accurately displayed and tracked within the dashboard, providing a more reliable view of sales performance. The change was made to improve data accuracy and reporting.
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 fixes an issue where dependent salary rules weren't appearing in the employee input selection. The change ensures that all relevant rules, including dependent ones, are displayed when adding inputs, streamlining the payroll configuration process. This prevents users from missing crucial rules and simplifies payroll setup.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461 Forward-Port-Of: odoo/enterprise#109049 Forward-Port-Of: odoo/enterprise#107719
This update corrects an issue where work entries weren't being generated when multiple resource calendar attendances were adjacent. The fix prevents consecutive attendances from being combined, ensuring accurate work entry creation, particularly for credit time entries. The change was driven by a bug discovered during testing and incorporates previously removed tests for comprehensive coverage.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994 Forward-Port-Of: odoo/enterprise#109050 Forward-Port-Of: odoo/enterprise#105981
This update fixes issues related to the integration of Field Service within the Planning app. Key changes include a new format for time tracking, streamlined field visibility, and the reintroduction of geolocation services, enhancing the efficiency of field service operations.
Original PR description
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used…
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used for allocated hours and break time fields in planning, - some planning.slot fields are hidden in the form view when field service integration is enabled to reduce the number of fields inside that view since those fields were more useful for a planning manager to prepare the intervention of his workers, - some access right errors are fixed, - the planning user can no longer edit access once field, service integration is disabled, - field service geolocation service has been re-introduced since it was removed when the timer in timesheets has been reviewed, - some terms are now correctly translated, - `planning_field_service` module is flagged as an application, - `Products` menu item has been added in planning field service, - map and activity views has been been added in all planning menu items when field service is enabled. task-5921961 Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com> Forward-Port-Of: odoo/enterprise#108363
This update fixes a reporting issue where NSSF Tier 2 and Pension Contribution deductions weren't always displayed on payslips, even when correctly processed. The changes ensure all contributions are accurately reflected on the payslip, improving payroll transparency and compliance.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380 Forward-Port-Of: odoo/enterprise#106173
This update fixes an issue where fast payments through the Point of Sale (POS) system were not creating the necessary 'pay later' accounting line. The fix ensures that both normal and fast payment validation processes now correctly generate the required accounting entries, maintaining accurate financial records. This improves the reliability of fast payment processing.
Original PR description
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and…
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0 4. Select the invoice(s) 5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom. -> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method. Why the issue ------------- If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created. That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions. After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places: 1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation. 2. On the products screen, when using fast payment, that is fast validation. For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation. However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation. The fix ------- Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation. Notes ----- - We keep the methods in `payment_screen` for backward compatibility, they will be removed in master. - We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`. opw-5488587 Forward-Port-Of: odoo/enterprise#108602 Forward-Port-Of: odoo/enterprise#105660
This update fixes an issue where SII invoices weren't being generated correctly, preventing successful electronic submission. The change updates XML tags related to withholding taxes to align with SII's specific invoice format requirements. This ensures invoices are properly validated and accepted by the SII system.
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 update fixes a technical error that prevented users from successfully using commands within Odoo's AI chat channels (like '/help'). The issue stemmed from an undefined 'message' response during command execution, now resolved through a code update. This ensures a smoother experience for users interacting with the AI features.
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 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 resolves access restrictions preventing basic users (sale, purchase, stock) from completing key workflows like creating invoices and purchase orders. The change ensures minimal access users can correctly interact with core sales, stock, and purchase processes.
Original PR description
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields…
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access. Here is a list of examples (each performed with every other access rights disabled): - With a `stock user`, open the delivery list or form view #### > Access error - With a `purchase user` create and confirm a PO > Upload Bill #### > the Bill will be created but an access error will prevent the draft bill from opening. - With a `sale user` create and confrim an SO > Create invoice #### > the invoice will be created but an access error will prevent the draft invoice from opening. ## Solutions: ### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user: 1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model. Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view. #### Note for master: IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52 2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53 ### Use case: Open a `stock.picking` views as basic stock user: 3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496 opw-5461135 opw-5417749 Forward-Port-Of: odoo/enterprise#107732 Forward-Port-Of: odoo/enterprise#106694
This update resolves a traceback issue that occurred when reloading the Studio page after opening the product catalog. The change creates a proper action, ensuring the Studio page loads correctly and prevents errors when toggling debug mode or refreshing.
Original PR description
*planning_field_service_sale_timesheet Steps to reproduce: - In Field Service, open the product catalog from a task using state button. - Open Studio - Enable/Disable debug mode or just refresh the page traceback occurs. After this commit: Created the real action so in studio refresh the action loads properly. This prevents the traceback when reloading the page or toggling debug mode. task-5478056
This update resolves a problem where tests were failing when the system used the EUR currency alongside the default USD currency. The fix ensures the USD currency is always active, making the tests more reliable and preventing unexpected errors. This improves the stability of the account invoice extraction feature.
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 fixes an issue where the legal name displayed in the payroll module for Chinese employees was not accurately calculated. The change ensures that the correct legal name is used, complying with local regulations and improving data accuracy for reporting and compliance purposes. This update impacts the HR Payroll module.
Original PR description
task-5979726 Forward-Port-Of: odoo/enterprise#109037
Features or functions removed from Odoo
This update removes a redundant field from the VoIP call data used in the spreadsheet dashboard. The field was added in a separate module and wasn't actually utilized, so it's been removed to streamline the data and improve efficiency. This change ensures the dashboard only displays relevant information.
Original PR description
`summary` field on `voip.call` is added in `voip_ai` which is not a dependency of `spreadsheet_dashboard_voip`. As the field is not used in the dashboard, this commit removes it. Fixes runbot #240996 Forward-Port-Of: odoo/enterprise#108120
This change removes unnecessary URLs from the JavaScript files used for onboarding tours. These URLs caused unwanted redirects, wasting user time and creating a confusing experience. The URL functionality will now be managed through XML files instead.
Original PR description
The URL key in a tour's JavaScript file implies a redirect to that URL once the browser opens. If this URL is the same as the one used in `start_tour()` (Python), then it serves no purpose. It's even detrimental because it implies a redirect (and therefore a waste of time). The URL key in the JS file is (for now) only used for onboarding tours. This key will be defined later in the .xml file for onboarding tours. That's why we're removing the URL keys from the registries here.
Code cleanup and technical improvements
This update streamlines the creation of guided tours within Odoo by removing a complex waiting mechanism. The change simplifies the tour API, making it easier for developers to create and manage tours. This improves overall system efficiency and consistency.
Original PR description
Before this commit, the `wait_for` key was used in tours to allow waiting for a promise to resolve before starting the tour. This commit removes all usages of `wait_for` in order to completely eliminate it and simplify the tour API. Since the tour engine already waits for a trigger and then executes the action for each step, the same behavior can be achieved by defining an initial step with a generic trigger (e.g., `body`) and an async `run` function that awaits the promise. This approach removes the need for a dedicated `wait_for` mechanism while keeping the same flexibility and improving API consistency.
This change prepares Odoo for the upcoming OWL3 migration by replacing an outdated reporting directive, 't-esc', with the newer 't-out'. This ensures compatibility with the new system and avoids potential issues during the migration process. The update includes automated script execution and manual adjustments across multiple Odoo modules.
Original PR description
In OWL 3 the directive `t-esc` does not exist anymore. In this PR to prepare for the OWL migration, we replace all `t-esc` directives by `t-out`. Community PR: odoo/odoo#247002
4 changes
Resolved issues and error corrections
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in the wrong section. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
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 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 is properly cleared when the contract is signed, preventing data duplication and maintaining accurate employee records. This improves data consistency and reporting.
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 Forward-Port-Of: odoo/enterprise#108933 Forward-Port-Of: odoo/enterprise#106974
This update prevents users from canceling subscriptions if they don't have access to the associated invoices. Previously, a sales representative could cancel a subscription even if invoices were outstanding but not visible to them. Now, the system requires invoice visibility before allowing cancellation, ensuring accurate subscription management.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108321 Forward-Port-Of: odoo/enterprise#106441
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
6 changes
Enhancements to existing features
This update simplifies the synchronization of partner addresses and VAT information within Odoo. Previously, changes to a child partner's VAT would be lost when syncing with the parent company. Now, VAT information is correctly propagated to child partners, improving data consistency and reducing manual updates. This change focuses on VAT synchronization for a smoother user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/206112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects a minor syntax error in the PWA service's CSS selector, which was preventing the application from correctly registering during installation. This resolves a potential issue that could have blocked users from installing the PWA version of Odoo. The fix targets version 18.0 and ensures a smoother PWA installation experience.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a technical issue that prevented users from sending follow-up reports by post when they lacked sufficient permissions to modify company settings. The fix allows for necessary changes to be made as an administrator, ensuring reliable report sending functionality. This resolves a potential disruption to the report generation process.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855
This update fixes an issue where down payment invoices generated from sales orders or Point of Sale transactions were missing tax. The fix automatically applies a 0% tax to down payment lines to ensure invoices comply with tax regulations. This improves financial accuracy and reduces the risk of non-compliance.
Original PR description
In certain conditions all lines in invoice require a tax. When making a down payment from an order containing products using fixed price tax, the corresponding invoice line was created without tax.…
In certain conditions all lines in invoice require a tax. When making a down payment from an order containing products using fixed price tax, the corresponding invoice line was created without tax. The issue appear both when making the down payment from the sale order and from the PoS. Steps to reproduce: ------------------- * Create a fixed price tax of 10€ * Create a product with this tax * Create a sale order with this product and make a downpayment of 10% > Observation: The down payment line has no tax set. * Open PoS and make a down payment of 10% for the same order * Pay and invoice the order > Observation: The down payment line has no tax set. Why the fix: ------------ If the tax is required on every invoice line we manually add a 0% tax to the down payment line to ensure that the invoice is compliant. At the moment we only add the tax when peppol is activated on the current company. But the `_require_tax_ids_on_invoice_lines` method can be overriden by other modules if downpayment lines also require tax. opw-5853070
This update resolves a problem preventing PDF exports of composite reports that included journal report sections. The fix ensures that journal reports are processed correctly during PDF generation, allowing users to download reports with accurate data. This improves the functionality of composite reports for users generating financial statements.
Original PR description
# Steps to reproduce: * Enable **Developer Mode**. * Go to **Accounting → Configuration → Accounting → Accounting Reports**. * Create a new report and enable **Composite Report**. * Add a new line of…
# Steps to reproduce: * Enable **Developer Mode**. * Go to **Accounting → Configuration → Accounting → Accounting Reports**. * Create a new report and enable **Composite Report**. * Add a new line of type **Journal Report**. * Save the report and create a menu item from the gear icon. * Open the report from the reporting menu. * Try to download the report in **PDF** format. # Observed behavior: * PDF export fails with a traceback. * Composite reports containing journal report sections cannot be exported as PDF. # Cause When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering. * The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report. * For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template. * Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines. * This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow. * The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22). * When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline. * Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`. In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one. # Fix: * Add PDF export support to the journal report custom handler. * Centralize common print option logic in a shared helper. * Update composite report export logic to delegate PDF generation to custom handlers when available. * Journal reports inside composite reports now export to PDF correctly. opw-5477551
This update ensures that loyalty cards can be scanned correctly in POS, even if the customer isn't already in the initial list of preloaded customers. Previously, a low customer limit caused errors when scanning new loyalty cards. This fix improves the customer experience by allowing all loyalty card scans to function properly.
Original PR description
When scanning a loyalty card in POS, the customer should be automatically selected. However, this fails when the customer is not in the initial preloaded customer list due to the…
When scanning a loyalty card in POS, the customer should be automatically selected. However, this fails when the customer is not in the initial preloaded customer list due to the limited_customer_count setting. Partial backport of: https://github.com/odoo/odoo/commit/e2843355898d4cce953fba35504170c10910fc35 Steps to reproduce: ------------------- * Open POS with limited_customer_count set to a low value (e.g., 5) * Create a loyalty card for a customer that won't be in the top 5 preloaded * Scan the loyalty card barcode in POS > Observation: Customer is not selected, shows "Invalid coupon code" error Why the fix: ------------ The current implementation only searches for loyalty cards in the local POS cache. When a loyalty card's partner_id is not resolved (because the partner wasn't preloaded), the code fails to set the customer. This fix backports the 19.0 solution which: 1. Uses server-side lookup via get_loyalty_card_partner_by_code() to find the partner ID from the loyalty card code 2. Explicitly loads the partner on-demand if not in the local cache 3. Works regardless of whether the customer was in the initial preload The test didn't spot that previously because the default limited_customer_count was big enough. opw-5778328
2 changes
Resolved issues and error corrections
This update resolves an issue where foreign vendor VAT invoices were not correctly identifying the country of origin. The fix adds the necessary country code to vendor bills, ensuring accurate reporting for Polish VAT compliance. This improves the accuracy of JPK reports.
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264)
Features or functions removed from Odoo
This update removes a now-unnecessary field ('Visible Internally Only') from the customer rating form in the Helpdesk module. Since customer ratings are no longer displayed on the website, this field was causing confusion and clutter. This change improves the user experience and simplifies the Helpdesk interface.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052**