Daily updates from Odoo
Wednesday, March 18, 2026
13 changes · 19.0
Enhancements to existing features
This update adapts the French accounting reports to a new way of receiving data from the system. Instead of downloading large files, the system now streams the data, improving efficiency and reducing download times. This change ensures continued accurate reporting for French businesses using Odoo Enterprise.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#106920 Forward-Port-Of: odoo/enterprise#102783
Resolved issues and error corrections
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system incorrectly deleted the original invoice document, potentially leading to data loss. The fix ensures the correct invoice document is protected, preventing accidental deletion during the update process.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147
This update resolves issues where overtime calculations were incorrect due to timezone discrepancies, leading to crashes and orphaned overtime records. The fix ensures accurate overtime intervals are generated and handled, regardless of the employee's location, improving data integrity and reliability.
Original PR description
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a…
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)". Steps to reproduce (stale overtime lines): With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed. The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`. The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Solution: - In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day. - In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors. - In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle. opw-5931665
This update resolves an issue where users were receiving an error message when exporting payroll data to SDWorx for freelance employees. The fix ensures that the system correctly skips the SDWorx code validation step for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update corrects a problem where employee documents were being accessed using the wrong website domain, leading to incorrect URLs. The fix ensures documents are accessed using the correct, system-defined base URL, improving document access reliability.
Original PR description
Steps to reproduce: --------------------------------- 1. Install `documents_hr` and `website_documents` modules 2. Go to website > configuration > websites 3. In My Website set any arbitary domain…
Steps to reproduce: --------------------------------- 1. Install `documents_hr` and `website_documents` modules 2. Go to website > configuration > websites 3. In My Website set any arbitary domain (e.g. https://test.com) 4. Open any employee record 5. Click on Documents smart button Observation: --------------------------------- It will try to open employee's documents with the website's domain, e.g. `https://test.com/odoo/documents/xyz` Issue: --------------------------------- After the following commit: https://github.com/odoo/enterprise/pull/92774/changes/46c43c14fb2a0fb7b693ede53cc84dbf8bdc9bcb the smart button redirects to the document folder via an access token. The `access_url` is computed using `get_base_url()`, which is overridden by the website module to return the website domain instead of the system base URL. https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/website/models/ir_model.py#L10-L36 Solution: --------------------------------- Added a context-based check to `get_base_url()`. When the context key `use_config_parameter_domain` is set, and the record has a `website_id` field, the system base URL from the configuration parameters is used instead of the website domain. This allows any model to explicitly rely on the configured base URL when required NOTE: No module installs `hr`, `documents` and `website`, so test case is not possible without bridge module of all three Related Community PR: https://github.com/odoo/odoo/pull/247920 opw-5471683
This update corrects a display issue in the employee profile where the 'Relationship' field was incorrectly shown to employees outside of India. The fix ensures this field is only visible for employees associated with Indian companies, aligning with localization requirements. This change improves the user experience for all employees.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update fixes an issue where the report editor in Web Studio wouldn't automatically focus after deleting rows or columns. The change prevents a test failure caused by browser behavior, ensuring the editor is immediately ready for use when a user clicks on it. This improves the user experience and efficiency within the report design process.
Original PR description
PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s native focus behavior. This commit ensures that editable is focused whenever clicking on t-field. [1]: https://github.com/odoo/odoo/pull/249256 [2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478 Community PR: https://github.com/odoo/odoo/pull/249256 task-5725593
This update resolves a technical issue within Odoo's Studio feature where actions incorrectly linked views to inherited ones. Previously, this caused errors when creating new studio designs. Now, the system correctly identifies and uses inherited views, ensuring stable design creation and eliminating the error.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734
This update corrects a visual discrepancy between how the AI livechat snippet is displayed in the editor and how it appears to users. The issue stemmed from mismatched code structures, leading to inconsistent rendering. This fix ensures the AI livechat snippet displays correctly across different devices and configurations.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change)
This update fixes a usability issue on mobile devices where a key button was hidden within a dropdown, requiring scrolling to access. The change ensures the loan record creation process is smoother and more intuitive on smaller screens, allowing users to easily complete the process.
Original PR description
Forward-Port-Of: odoo/enterprise#110552 Forward-Port-Of: odoo/enterprise#110120
This update ensures that NACHA payment files accurately reflect the actual account holder's name, rather than the customer's name in Odoo. Prioritizing the bank account holder's name improves payment processing accuracy and compliance with NACHA regulations.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
This update ensures that the PIN code is now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (via digital wallets) because they couldn't access the necessary PIN information. This change improves the user experience and ensures seamless payment processing.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462
This update resolves a validation error with the ARCA system (used for Argentinian tax compliance) when processing invoices for 'Final Consumers' without VAT/CUIT numbers. The system now correctly sends a 'null' value for the invoice number, aligning with ARCA's requirements and preventing invoice rejection.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.