Daily updates from Odoo
Monday, April 13, 2026
194 changes
19 changes
Resolved issues and error corrections
This update resolves an issue where Odoo displayed a misleading 'This message has been removed' notification in the chatter when an approval request was canceled before a purchase order was created. The fix ensures that chatter messages are only logged when there's actual information to display, improving the user experience and preventing unnecessary notifications.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998 Forward-Port-Of: odoo/enterprise#112454
This update enhances the logging of Stripe payment rejections for expense reports. Now, both the MCC name and code are recorded, providing clearer details for troubleshooting and improving the accuracy of expense data. This change helps our team quickly identify and resolve issues related to payment processing.
Original PR description
Before this commit: - Only the MCC name was logged when Stripe refused an MCC. After this commit: - The MCC code is now logged along with the MCC name for better clarity and debugging. task-6084569 Forward-Port-Of: odoo/enterprise#112599
This update simplifies error messages during database synchronization, reducing user alarm and confusion. Instead of detailed error lists, users now see a summary count of issues. Detailed error information is now logged in a separate location for technical review, streamlining the process.
Original PR description
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors,…
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors, the wizard now displays a single summary message indicating the number of databases that encountered an issue. A new Unreachable project tag is introduced (loaded from project_tags.xml if missing). It is automatically assigned to failing databases and removed upon the next successful synchronization. Detailed error information is no longer shown in the wizard and is instead logged in the chatter of the corresponding database settings for further inspection. Previously displayed non-blocking warnings for already-configured SaaS databases are now omitted to reduce noise, as they would otherwise generate chatter messages at each synchronization. Task-id: [5945269](https://www.odoo.com/odoo/project.task/5945269) Forward-Port-Of: odoo/enterprise#113585 Forward-Port-Of: odoo/enterprise#107975
This update resolves a warning message appearing when employee contracts partially overlapped with payslip periods. The fix ensures that contracts with even a single overlapping day are now processed without the warning, improving user experience. This change was made to align with the latest version (v.19) and addresses a known issue in previous versions.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves a problem where EPD bill payments weren't correctly marked as 'paid' in the system. The fix ensures that payments are accurately reflected after reconciling an EPD bill with a bank transaction, improving financial reporting accuracy. This was triggered by a specific test scenario involving early payment terms and EPD bills.
Original PR description
Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Fix in community: https://github.com/odoo/odoo/pull/256486 opw-5881976 Forward-Port-Of: odoo/enterprise#113357 Forward-Port-Of: odoo/enterprise#112398
This update ensures payroll calculations and leave allocations are accurate by restricting work entry types to match the employee's country. A new automated process now converts generic work entry types to localized versions upon installation, resolving potential errors and improving data consistency across the system.
This update resolves a technical issue that was preventing our payroll performance tests from running correctly. The change ensures the test setup properly initializes time off types, restoring the test suite's functionality without impacting normal business operations. This improves the reliability of our payroll performance testing.
Original PR description
Description of the issue this commit addresses: A constraint forbids changing requires_allocation on time off types once related leaves exist. The payroll performance test setup still toggled that field directly so the class crashes during initialization. --- Desired behavior after this commit is merged: This commit makes the performance test setup update seeded time off types in install context. The class initializes correctly again and the broken payroll test suite runs without changing normal business behavior. --- runbot-240729
This update resolves an issue where the 'Results Brought Forward' line on the Luxembourg balance sheet displayed incorrect values. The fix adjusts how the balance sheet calculates retained earnings, ensuring accurate reporting after year-end adjustments are made. This improves the reliability of financial reporting for Luxembourg companies.
Original PR description
… sheet Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated)…
… sheet
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/enterprise#111328A bug was preventing users from deleting timesheets when a confirmation dialog was open. The fix ensures that pressing the Enter key in the timesheet list view now correctly triggers the delete action instead of starting or stopping the timer. This improves the user experience and prevents incorrect time tracking.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#113207 Forward-Port-Of: odoo/enterprise#112583
This update addresses a minor usability issue in the Odoo form editor. Previously, groups within the editor were difficult to see and access due to a lack of padding. This change reintroduces padding to improve the visibility and accessibility of these groups, making the form editor more user-friendly.
Original PR description
Before this commit, and consequently to odoo/enterprise#8489b760dd601d2a5196c8323eb0e1929c0f2132 the "groups" in the form editor were not easily visible or accessible because they lacked some padding. After this commit, we reintroduce some padding. task-6072333
This update resolves a critical issue where users could cancel documents after all signatures were collected, potentially weakening legal records. Now, the cancel button disappears automatically once signing is complete, and backend cancellations are blocked to ensure documents remain permanent and secure, protecting legal agreements.
Original PR description
Before this commit, users could cancel documents after everyone had signed. This weakened legal records and proof of agreement. After this commit, the cancel button disappears once signing is complete. We also blocked backend cancellations to keep finished documents permanent and secure. task-5980337 Forward-Port-Of: odoo/enterprise#113310 Forward-Port-Of: odoo/enterprise#109353
This update prevents regular employees from modifying target job selections within appraisals. The original issue stemmed from employees lacking the necessary permissions to view company job postings, leading to access errors. The fix restricts the 'target job' field to managers, aligning with the correct workflow and improving data integrity.
Original PR description
Steps to reproduce: 1- Create an appraisal for a regular employee 2- Confirm it so its state changes to 'ongoing' 3- Try to change the target job as an employee 4- Click on see more Cause: The main cause is that regular employees lack the privilage to view job postings by a company. therefore an access rights errors is resulted when the flow is executed. Solution: Made the field readonly for normal employees (as it should be, target jobs are the managers' responsibility to change). Forward-Port-Of: odoo/enterprise#112663
This update fixes a misleading warning in the payroll system that appeared when employee contracts overlapped slightly with payslip periods. The change ensures that a warning only appears when there's a genuine overlap, improving the user experience and preventing unnecessary alerts. This resolves an issue identified in previous versions.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update fixes a technical issue where duplicate checks were being generated during tax return creation, causing errors. The change prevents the same check code from running multiple times, ensuring smoother tax return generation processes. This improves reliability and avoids user disruption.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030
Forward-Port-Of: odoo/enterprise#113393This update adjusts Belgian payroll tax rates (FFE) to reflect the latest regulations for 2026. This ensures accurate tax calculations and compliance for Odoo Enterprise users operating in Belgium, minimizing potential financial discrepancies. The change is a technical fix to maintain accurate reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update resolves a potential memory issue that could occur when processing large payroll warning datasets. The fix limits the number of warnings displayed and optimizes the search process, preventing errors and improving performance. A visual indicator now shows when a large number of warnings are truncated.
Original PR description
Before this commit, domain-based records were searched and then eventually filtered afterwards. With or without the filter, for very large recordset fetched, it was possible to get a MemoryError. This commit introduces 2 fixes: - removes the filter after the search and replaces it by an extension to the domain - limit domain-based warnings to 1000 records and displays a '+' on the dashboard to indicate that the results were truncated task-6093607
This update resolves a memory issue that was impacting the performance of the payroll dashboard. The team optimized the data processing method, switching from a complex union operation to a simpler list appending approach. This change significantly reduces memory usage and improves dashboard responsiveness.
Original PR description
Instead of using union in _group_records_by_schedule and _group_by_warning_and_date we append in a list and browse to avoid memory errors
This update resolves a technical error that prevented label printing when validating receipts through the barcode app. The fix utilizes an optional operator to handle cases where receipt data is missing, ensuring labels can now be printed correctly.
Original PR description
Given a printer is configured to print a label for product receipts, when the receipt is validated from the barcode app, then a traceback appears. A filter on action.context.active_ids was introduced in https://github.com/odoo/enterprise/pull/106277. When validating the receipt from the purchase app, active_ids is set to the id of the purchase order and the behavior is as expected. When validating the receipt in the barcode app , it is not set (nor was it set in 17.0). The filter therefore crashes because it cannot work on undefined. An optional chaining operator is added to apply the filter only if active_ids is set. The barcode app does not raise a traceback anymore when validating a receipt and the label can be printed. Forward-Port-Of: odoo/enterprise#113146
This update fixes an issue where the mutual health warning incorrectly flagged employees with long sick leaves before 31 days. The change now accurately identifies employees who have been on sick leave for at least the past 31 days, ensuring more accurate reporting and compliance. This improves the reliability of payroll data.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
12 changes
Resolved issues and error corrections
This update resolves an issue where Odoo displayed a misleading 'This message has been removed' notification in the chatter when an approval request was canceled before a purchase order was created. The fix ensures that chatter messages are only logged when there's actual information to display, improving the user experience and clarity.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998 Forward-Port-Of: odoo/enterprise#112454
This update enhances the logging of Stripe payment rejections for expense reports. Now, the MCC code is recorded alongside the MCC name, providing more detailed information for troubleshooting and resolving payment issues. This improves our ability to understand and address problems with expense payments.
Original PR description
Before this commit: - Only the MCC name was logged when Stripe refused an MCC. After this commit: - The MCC code is now logged along with the MCC name for better clarity and debugging. task-6084569 Forward-Port-Of: odoo/enterprise#112599
This update ensures that CSV files are now correctly recognized as viewable within Odoo's list views, mirroring the behavior in the Kanban view. Previously, CSV files were only accessible through the Kanban view, creating a discrepancy in functionality. This change enhances user experience and simplifies file access.
Original PR description
Current behavior before PR: - CSV files were viewable from the Kanban view, and opened the spreadsheet conversion dialog - In list view, CSV files were not considered viewable - Same issue for trashed CSV files in list view Desired behavior after PR is merged: - Consider CSV files as viewable in list view - Align behavior with the Kanban view Task: 6052134 Forward-Port-Of: odoo/enterprise#113453 Forward-Port-Of: odoo/enterprise#112869
This update resolves a warning message that appeared when employee contracts partially overlapped with payslip periods. The fix ensures that contracts with even a single overlapping day are now processed correctly without triggering the warning. This improves the user experience and prevents unnecessary alerts.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves an issue where the 'Results Brought Forward' line on the Luxembourg balance sheet displayed incorrect values. The fix adjusts how the system calculates this line, ensuring it accurately reflects the year-end affectation process for Luxembourg companies. This improves the reliability of financial reporting.
Original PR description
… sheet Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated)…
… sheet
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/enterprise#111328This update fixes a misleading warning in the payroll system that appeared when payslips overlapped with employee contract dates. The change ensures the system correctly handles overlapping periods, preventing unnecessary warnings and improving user experience. This resolves a previous inconsistency between versions 17 and 19.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update prevents regular employees from attempting to change the target job within an appraisal. The original issue stemmed from a permissions error when employees lacked access to view company job postings. The fix restricts editing this field to managers, aligning with the intended workflow and improving data integrity.
Original PR description
Steps to reproduce: 1- Create an appraisal for a regular employee 2- Confirm it so its state changes to 'ongoing' 3- Try to change the target job as an employee 4- Click on see more Cause: The main cause is that regular employees lack the privilage to view job postings by a company. therefore an access rights errors is resulted when the flow is executed. Solution: Made the field readonly for normal employees (as it should be, target jobs are the managers' responsibility to change). Forward-Port-Of: odoo/enterprise#112663
This update resolves a visual issue where text in the payroll view would split and misalign with checkboxes when the browser window was resized. The fix ensures all text remains on a single line, maintaining a consistent and professional appearance for users. This improves the user experience and data clarity.
Original PR description
Step to reproduce: play with the width of the window, at some point text splits and item are unaligned. Cause: with some window width, the text is splitted on 2 lines, which makes it unaligned with the checkbox. Solution: force text on same line using style="white-space: nowrap". Task: 6069017 Forward-Port-Of: odoo/enterprise#113386
This update ensures that planning times displayed in the Odoo interface match the format used when generating reports. Previously, planning slots were printed in 24-hour format, creating a discrepancy. This fix standardizes the time format for a more consistent and user-friendly experience.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Planning app - Click the Print action Issue: Planning slots display in 12-hour format in the UI but print in 24-hour format. Cause: A hard-coded time format was used when printing planning slots. Fix: Remove the explicit format and rely on the locale aware short time format. task-5462276 Forward-Port-Of: odoo/enterprise#103359
This update fixes an issue where duplicate checks were being triggered during tax return generation, causing errors. The change prevents the same check code from being applied multiple times, ensuring smoother and more reliable tax return processing. This improves data integrity and reduces potential user disruption.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030
Forward-Port-Of: odoo/enterprise#113393This update corrects payroll calculations in the l10n_be_hr_payroll module to reflect the latest Federal Fiscal Employee (FFE) rates for 2026. This ensures accurate tax and social security deductions for Belgian employees, aligning with current regulations. The change is a technical fix to maintain compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update resolves a bug that prevented users from printing labels when validating receipts through the barcode app. The fix involved adding a safeguard to handle situations where the barcode app didn't have the necessary data, ensuring label printing now works correctly.
Original PR description
Given a printer is configured to print a label for product receipts, when the receipt is validated from the barcode app, then a traceback appears. A filter on action.context.active_ids was introduced in https://github.com/odoo/enterprise/pull/106277. When validating the receipt from the purchase app, active_ids is set to the id of the purchase order and the behavior is as expected. When validating the receipt in the barcode app , it is not set (nor was it set in 17.0). The filter therefore crashes because it cannot work on undefined. An optional chaining operator is added to apply the filter only if active_ids is set. The barcode app does not raise a traceback anymore when validating a receipt and the label can be printed. Forward-Port-Of: odoo/enterprise#113146
6 changes
Resolved issues and error corrections
This update fixes a misleading warning that appeared when employee contracts partially overlapped with payslip periods. The system now correctly handles overlapping contracts, preventing unnecessary alerts. This ensures smoother payroll processing and avoids potential user confusion.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves a bug that prevented price changes in the POS system when using the Blackbox module and different decimal separators (like commas) based on the user's language settings. The fix ensures accurate price updates, improving the reliability of order calculations for all users.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113151
This update fixes an issue where the system incorrectly displayed outstanding balances when settling POS dues after a refund was processed. The fix now includes refunds in the calculation, ensuring accurate due amounts are shown for customers using 'customer Account' payment methods. This improves the reliability of the POS settlement process.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113117 Forward-Port-Of: odoo/enterprise#107883
This update adjusts the FFE (Fonds voor Financiële Inlichtingen) rates used in the Belgian payroll calculations to reflect the latest figures for 2026. This ensures accurate payroll processing and compliance with Belgian tax regulations. The change is a technical fix to maintain current reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update resolves an issue where the LU reports were incorrectly showing only the first product with a missing internal reference. The change ensures all products with missing internal references are now displayed, improving data accuracy for Luxembourgian reporting. This aligns with requirements for complete and accurate financial reporting.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296 Forward-Port-Of: odoo/enterprise#113452
This update resolves an issue where invoice reports were generating incorrect debit and credit totals due to negative values in invoice line amounts. The fix ensures that debit and credit calculations are accurate by using absolute values, preventing validation errors and improving report reliability. This impacts financial reporting accuracy.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113316
11 changes
Resolved issues and error corrections
This update resolves an issue where spreadsheet pivots were crashing due to incorrect field type support. The team corrected the logic to accurately identify unsupported field types (like JSON) and added comprehensive testing to ensure stability across all field types. This enhances the reliability of the spreadsheet feature for users.
Original PR description
Spreadsheet pivots only do not support all field types. But we were relying only on `field.groupable` to determine if a field could be grouped, which is wrong (eg. JSON fields can be groupable but are not supported). It leads to crashes for fields that were groupable, but didn't have an entry in `pivotNormalizationValueRegistry`. Added a test for all of the field types to ensure we have a correct behavior. Task: 6036075 Task: [6036075](https://www.odoo.com/odoo/2328/tasks/6036075) 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#255571
This update fixes a misleading warning message displayed when an employee's contract overlaps with a payslip period. The change ensures that a warning only appears when there's a genuine overlap, improving the user experience and preventing unnecessary alerts. This resolves an issue identified in older versions of Odoo.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update fixes an issue where product names on invoices weren't always displayed in the correct language when using child contacts. The change ensures that invoice line labels are translated based on the language of the selected invoice contact, regardless of the parent contact's language. This improves accuracy and consistency for multilingual invoicing.
Original PR description
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not…
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language. ### Steps to reproduce the issue: 1. Activate at least 2 languages (X and Y) 2. Create a product and set the translation for that product in the activated languages 3. Create a Contact with the language X 4. Create a child contact (invoice adress type) for that contact with language Y 5. Create a new invoice setting the customer as the child contact 6. Add the product you created 7. See the label is displayed in the language of the parent contact ### Cause of the issue: The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language. ### Reason to introduce the fix: To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner. opw-5955875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258458 Forward-Port-Of: odoo/odoo#254833
This update resolves a recurring issue where a test related to formatting inline code would sometimes fail unexpectedly. The fix ensures the color picker is displayed before attempting to select a color, creating a more reliable test environment. This improves the overall stability of the HTML editor functionality.
Original PR description
Purpose of this PR: - Ensure color picker is rendered before selecting a color to avoid non-deterministic failures. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258566
This update resolves an issue where price changes within the Blackbox module wouldn't function correctly for users with different decimal separators (like commas). The fix ensures accurate price updates regardless of the user's locale, preventing incorrect pricing calculations. This improves the reliability of order processing for all users.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113151
This update resolves a warning appearing on Odoo.sh production branches during module updates. Previously, the update process logged unnecessary warnings about company-dependent fields, causing a yellow status. This change lowers the log level to DEBUG, aligning with existing practices and ensuring Odoo.sh branches consistently show a green, healthy status.
Original PR description
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the…
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet. But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine. Current behavior before PR: Logs may contain warnings such as: - Patching res.partner.ref with company_dependent=True - Patching product.template.sale_ok with company_dependent=True - Patching product.product.default_code with company_dependent=True even though there is no actual issue (ok normal behavior) The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine. Desired behavior after PR is merged: Keep the same mechanism, but lower the log level from WARNING to DEBUG. This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG. Having the production branches green. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258444 Forward-Port-Of: odoo/odoo#258326
This update resolves an issue where attachments from multiple employee expenses were incorrectly combined into vendor bills during the posting process. Previously, users could see duplicate attachments in their bills. This change ensures that each bill accurately reflects the attachments associated with the specific expense it's linked to, improving data accuracy and reporting.
Original PR description
Steps to reproduce: 1. Create two expenses for different employees (e.g., Expense A for Employee 1, Expense B for Employee 2). 2. Upload different attachments to each (e.g., 2 files for A, 3 files…
Steps to reproduce:
1. Create two expenses for different employees (e.g., Expense A for Employee 1, Expense B for Employee 2).
2. Upload different attachments to each (e.g., 2 files for A, 3 files for B).
3. Select both expenses and use the 'Post' action to open the posting wizard.
4. Click 'Post' in the wizard.
5. Check the generated journal entries (vendor bills).
Result: Both vendor bills contain all 5 attachments (copies of A's files and copies of B's files).
Issue:
In `_prepare_bills_vals`, `self.attachment_ids` is collected before the
`grouped('employee_id')` loop (see: https://github.com/odoo/odoo/blob/6b7fff433335edf7459f7a6eb5c274c0f4d5d1df/addons/hr_expense/models/hr_expense.py#L1572-L1578).
Since `self` refers to the full expense recordset, `self.attachment_ids` returns
the union of all attachments across every expense. This combined list is then
assigned to every bill created inside the loop, causing attachments from one
employee's expenses to leak into another employee's journal entry.
opw-6056590
Forward-Port-Of: odoo/odoo#256031This update fixes issues within the HTML editor related to blockquote functionality. Specifically, it now allows users to correctly delete content within a blockquote using Backspace, removes unnecessary line breaks after tables, and enables the creation of lists inside blockquotes. These changes improve the overall editing experience and ensure blockquotes function as intended.
Original PR description
Description of the issue this PR addresses: - Pressing Backspace inside a blockquote that has visible content but no text content removes the blockquote instead of the content. The content (image or table) gets moved outside of the blockquote. - Trailing BR was kept after tables because tables are marked as unsplittable blocks. This left unnecessary BR nodes after tables in blockquote. - Lists could not be created inside a `blockquote`. Desired behavior after PR is merged: - Backspace removes the inner content first when blockquote contains nodes. - Trailing BR is removed when placed table inside blockquote. Cursor can still be placed at the edge of the table without requiring a BR anchor. - Lists can be created directly inside a blockquote. task-5864080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258108 Forward-Port-Of: odoo/odoo#245011
This update resolves an issue where POS users needed administrator access to close sessions after a sale, specifically within the German + Fiskaly POS setup. The fix removes unnecessary security checks, allowing users with standard POS rights to close sessions without requiring elevated permissions. This improves the user experience for German customers using the POS.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960
This update fixes an issue where the event ticket download button wasn't appearing for online payments. The fix ensures that necessary data is always set, regardless of the order's status, allowing the button to display correctly and the confirmation email to be sent as expected. This improves the user experience for customers using online payment methods.
Original PR description
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and…
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and pay with the online payment method - Once on the ticket screen, the button to download the event tickets is not displayed **Why the fix:** The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration. The problem is that with an online payment method, once we enter the **read_pos_data** method that sets the values for the frontend, the order is still in draft, so we just return without doing anything. We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment. In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed. A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed. opw-5438432 Forward-Port-Of: odoo/odoo#249306
This update adjusts the FFE (Fonds voor Financiële Insolventie) rates used in the Belgian HR payroll calculations to reflect the latest figures for 2026. This ensures accurate payroll processing and compliance with Belgian tax regulations for our business users in Belgium. The change is a technical fix to maintain accurate reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
7 changes
Resolved issues and error corrections
This update corrects a misleading warning message displayed when an employee's contract overlaps with a payslip period. The change ensures that a warning only appears when a contract genuinely runs over the payslip date, improving user experience and preventing unnecessary alerts. This resolves an issue identified in older versions of Odoo Enterprise.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves a crash that occurred when users double-clicked 'Add Custom Field' within a list view's optional fields dropdown in Odoo Studio. The fix ensures Studio is properly protected from opening multiple instances, preventing the instability.
Original PR description
On a list view, open the optional fields dropdown. Click twice on "Add Custom Field" Before this commit there was a crash, because opening studio while it is already opening was not protected. After this commit, there is no crash.
This update corrects a misleading warning message displayed during payslip generation. The fix ensures that a warning only appears when a contract genuinely overlaps with the payslip period, improving user experience and preventing unnecessary alerts. This change was made to align with the behavior introduced in version 19.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update resolves an issue where the LU reports were incorrectly showing only the first product with a missing internal reference. The change ensures all products with missing internal references are now displayed to the customer, improving report accuracy and data completeness. This is part of a larger effort to fix the FAIA XML export.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296 Forward-Port-Of: odoo/enterprise#113452
This update corrects a bug in the l10n_lu_reports module that caused incorrect calculations of total debit and credit amounts in reports. The fix ensures that invoice line amounts are accurately represented, resolving validation errors and improving report accuracy. This impacts financial reporting within the Lu accounting module.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113316
This update adjusts Belgian payroll tax rates (FFE) to reflect the latest regulations for 2026. This ensures accurate tax calculations and compliance with Belgian tax laws within the Odoo Enterprise system. The change is a technical fix to maintain accurate financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update fixes an issue where appointment booking descriptions were displayed in the user's language instead of the website's language. Previously, the system used the user's language setting. Now, booking descriptions will correctly display in the website's specified language (e.g., French), ensuring a consistent user experience across different language settings.
Original PR description
When booking an appointment, the cart shows the date/time in the partner's language instead of the website's language. `_prepare_order_line_values` uses `self.partner_id.lang`, ignoring the website language and using the user's language instead. Steps to reproduce: 1. Have a website language different than the user's language 2. Go to the website appointment page 3. Book an appointment 4. Check the booking For this case: - Website language: French - User language: English => You will find, "xxx at xx:xx to yyy at yy:yy" instead of "xxx à xx:xx au yyy à yy:yy" Ticket [link](https://www.odoo.com/odoo/action-4043/5931610) opw-5931610 Forward-Port-Of: odoo/enterprise#107698
25 changes
Resolved issues and error corrections
This update resolves an issue where Odoo displayed a misleading 'This message has been removed' message in the chatter when an approval request was canceled before a purchase order was created. The fix ensures that chatter messages are only logged when there's actual information to display, improving the user experience and clarity.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998 Forward-Port-Of: odoo/enterprise#112454
This update hides provider-specific journals from the accounting dashboard, addressing a previous issue where they cluttered the view. This change simplifies the dashboard, making it easier for users to manage their financial data and improving overall usability. It's a routine improvement to the accounting interface.
Original PR description
**: platform_order, urban_piper In this commit: --- - Journals are created for each provider, which mess the accounting dashboard. - Hide these journals from the dashboard to improve visibility and usability. task-6047042
This update corrects a visual issue in the mobile dark mode of the Customer screen. Previously, secondary buttons within dropdown menus appeared as labels. This change ensures buttons consistently appear as buttons in dark mode, improving the user experience and visual consistency.
Original PR description
In mobile dark mode, the secondary button inside the dropdown menu on the Customer screen appeared as a label instead of a button due to a CSS issue. Task-5945915 Related PR-https://github.com/odoo/odoo/pull/249400 Before | After :-------------------------:|:-------------------------: <img width="393" height="549" alt="image" src="https://github.com/user-attachments/assets/0cc6c433-39c5-45fb-8365-9a526b675379" /> | <img width="385" height="552" alt="image" src="https://github.com/user-attachments/assets/a69486ff-d9b7-4f3c-ad78-6558854bfaed" />
This update enhances the logging of Stripe expense rejections by now including the MCC code alongside the name. This provides more detailed information for troubleshooting and resolving issues related to expense processing, ultimately improving the efficiency of our finance team.
Original PR description
Before this commit: - Only the MCC name was logged when Stripe refused an MCC. After this commit: - The MCC code is now logged along with the MCC name for better clarity and debugging. task-6084569 Forward-Port-Of: odoo/enterprise#112599
This update fixes a visual issue where text and checkboxes related to the mobility budget were misaligned when viewing the employee details. The fix ensures consistent formatting across different screen sizes, improving the user experience and readability of this important information. This change addresses a minor layout problem.
Original PR description
Step to reproduce: play with the width of the window, at some point text splits and item are unaligned. Cause: the text is splitted on 2 lines, which makes it unaligned with the checkbox. Solution: force text on same line using style="white-space: nowrap" and use the new o_input_box_overlay_end for units. Task: 6069017
This update corrects a misleading warning message displayed during payslip generation when contract dates partially overlapped with the payslip period. The change ensures that users can continue generating payslips even with minor overlaps, aligning with the functionality introduced in version 19. This improves user experience and avoids unnecessary alerts.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves a technical problem that was preventing our payroll performance tests from running correctly. The change ensures that time off types are properly initialized during test setup, restoring the test suite's functionality without impacting normal business operations.
Original PR description
Description of the issue this commit addresses: A constraint forbids changing requires_allocation on time off types once related leaves exist. The payroll performance test setup still toggled that field directly so the class crashes during initialization. --- Desired behavior after this commit is merged: This commit makes the performance test setup update seeded time off types in install context. The class initializes correctly again and the broken payroll test suite runs without changing normal business behavior. --- runbot-240729 Forward-Port-Of: odoo/enterprise#110821
This update allows HR administrators to designate specific leave types (like vacation or personal time) as selectable for time off reporting. Previously, certain leave types weren't visible within the holiday schedule Gantt chart, making it difficult to accurately track employee time off. This change enhances reporting and provides a more complete view of employee availability.
Original PR description
task-6089849
This update standardizes how time is recorded within Odoo Enterprise by renaming 'work entry type' and 'time off type' to 'time type'. This resolves previous inconsistencies that caused confusion and improved data accuracy for employee time tracking and payroll calculations.
Original PR description
Previously, time off types were generating hr.leave.request records while still being exposed as work entry types, leading to inconsistencies across the system. In this commit, renaming: work entry type -> time type time off type -> time type Task-5976238
This update resolves an issue where the HSBC Net file export was generating incorrect data due to a problem with binary field handling. The fix ensures the export produces accurate data, and the test case has been updated to reflect this change.
Original PR description
Following recent changes on binary fields, the hsbcnet export was writing binary data into the txt file, making the export incorrect. This fixes the issue and update the test in a way where it doesn't pass even though the export was wrong. task-6104863
This update fixes a misleading warning in the payroll system that appeared when payslips overlapped slightly with employee contract dates. The change ensures the system correctly handles overlapping periods, preventing unnecessary warnings and improving user experience. This resolves a previous inconsistency between versions 17 and 19.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update fixes a confusing error message when using system alias emails in sign requests, which previously caused the application to crash. Now, users receive a clear 'Invalid email address' message, improving the user experience and making the sign process more reliable. The change includes a new check and test to ensure proper functionality.
Original PR description
Before this commit, using a system alias email (like a catchall address) as a signer in a sign request would crash with a confusing ValidationError about an "empty partner", making it hard to understand what went wrong. The error message also had a grammar mistake ("request's").
After this commit, a clear UserError saying "Invalid email address. Please try another one." is raised instead. A check using `_find_aliases` was added and also a test to cover the fix.
task-5904159This update ensures that account moves are automatically created when closing a POS session containing Urban Piper future orders (orders with a delivery date). Previously, these orders were excluded, preventing proper accounting record generation. This change improves financial reporting accuracy for orders processed through the Urban Piper integration.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#113092 Forward-Port-Of: odoo/enterprise#111137
This update fixes a potential issue in the account reports module's testing process. By using Python objects instead of string IDs in assertions, the tests are now more reliable and less prone to errors when comparing data. This ensures the accuracy of financial reporting.
Original PR description
Steps to reproduce: - create a test using the assertLinesValues using two lines having the same id. Forward-Port-Of: odoo/enterprise#112569
This update fixes a problem where invoices sent to the Colombian DIAN tax authority would incorrectly be marked as duplicates and rejected. The fix prevents a rollback process from triggering when the DIAN GetStatus endpoint fails, ensuring invoices are correctly accepted by DIAN and preventing duplicate submissions.
Original PR description
Steps to reproduce:
- Send a Colombian DIAN invoice (SendBillSync flow)
- Simulate a non-200 response from the DIAN GetStatus endpoint during the call of _get_attached_document (see ticket)
Issue:
The invoice is accepted by DIAN but the state is never written. When trying to send the invoice a second time DIAN rejects the invoice as a duplicate (already submitted).
Cause:
`_get_response_history` returns `("", error_msg)` on non-200 status_code and when calling `_get_attached_document`
-> error and rollback and `invoice_accepted` is not written correctly
opw-5919395
Forward-Port-Of: odoo/enterprise#111349
Forward-Port-Of: odoo/enterprise#111186This update resolves an issue where the 'Results Brought Forward' line on the Luxembourg balance sheet displayed incorrect values. The fix adjusts how the system calculates this line to accurately reflect year-end adjustments related to profit and loss, ensuring financial reporting accuracy for Luxembourg companies.
Original PR description
… sheet Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated)…
… sheet
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/enterprise#111328This update fixes an issue where Odoo incorrectly consumed stock from the wrong location when scanning serial numbers on Manufacturing Orders. The fix ensures the correct warehouse location is used, preventing stock discrepancies and improving order fulfillment accuracy. This resolves a potential error impacting inventory management.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474 Forward-Port-Of: odoo/enterprise#113442 Forward-Port-Of: odoo/enterprise#112691
This update corrects a bug where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). The fix disables a feature that allowed this, ensuring compliance and preventing inaccurate reporting. This resolves an issue impacting Mexican businesses using Odoo Enterprise.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109561 Forward-Port-Of: odoo/enterprise#104628
This update simplifies the synchronization wizard by reducing overwhelming error messages for users. Instead of detailed error lists, the wizard now provides a summary count of problematic databases. Error details are now logged in a separate location for technical review, minimizing user alarm and improving the overall workflow.
Original PR description
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors,…
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors, the wizard now displays a single summary message indicating the number of databases that encountered an issue. A new Unreachable project tag is introduced (loaded from project_tags.xml if missing). It is automatically assigned to failing databases and removed upon the next successful synchronization. Detailed error information is no longer shown in the wizard and is instead logged in the chatter of the corresponding database settings for further inspection. Previously displayed non-blocking warnings for already-configured SaaS databases are now omitted to reduce noise, as they would otherwise generate chatter messages at each synchronization. Task-id: [5945269](https://www.odoo.com/odoo/project.task/5945269) Forward-Port-Of: odoo/enterprise#113617 Forward-Port-Of: odoo/enterprise#107975
This update fixes an issue where duplicate checks were being triggered during tax return generation, leading to error messages. The change ensures that only one 'draft entries' check is run, streamlining the return generation process and preventing unnecessary errors. This improves the reliability of tax reporting.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030
Forward-Port-Of: odoo/enterprise#113393This update resolves an issue where upgrading to a newer version of Odoo would fail if a previously deleted company folder was still referenced. The fix ensures that inactive folders are properly handled during the upgrade process, preventing errors and maintaining data integrity.
Original PR description
While embedding sign into predefined folders we need to consider if they are active or not. Otherwise during…
While embedding sign into predefined folders we need to consider if they are active or not. Otherwise during [upgrade](https://github.com/odoo/upgrade/blob/master/migrations/documents_sign/saas%7E19.2.1.0/post-migrate.py) to `saas~19.2` with module `documents_sign` installed, it will try to get document actions of predefined folder [here](https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1592), so if the folder is inactive it will not be able to read the folder [here](https://github.com/odoo/enterprise/blob/6d334a17d10faec33d60f4a8d7d263c091bb456e/documents/models/documents_document.py#L1494).
Steps to reproduce:
1/ Install `documents_sign` in 19.0
2/ Delete the folder `Legal` (documents.document_legal_folder)
3/ Upgrade to `saas~19.2`
As result we will get traceback similar to this:
```
2026-03-19 16:17:50,553 4059246 INFO test_documents_sign odoo.modules.migration: module documents_sign: Running migration [saas~19.2.1.0>] post-migrate
2026-03-19 16:17:50,593 4059246 WARNING test_documents_sign odoo.modules.loading: Transient module states were reset
2026-03-19 16:17:50,594 4059246 ERROR test_documents_sign odoo.registry: Failed to load registry
2026-03-19 16:17:50,594 4059246 CRITICAL test_documents_sign odoo.service.server: Failed to initialize database `test_documents_sign`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1598, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
load_modules(
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 465, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 231, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/upgrade/migrations/documents_sign/saas~19.2.1.0/post-migrate.py", line 7, in migrate
_post_init_hook(util.env(cr))
File "/home/odoo/src/enterprise/saas-19.2/documents_sign/__init__.py", line 40, in _post_init_hook
folders_to_process._embed_action(sign_action.id)
File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1621, in _embed_action
folder.action_folder_embed_action(folder.id, action_id)
File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1592, in action_folder_embed_action
return self.get_documents_actions(folder_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/documents/models/documents_document.py", line 1496, in get_documents_actions
raise UserError(_('This folder does not exist or is not accessible.'))
odoo.exceptions.UserError: This folder does not exist or is not accessible.
```
For fixing the issue we skip inactive folders.
tbg-2508
Forward-Port-Of: odoo/enterprise#111339This update fixes a potential issue where work entry types were incorrectly selected across different countries, leading to inaccurate payroll calculations and leave allocations. The changes enforce country-specific work entry types based on the company and employee context, ensuring accurate and reliable payroll processing across all localized versions of Odoo.
Original PR description
Forward-Port-Of: odoo/enterprise#113290
This update fixes a visual inconsistency in the Odoo Enterprise subscription interface. Specifically, the 'Recurring Plan' and 'Until' display labels are now aligned and share the same width for a cleaner and more user-friendly experience. This improves readability and overall presentation.
Original PR description
Go to Subscription and open a subscription. => "Recurring Plan" & "Until" should share the width and be on the same line. task-6033618
This update fixes an issue where the amount for Danish balance sheet reports wasn't displayed correctly when certain report settings were enabled. The update simplifies report generation to use account sublines, ensuring accurate reporting and aligns with Danish accounting practices. It also includes updated Danish translations.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113285 Forward-Port-Of: odoo/enterprise#112430
This update enhances the user experience within the Odoo form editor by adding padding to the grouping of fields. Previously, these groups were difficult to see and access. This change improves clarity and usability for users creating and editing forms.
Original PR description
Before this commit, and consequently to odoo/enterprise#8489b760dd601d2a5196c8323eb0e1929c0f2132 the "groups" in the form editor were not easily visible or accessible because they lacked some padding. After this commit, we reintroduce some padding. task-6072333 Forward-Port-Of: odoo/enterprise#112439
7 changes
Resolved issues and error corrections
This update fixes a misleading warning displayed during payslip generation when contracts partially overlapped with pay periods. The system now correctly handles overlapping contracts, ensuring users can generate payslips without unnecessary alerts. This improves the user experience and avoids potential confusion.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update corrects a reporting issue in the Rental app where pickup/return quantities were incorrectly duplicated and the report displayed the wrong start date. The fix addresses a problem with how the database handles timezones and ensures accurate reporting of rental activity. This improves the reliability of rental data analysis.
Original PR description
Steps to reproduce: 1- Install Rental app and create a rental product. 2- Create a Rental Order for that product from Feb 27, 12:00 AM to Feb 28, 11:30 PM. 3- Confirm the order and deliver the…
Steps to reproduce: 1- Install Rental app and create a rental product. 2- Create a Rental Order for that product from Feb 27, 12:00 AM to Feb 28, 11:30 PM. 3- Confirm the order and deliver the quantity. 4- Open the [Rental -> Reporting -> Rental Analysis] Pivot view. 5- Set the measures to "Picked up Quantity" and group by "Date: Day". Description of issue: Two issues occur: 1- The "Picked up Quantity" is duplicated and shown on every single day of the rental period. The same happens for the "Returned Quantity" which is shown on every row. 2- The report shows the start date on the previous day (Feb 26). Expected behavior: 1- The Picked up/Returned Quantity should only appear on the day the pickup/return actually occurred. 2- The start date should be on the same day (Feb 27). Why this happens? 1- The SQL view uses generate_series to expand the rental duration into individual days. The original query was pulling the qty_delivered/qty_returned into every resulting row without a conditional check. 2- Datetime fields are stored in UTC format in the database, and the SQL view was performing a date cast directly on the UTC field without converting to the local timezone. opw-5501263
A recent update to the Document module caused a problem where the server action view within the Odoo interface was broken, preventing users from accessing key features. This was due to an incorrect priority setting for the view, leading to the wrong view being displayed. This fix ensures the server action view functions correctly after the Document module is installed.
Original PR description
When the document module is installed, sometimes the server action view that is shown when accessing the server actions from the normal menu can be broken: the model field for instance is no longer visible, which makes the user interface unusable. <img width="723" height="412" alt="image" src="https://github.com/user-attachments/assets/73f6d516-77be-4f66-80dc-033fd8c0cb7c" /> This is because the document module defines a new primary form view for server actions, but does not set a priority for that view. As a result we have 2 primary views, with the same default priority of 16 in the database, and in that case the sorting of view can lead to the document specific view to be selected, when the other one is expected. We fix this by explicitly setting a priority of 32 on the form view in the document module.
This update resolves a critical issue causing crashes and slow performance when generating the VAT Books Excel report for large invoices. By optimizing memory usage and query execution, the report now runs reliably and efficiently, even with extensive data, significantly improving user experience.
Original PR description
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance…
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process. ### Current behavior before PR: When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes. ### Desired behavior after PR is merged: The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically: - The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration. - The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries. ### Benchmark: The model is iterating through ~1.1M journal items when generating the full report. For Memory: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 1.4GB| 202 MB | | ~32,000 journal items | MemoryError | 278 MB | | ~141,500 journal items | MemoryError | 760 MB | | ~1.1M journal items | MemoryError | 1.4 GB | For Speed: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 2 min | 1.5s | | ~32,000 journal items | MemoryError | 4s | | ~141,500 journal items | MemoryError | 12s | | ~1.1M journal items | MemoryError | 56s | ### Reference opw-6037414 ----------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves an issue where price changes within the Blackbox module were failing due to incorrect decimal separator handling in different user language settings. The fix ensures that price updates are now consistently applied regardless of the user's locale, improving the reliability of order pricing.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113151
This update fixes a misleading warning in the payroll system related to contract dates and payslip periods. Previously, a warning appeared even with a slight overlap between the contract and payslip. Now, the system correctly handles overlaps, eliminating the unnecessary warning and improving user experience. This ensures accurate payroll processing.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update corrects a technical issue in the web_studio report editor where unwanted placeholders were automatically inserted between layout sections. This prevented reports from printing correctly, and the fix ensures that report sections are properly formatted for printing. The change addresses a bug related to how Odoo prepares reports for output.
Original PR description
… sections Before this commit, the html_editor automatically put placeholders between hearder, article and footer nodes (identified with classes) This is caused by odoo/odoo@edf7f7bb0c62978640c181eccb4934855d5d872d. This caused issues because at print time those cracks are not printed because of base/ir_actions_report.py:def _prepare_html (which separates header, footer, and articles to pass them to wkhtmltopdf) After this commit, those placeholders are not present in those cracks. opw-6048955
11 changes
Resolved issues and error corrections
This update fixes an issue where draft journal entries in the payroll accounting module were incorrectly using the end of the month instead of the payslip pay period date. This ensures accurate accounting records and proper financial reporting for employee payroll.
Original PR description
Steps to Reproduce: - install payroll accounting module - create or update existing employee contract - change schedule pay to semi-monthly - create a payslip and validate it. - create draft entry and open the journal entry Issue: - The accounting date of the draft entry is the last date of the month. - It should be the end date of payslip pay period. Reason: - While creating draft entry it takes the last date of the month instead of the end date of the payslip Solution: - assign end date of payslip pay period instead of last date of the month task-5419465 Forward-Port-Of: odoo/enterprise#104909
This update resolves an issue where document sorting in the Documents app wasn't honoring the 'Sort by Name' setting configured within Odoo Studio. The fix removes a technical override that was causing documents to default to creation date sorting. Now, users can accurately set and maintain document sorting preferences through Studio.
Original PR description
Steps To Reproduce ------------------ 1- Navigate to the Documents app. 2- Open Studio and enter customization mode. 3- Set the "Sort by" field to "Name" in the Kanban or List view. 4- Save and close Studio. Issue ----- The documents remain sorted by creation date instead of alphabetically by name. The Studio "Sort by" configuration is ignored. Cause ----- https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/documents/static/src/views/search/documents_search_model.js#L329-L331 This forces a fallback sort of create_date desc when super.orderBy is empty. This overrides the view's default_order attribute set by Studio. Solution -------- Remove the forced create_date desc fallback. Update the model's _order from 'id desc' to 'create_date desc, id desc' to preserve existing default behavior. This allows Studio's default_order customization to take precedence while keeping the default sorting logic in one place. opw-5382403
This update fixes a misleading warning that appeared when employee contracts partially overlapped with payslip periods. The change ensures that contracts with even a single overlapping day are now processed without the warning, improving user experience. This resolves a potential source of confusion and allows for more flexible contract scheduling.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update addresses a critical issue where Odoo would crash when attempting to download a URL document alongside a spreadsheet. The fix ensures stable and reliable downloading of both document types, improving user workflow and preventing data loss. This resolves a reported instability impacting users accessing and sharing documents.
Original PR description
Try to download a url document along with a spreadsheet. `onDownload` crash when trying to download a url document. Task: 5485662 Forward-Port-Of: odoo/enterprise#112513
This update corrects a display issue where quotation dates weren't updating in the list view. The fix ensures that when a user changes the order date, the list view accurately reflects the new date, improving data accuracy and reporting.
Original PR description
Steps: - Install sale, sign and studio - Sales > Quotations - Add Order date(`date_order`) field in the list view using studio(use debug mode) - Select the widget `datetime_no_seconds` for `date_order` field from the studio left panel Issue: - Even after updating `date_order`, the Quotations list view continues to display the creation date for all quotations. Cause: - The formatting logic always defaults to the creation date when rendering `date_order`. - This happens because the date formatting function ignores incoming updated value and falls back to the creation date by default. Fix: - Update the code to accept the incoming `date_order` value when provided. - This ensures that when a user updates the date, the list view now correctly reflects the updated value. opw-5043343
This update corrects a technical issue related to date formatting on rental listings within the Enterprise version of Odoo. Previously, dates were displayed with an incorrect timezone, which has now been resolved to ensure accurate display for users. This ensures consistent and reliable rental information.
Original PR description
should be converted from website tz as they're going to be converted back by the front-end to that specific timezone. Runbot issue: 234756
This update corrects payroll calculations in the Belgian HR module to reflect the latest Federal Fiscal Exemptions (FFE) rates for 2026. This ensures accurate tax and social security deductions are processed for employees in Belgium, aligning with current regulations. The change is a technical fix to maintain compliance.
This update fixes a limitation in Odoo Studio where activity filters weren't consistently available when the 'use_mail' option was enabled. The change adds necessary filters for overdue, today, and upcoming activities, ensuring users can effectively manage and filter records based on their activity status within Studio.
Original PR description
Steps to reproduce
==================
- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future
Cause of the issue
==================
https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77
For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present
Solution
========
We add them to the search view. They are all pretty much implemented the same way in every model.
opw-6069150This update fixes a misleading warning message displayed during payslip generation. The change ensures that a warning only appears when a contract overlaps with the payslip period, aligning with the behavior in version 19. This improves the user experience and prevents unnecessary alerts.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#112758This update resolves an issue where the LU financial reports were incorrectly showing only the first product ID when multiple products lacked a required internal reference. The fix now displays all products with missing internal references, ensuring accurate reporting for Luxembourg businesses. This aligns with reporting requirements and improves data accuracy.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296 Forward-Port-Of: odoo/enterprise#113452
This update resolves a technical issue in the Lu reporting module that caused incorrect debit and credit calculations in XML exports. By ensuring amounts are always positive, the system now accurately reflects financial data, preventing reporting errors and improving data integrity. This change is part of a larger effort to improve FAIA XML export functionality.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113316
2 changes
Resolved issues and error corrections
This update fixes an issue where the Luxembourg annual VAT declaration XML reports incorrectly included zero-valued fields. The change ensures the reports strictly adhere to Luxembourg tax authority specifications, improving compliance and preventing the generation of unnecessary XML elements. This ensures accurate VAT reporting.
Original PR description
### Issue before this commit: The XML generation for the Luxembourg annual VAT declaration included several fields with a value of 0,00 even when these fields were not mandatory according to the…
### Issue before this commit: The XML generation for the Luxembourg annual VAT declaration included several fields with a value of 0,00 even when these fields were not mandatory according to the official eCDF specification. As a result, the generated XML contained unnecessary elements that should only appear when the related fields are filled or when specific dependency conditions are met. This behavior produced XML declarations that did not strictly follow the expected rules of the Luxembourg tax authority specification. ### Steps to reproduce the issue: 1. Download Accounting and l10n_lu apps 2. Switch to LU company 3. Go to Accounting > Reporting > Tax Report 4. Set Report parameter as "Annual VAT Declaration (LU)" 5. Wheel button next to title "Tax Report" > XML 6. Fields 129, 137, 145, 163, 175 should not be there if setted to zero ### Cause of the issue: The issue was caused by the logic used during XML generation, which kept certain fields in the declaration even when their value was zero. These fields were included because they were listed among mandatory fields or because the filtering logic did not fully reflect the conditional requirements defined in the eCDF rules. Consequently, fields that should only appear when related fields are filled or when dependency conditions are satisfied were still exported with a zero value. ### Reason to introduce the fix: This fix ensures that only the fields required by the eCDF specification are included in the generated XML declaration. Non-mandatory fields with a zero value are now properly excluded unless they are explicitly required by dependency rules. This improves compliance with the Luxembourg tax declaration format and prevents the generation of unnecessary or invalid fields in the XML output. ### Fix details: While addressing this issue, several elements previously introduced by PR https://github.com/odoo/enterprise/pull/105143 and https://github.com/odoo/enterprise/pull/91938 had to be modified still maintaining their fixes. The implementation follows the rules described in the official documentation: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/TVA_DECA_TYPE/2020/en/1/rules The main purpose of this change is to first compute (if that is possible) and then validate the logic of the VAT declaration fields in a structured and maintainable way. To achieve this, a large dictionary (YEARLY_VAT_RULES) was introduced to describe the relationships and validation rules between all fields appearing in the declaration. Each entry of the dictionary corresponds to a field of the declaration (identified by its numeric ID) and defines how its value should be validated or computed. For each field, the structure specifies: - relation_type: indicates if the field belongs to a circular dependency group or to a parent-child relation - group: lists the fields that are part of the same dependency group. - rules: describes how the field value should be derived or validated. opw-5925322
This update resolves an issue where the checkout process became unresponsive when using Avatax with CPF identification. The previous code unnecessarily called external tax APIs, leading to errors that disrupted the checkout flow. This fix removes the unnecessary API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767