Daily updates from Odoo
Friday, December 5, 2025
29 changes · master
Resolved issues and error corrections
This update fixes an issue where the payroll system was incorrectly referencing employee version records instead of the main employee records. This change ensures accurate calculations and reporting related to employee compensation, particularly in Switzerland. The fix was triggered by a recent update to the Odoo Enterprise system.
Original PR description
Commit [46052c4](https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8) introduced the `hr.version` model, which contains historical information about an employee record. Some of the updated lines use the hr.version ID when they should use `hr.employee`. Ticket [5218215](https://www.odoo.com/odoo/project.task/5218215) Forward-Port-Of: odoo/enterprise#100079
This update resolves an issue where duplicating multiple repair orders would cause errors. The fix ensures the system correctly handles multiple records during duplication, allowing users to efficiently copy repair orders without encountering technical problems. This improves the reliability of a key business process.
Original PR description
## Current behaviour: Duplicating multiple repair orders raises an error due to direct access to record fields without iterating on each record. ## Expected behaviour: Duplicating multiple repair orders should work without errors. ## Steps to reproduce: 1. Open runbot. 2. Select multiple repair orders. 3. Click "Duplicate". 4. System raises an error. ## Cause of the issue: The create/write methods assume a single record and fail when multiple records are processed at once. ## Caused by: https://github.com/odoo/enterprise/commit/16e1a97d85fc8227c73ce4a1507ab92ab7ed8486 The commit introduced logic that accesses values directly without looping over each record. ## Fix: Loop over records in create and write to handle multi-record operations. opw-5382657 Forward-Port-Of: odoo/enterprise#101184
This update fixes an issue where the 'Journal Items' link in the General Ledger report incorrectly displayed items not associated with the selected account group. The fix ensures that users see the correct journal items linked to their account groups, improving report accuracy and data reliability.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update fixes an issue where debit notes created in Uruguay were incorrectly assigned as e-invoices (type 111). The fix ensures debit notes automatically use the correct document type (113), streamlining invoice processing for Uruguayan customers. This improves data accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type =…
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**. * From the invoice's gear icon, create a **Debit Note**. **Observed behavior:** * The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**. * Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111. **Cause:** * `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification. * This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type. * The override prevents the correct selection (internal_type == *debit_note*) from being applied. **Fix:** * Add a condition in the automatic e-Invoice assignment logic. * Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**. opw-5154599 Forward-Port-Of: odoo/enterprise#100938
This update fixes a problem where annotations in PDF exports of Balance Sheet reports were not displayed in chronological order. Now, the oldest annotations will appear first, ensuring a more accurate and understandable report. This improves the clarity and reliability of financial reporting.
Original PR description
We expect the oldest annotations to appear first when exporting to a PDF.
To reproduce:
- Go to any report such as the Balance Sheet
- Open the chatter for an account
- Post 2 messages ("first" and "second" for exemple)
- Export the report to PDF
This was introduced in https://github.com/odoo/enterprise/pull/95307
Forward-Port-Of: odoo/enterprise#100475This update resolves a test failure that occurred when the demo data was used. The fix ensures the test no longer interferes with the demo environment, preventing disruptions and maintaining the accuracy of the demo setup. This improves the reliability of the demo for testing and demonstration purposes.
Original PR description
Some tests were failing when the demo data were installed. This commit fixes the test so that it doesn't interfere with demo data. Related build error: https://runbot.odoo.com/odoo/runbot.build.error/234529 task-5386529 Forward-Port-Of: odoo/enterprise#101301
This update resolves an issue where the automatic transfer account rule was creating duplicate and incorrect rules, leading to inaccurate account assignments. The fix simplifies the rule creation process by removing redundant mechanisms, ensuring data integrity and a more reliable transfer process.
Original PR description
## Steps to reproduce: 1. Create a new transfer record 2. Add more than one account to the Accounts field or add a rule with condition on Account or remove account from an Account condition with multiple accounts set ... (various other actions when adding/removing accounts) ## Before: Redundant and incorrect rules are created and an incorrect value is assigned for account_ids due to the faulty sync between the two. ## After: Removing the onchange mechanism that creates the rule with condition on Account whenever an account is added to the Accounts field, this information is redundant for the user. Also removing the onchange mechanism of the reverse (adding accounts to the Accounts field when a rule with condition on Account is added) as it cannot account for nested rules and any/all conditions. opw - 5160635 Forward-Port-Of: odoo/enterprise#100054
This update resolves an issue where bank statement creation would fail when the Chart of Accounts wasn't properly configured. The fix ensures the system only attempts to match accounts when valid accounts are present, preventing a syntax error and improving the reliability of bank statement processing.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053 Forward-Port-Of: odoo/enterprise#100931 Forward-Port-Of: odoo/enterprise#100459
This update corrects a visual issue where the activity badge within the bank reconciliation widget was misaligned. The fix removes a styling class that was causing the misalignment, ensuring the badge now appears correctly positioned on the icon. This improves the user experience and visual consistency of the bank reconciliation feature.
Original PR description
Current behavior before PR: The activity badge inside the bank reconciliation widget was misaligned, <img width="55" height="60" alt="image" src="https://github.com/user-attachments/assets/0f99ea55-fedd-401a-a65e-226296070e32" /> Desired behavior after PR is merged: The activity badge now sits in the correct position on the icon. <img width="62" height="55" alt="image" src="https://github.com/user-attachments/assets/abf96aed-73d4-4153-8e0a-56937d4ff08a" /> Changes implemented: - Removed `fa-fw` class. - Removed the unnecessary 'fa-fw' class from comment and paperclip icon. task-5354994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#100573
This update fixes an issue where the Christmas Bonus payslip incorrectly used a standard periodicity. The change ensures the payslip's periodicity is set to '99' (other periodicity) when the bonus is classified as extraordinary, accurately reflecting Mexican payroll regulations. This ensures correct reporting and payment processing for this specific bonus type.
Original PR description
For the Christmas Bonus, the 'periodicidad_pago', the periodicity of the payslip, should be 99, i.e. other periodicity. Right now, it takes the periodicity from the version which is not correct. Fix: when the structure is of payroll type extraordinary, put 99 in the 'periodicidad_pago'. Task: 5344050 Forward-Port-Of: odoo/enterprise#100271
This update resolves a critical error that prevented the generation of payroll export files. The fix corrects a naming mismatch in the code, ensuring accurate retrieval of employee data. A new test suite has been added to guarantee the reliability of the export process and validate data integrity.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#101137 Forward-Port-Of: odoo/enterprise#96743
This update resolves an issue where the timesheet grid incorrectly displayed unavailable days when flexible hours were enabled for a company. The fix ensures that all days are treated as working days when flexible hours are in use, providing accurate timesheet availability. This improves the usability of the timesheet feature for companies utilizing flexible work schedules.
Original PR description
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days…
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent. **Steps to reproduce** 1. Enable flexible hours on company's working schedule 2. Go to Timesheets > All timesheets 3. Switch to Grid view and filter by month 4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out **Fix** The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days. This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths: 1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback 2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found This follows the same pattern as the gantt view fix #100385 opw-5215646 Forward-Port-Of: odoo/enterprise#100881
This update resolves an issue where the ChatGPT plugin button was disabled when no text selection was made in the HTML editor. Now, the button consistently enables the ChatGPT window, regardless of whether a selection is present, ensuring users can always access the AI features.
Original PR description
This PR fixes an issue with the toolbar button. Before when no selection were applied in the HTML Editor, the button would be disabled. This PR introduce a fix that makes the button enabled in two scenarios: - Either the user has no selection, clicking the button will then open the chat window without any AI button, as it does with the powerbox buttons, - Or the user has a selection, then clicking the button will result in opening the chat window with the AI buttons as it was already the case. If the user has a selection that is empty, then the button remains visible but is disabled. Forward-Port-Of: odoo/enterprise#101332
This update corrects a technical error in how Odoo processes webhook events related to virtual expense cards. Specifically, it addresses a situation where 'None' shipping values were incorrectly treated as dictionaries, preventing proper expense tracking. This fix ensures accurate expense reporting data.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict Forward-Port-Of: odoo/enterprise#100703
This update fixes a technical issue that caused duplicate journal entries (reversals and deferrals) to be created, leading to confusing accounting reports. The change ensures that deferred entries are calculated correctly, particularly when invoice dates fall within the same month, resulting in cleaner and more reliable financial records.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update prevents Odoo from endlessly checking the status of NFS-e invoices if the city hall hasn't responded after 10 days. This reduces unnecessary user credit consumption and ensures a smoother process for users. The system now automatically flags invoices that haven't been processed, notifying the user.
Original PR description
Previously, when an NFS-e was submitted to the city hall, a cron job was continuously checking its status. However, if the city hall never responded, the system kept checking indefinitely, leading to unnecessary consumption of user credits. To address this, a limit has now been introduced on these cron checks. If more than 10 days have passed since the invoice was submitted, the invoice is moved to an error status (thereby excluding it from further cron checks), and a log note is posted informing the user. **task**-4776548
This update resolves a skipped test related to map view links within the documents_spreadsheet module. The fix involves adding the `web_enterprise` module as a dependency, ensuring the test now runs correctly and accurately validates the functionality. This improves the reliability of our testing process.
Original PR description
Map view link test was skipped because it depended on `web_enterprise` module, which is not a dependency of `documents_spreadsheet` module. To fix this, we move this test to `test_spreadsheet_edition` module, with `documents_spreadsheet` and `web_enterprise` as new dependencies.
This update fixes an issue where report start dates were incorrectly calculated based on the current date, leading to inconsistent results. The fix ensures accurate start dates for returns, regardless of the current date or custom fiscal year settings. This improves the reliability of financial reporting across Odoo's localized versions.
Original PR description
compute_fiscalyear_dates using date.today() is wrong and can lead to different start_dates depending the current date. For instance if we create a custom fiscal_year from sept 2025 to Dec 2025 and we are currently the 10th Sept 2025. Then, we try to generate a return for January. The start date would be set to the 1st Sept. Then later, when trying to generate the same return for January 2025 but being after that custom fiscal year (for instance 20th January 2026), We get a completely different start date. The fix is to avoid using the custom fiscal years in get_start_date_elements. An improvement will be done in master to add that feature. We can also safely remove the custom start_date from the belgian localization as now it is not used anymore. See: https://github.com/odoo/enterprise/pull/100034 Forward-Port-Of: odoo/enterprise#101261 Forward-Port-Of: odoo/enterprise#100022
This update corrects an issue causing VAT return XML files to be rejected by the Belgian government. The fix removes incorrect grid numbers ('46L' and '46T') from the generated XML, ensuring compliance with tax regulations. This prevents delays in VAT filing.
Original PR description
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date:…
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date: [last month] * Fiscal Position: [Intra-Community] * Invoice Lines: [a product with "0% EU M" tax] - Confirm the invoice - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the period containing the created invoice - Mark all lines as "Reviewed" - Validate the VAT Return **Issue:** In the generated XML, there is a line for grid number "46L", which should not appear. Therefore, the XML is rejected by the government. Same issue with grid number "46T". These 2 grids are sub-section of grid number "46" and should not appear in the XML. Cause: Previously, they were filtered out, but since this commit https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the formula has changed from "46L" to "-46L" but the excluding filter has not been updated. opw-5344566 Forward-Port-Of: odoo/enterprise#101353
This update resolves an issue where a loading banner remained persistently displayed after switching between report variants. The fix ensures the banner is only shown when data is actively being loaded, preventing it from sticking around unnecessarily. This improves the user experience by eliminating unnecessary visual clutter.
Original PR description
As the `_get_report_information` isn't called when variant changes as report info is already in `reportInformationMap`, the `asyncDataLoading` is set to true and rpc callback never executes, leading to persistence of the warning banner. Fixing this by only setting `asyncDataLoading` right before the rpc call `_get_report_information`. Steps to reproduce: - open Balance Sheet (US) - go to BS generic variant - go back to BS (US) variant - The banner is shown without ever being deleted
This update corrects a technical issue within the account invoice extraction module. The previous method of retrieving data has been replaced with a more modern approach using `get_bool` and related functions. This ensures the system continues to function correctly and aligns with current Odoo standards.
Original PR description
`get_param` doesn't exist anymore, it was replaced by `get_bool`, `get_str`, etc. task-none
This update prevents users from manually closing invoices for subscription orders. Because these subscriptions automatically generate recurring invoices, closing them would disrupt the ongoing billing process. This change ensures accurate and consistent subscription billing.
Original PR description
Subscription orders with recurring plans cannot have their invoicing manually closed, as they require ongoing invoicing cycles.
This commit adds validation to the `action_close_invoicing` method to raise a user-friendly error when attempting to close invoicing for subscription orders.
task-5027819
- SEE ALSO:
Community PR : https://github.com/odoo/odoo/pull/228008This update corrects a bug where vehicles marked for change (but with a 'no change' flag) were incorrectly shown as available. The fix ensures that vehicles slated for change are accurately identified as unavailable, improving the accuracy of vehicle availability reports. This resolves an issue impacting fleet management reporting.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#101351 Forward-Port-Of: odoo/enterprise#90812
This update resolves an issue where users were unexpectedly redirected back into the sign flow after completing a document signature. The fix ensures users return directly to the correct record (like an Offer or Invoice) without lingering 'Sign' breadcrumbs. This improves the user experience and prevents navigation confusion.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992
Forward-Port-Of: odoo/enterprise#99525This update resolves a problem where the departure holiday attest form in the Belgian payroll module was not functioning correctly. The fix ensures accurate calculation and reporting of departure holiday entitlements, improving payroll accuracy and compliance. This change impacts the HR and Payroll processes within the Odoo Enterprise system.
Original PR description
Forward-Port-Of: odoo/enterprise#101314
This update clarifies the ESIC contribution rules within the payroll system. The tooltip now specifies that employee and employer contributions are calculated only for gross wages below ₹21,000. This ensures accurate reporting and compliance with ESIC regulations.
Original PR description
We are updating the field tooltip. Before: - l10n_in_esic_employee_amount: Employee contributions towards ESIC(Employees’ State Insurance Corporation) are calculated based on their gross wages. - l10n_in_esic_employer_amount: Employer contributions towards ESIC (Employees’ State Insurance Corporation) are calculated based on the employee’s gross wages. After: - l10n_in_esic_employee_amount: Employee contributions apply when the gross wage is below ₹21,000 - l10n_in_esic_employer_amount: Employer contributions apply when the gross wage is below ₹21,000 Task: 5383839 Forward-Port-Of: odoo/enterprise#101198
This update resolves an issue where invalid PDF tests were failing due to compatibility problems with different versions of the PyPDF2 library. The fix standardizes error handling, ensuring tests consistently pass regardless of the PyPDF2 version used, improving the reliability of the sign document process.
Original PR description
## Case 1: When `pypdf2_2` is not installed, it falls back to using the pypdf package. (Ref1) This triggers a warning during the test case when it tries to parse an invalid PDF. This commit…
## Case 1: When `pypdf2_2` is not installed, it falls back to using the pypdf package. (Ref1) This triggers a warning during the test case when it tries to parse an invalid PDF. This commit suppresses the warning to ensure the test runs without warnings. Ref1: https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/odoo/tools/pdf/__init__.py#L42-L46 ## Case 2: With **PyPDF2===1.26.0**, the line at [1] raises a `PyPDF2.utils.PdfReadError: EOF marker not found`. This exception is not handled by the same except block but is instead handled later in the flow at [2]. As a result, the test raises a **UserError**, causing the assertion to fail. On the other hand, when `pypdf2_2` or `pypdf` is installed, the _PdfFileReader_ raises a **UnicodeDecodeError**, which is then handled as a **ValidationError**, allowing the test to pass as expected. This commit adds handling for **PdfReadError** in method `get_valid_pdf_data()` to unify the behavior across all supported PyPDF versions. 1: https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/sign/utils/pdf_handling.py#L27 2: https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/sign/models/sign_document.py#L433-L437 Runbot-234021, 234022 Forward-Port-Of: odoo/enterprise#99757
This update fixes an issue where PDF payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. Now, payslips will correctly display 'Salary Slip - [Employee Name] - [Time Period]', ensuring accurate and professional payroll documentation. This improves the user experience and consistency of our payroll reports.
Original PR description
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip…
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Go to Payroll and click on the Payslips tab > payslips. 2. Click on Pay Run. Select Regular Pay and click Continue. 3. Select an employee for which you'd like to generate the payslip. 4. Click on the employee row in the list view. 5. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5216796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#101259 Forward-Port-Of: odoo/enterprise#101056
This update prevents users from modifying existing approval requests. Allowing edits would have caused unpredictable behavior and potential errors within the system. This change ensures the integrity and reliability of the approval process.
Original PR description
There is no legitimate use case that should modify the approval request. This would result in unexpected behaviour. task-5269982 Forward-Port-Of: odoo/enterprise#101328 Forward-Port-Of: odoo/enterprise#100273