Daily updates from Odoo
Friday, December 5, 2025
44 changes · master
New functionality added to Odoo
This update adds sample data to the Odoo Enterprise system to demonstrate how referral reporting works. Specifically, it includes data for analyzing applicants by referral method and for tracking referral points within reward reports. This allows users to easily test and understand the referral reporting functionality.
Original PR description
Commit 1: - Remove post init hook for update stage as it just update the data after the demo data is installed. And directly assign the points to the recruitment stage. Commit 2: - Add demo data for applicants with different referral methods to be used in the referral analysis report. - Add demo data for referral points to be used in the reward analysis report demo. task-4687288
This update expands Odoo's US payroll functionality to include support for Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon, and North Carolina. This enhancement ensures accurate payroll calculations and compliance for businesses operating in these newly supported states.
Original PR description
With this, we add support for 8 more states in the US payroll: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon and North Carolina. Task: 5247501 Forward-Port-Of: odoo/enterprise#101141 Forward-Port-Of: odoo/enterprise#99278
This update incorporates local tax requirements for New York City and Yonkers. It adds necessary payroll rules and configurations to accurately calculate and remit taxes based on the NYS-50-T-NYC and NYS-50-T-Y forms. This ensures compliance with local tax regulations for employees in these areas.
Original PR description
This commit adds regional taxes for New York City, NY and Yonkers, NY. Relevant `hr.salary.rule` and `hr.rule.parameter` records are added in accordance to form NYS-50-T-NYC and NYS-50-T-Y. task-3548596
Enhancements to existing features
This update clarifies the labeling of a field used when making salary adjustments within the HR payroll system. The change ensures users understand exactly where this setting is accessible, improving the overall user experience. This is a minor improvement focused on usability.
Original PR description
This change ensures the label accurately reflects where the field is accessible and providing better clarity for users when working with salary adjustments. Task: 5375187 Forward-Port-Of: odoo/enterprise#101065
This update enables administrators to modify the work entries associated with payslips that have been reversed or refunded. Previously, these entries were immutable. This change improves operational efficiency by allowing corrections to be made directly within the system through the user interface.
Original PR description
-Originally, work entries for validated payslips cannot be modified. -This task allows for the modification of the work entries for the reverted payslips. -State of work entries can be modified manually through list view + form view on gear icons Task-id: #5380821
This update improves the AI live chat experience by enabling real-time streaming of AI responses to users. The system now displays 'AI is thinking...' messages while the AI processes requests, providing a more responsive and informative user experience. This change streamlines the AI interaction flow and enhances user engagement.
Original PR description
Convert the LLM processing loop in LLMApiService to a generator that yields (done, text_response) tuples, enabling real-time streaming of AI responses to clients. Key changes: - _request_llm_gen…
Convert the LLM processing loop in LLMApiService to a generator that yields (done, text_response) tuples, enabling real-time streaming of AI responses to clients. Key changes: - _request_llm_gen yields intermediate text responses during tool execution, allowing callers to stream progress updates - Introduce AITool NamedTuple to replace ad-hoc tuples, improving code clarity and enabling subtitle extraction from tool descriptions - Add "thinking text" mechanism using tool subtitles (parsed from `**Tool Thinking Message: <text>**`) to show users what the AI is processing - Move HTML conversion (markdown_format) out of _generate_response, making it the caller's responsibility - Add _call_tool method to LLMApiService for runtime introspection by other packages - Update /ai/generate_response endpoint to use HTTP streaming instead of JSON-RPC - Adapt JS to consume streamed responses and display thinking text Tests updated to consume generators before asserting results. TASK-ID: 5153674
This update improves how bank statement PDFs are handled within Odoo. When a PDF attachment is linked to a bank statement and synchronization is enabled, a corresponding document is automatically created in the Documents app, mirroring the journal's settings. This allows for easier retrieval of bank statements, similar to handling XML attachments.
Original PR description
[IMP] documents_account, test_documents_full: sync bank statement attachment When creating PDF (only) attachments linked to a bank statement and the document synchronization is configured for the…
[IMP] documents_account, test_documents_full: sync bank statement attachment When creating PDF (only) attachments linked to a bank statement and the document synchronization is configured for the journal of the statement, we create a document linked to the attachment following the synchronization settings of the journal (in the configured folder). This is similar to what is done for xml attachment for account move entry. The goal is to have PDF document of the bank statement in the app Document (ex.: when fetching coda from codabox, see TestDocumentsCodabox.test_codabox_file_import_document_creation). Note that we use the statement create_uid as owner of the created document and the create_uid.partner_id as partner_id. [MOV] l10n_be_codabox: extract test setup to use in test_documents_full We extract the setup of the tests so that we can test the document synchronization when fetching coda file in test_documents_full which ensures that documents_account is installed. Task-5187510 *: l10n_be_codabox, test_documents_full
This update enhances the user interface for managing work entries within Odoo, streamlining workflows and improving usability. The changes include a reorganized layout, a simplified editing process, and added features like source links for better tracking and reporting. This improves efficiency for HR and payroll teams.
Original PR description
*={_attendance,_enterprise,_holidays_enterprise,_planning}
- split MultiSelectButtons in 2:
- standard tools on the left
- quickAction on the right
- Use the multiCreateForm for the edit popover
- Allow the split by uncollapsing the current edited work entry to have a new empty record ready to be created
- Creation of a service to use the same popover behavior in calendar & gantt.
- Add a source link/text on each work entry
task-5122722This update enhances the way location units are managed within Odoo's payroll system for Belgium (l10n_be_hr_payroll). Specifically, it prevents data loss related to company information on payslips and introduces a new, more organized structure for managing fictitious location units used by the ONSS system. This ensures accurate payroll calculations and reporting.
This update enhances the user experience on the Frontdesk module by clarifying messages displayed when a report is empty. The changes improve readability and provide a better experience for users viewing an empty report screen, ultimately contributing to a more intuitive interface.
Original PR description
Updating the frontdesk empty screen messages for clarity and improving user experience when viewing an empty report screen. Task: 5380402
This update enhances the handling of Chilean electronic invoices by ensuring document folio numbers align with available CAF files. A key change requires a valid owner document (subject_serial_number) for certificates, improving data integrity and compliance with SII regulations. This ensures accurate invoice processing and avoids errors related to expired CAF files.
Original PR description
This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the…
This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the codebase. The most significant changes focus on ensuring that document folio numbers are correctly managed in accordance with available CAFs, making the certificate model more robust, and updating code style for clarity and consistency. This improvement is mostly made because CAFs have expiration dates and fixed folio numbers. If the expiration date is reached but the folios were not fully consumed, the system will try to generate a document with following number in the sequence but an error will be raised because that number belongs to an expired CAF, althought the user had already uploaded a new CAF. To fix this, whenever the system looks for the highest number to set to a document, it previously check if that number is between the folio numbers of a valid CAF file. ### Chilean electronic document sequence management * Added `_get_last_sequence` method to `account_move.py` to ensure that the folio number used for Chilean electronic documents (DTE) is valid and corresponds to an available CAF. If no CAF is available for the current folio, the sequence is reset using the document type's prefix and starting number. ### Certificate model validation * Made `subject_serial_number` a required field in the `Certificate` model, enforcing that every certificate has a valid owner document and improving data integrity. We made this change to prevent the field being empty after loading the certificate in Odoo, since it is required by the SII to validate invoices. Forward-Port-Of: odoo/enterprise#92208
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
Features or functions removed from Odoo
This update simplifies the AI modules by replacing outdated PyTZ dependencies with the more current ZoneInfo. This change was driven by a previous update to standardize timezone handling within Odoo, ensuring greater consistency and accuracy.
Original PR description
Small commit that replaces pytz dependencies with ZoneInfo since the following PR made that be the standard choice: https://github.com/odoo/odoo/pull/236660
This update removes an outdated dependency (pytz) from the AI module. The change was made to improve performance and align with best practices for timezone handling. This ensures Odoo continues to run efficiently and reliably.
Original PR description
Since #100008 the usage of pytz should be avoided and replaced by ZoneInfo.
This update removes a rarely used code for work entry types within the Odoo Enterprise payroll module. This cleanup improves the system's efficiency and reduces potential complexity. The change is a routine maintenance task to ensure the system remains optimized.
Original PR description
Removed code `LEAVE510` since it's not referenced anymore Task: 5365455
Code cleanup and technical improvements
This update simplifies the way ringtones are handled within the Odoo Enterprise system. Previously, a separate service was required to initialize ringtones; now, ringtones are directly initialized and exported as objects. This change improves efficiency and reduces complexity in the system.
Original PR description
There is no need to have a service to initialize a ringtone object. Instead, we just initialize an object and export it.