Daily updates from Odoo
Friday, February 27, 2026
21 changes · master
New functionality added to Odoo
This update enhances payment advice reports by including the beneficiary account used for salary adjustments. This provides greater transparency and clarity for payroll reporting, ensuring accurate record-keeping and compliance with In-country regulations. This change improves the reporting accuracy for employee compensation details.
Original PR description
-The beneficiary account details for the salary adjustment has been added to the payment advice report.
This pull request enhances Odoo's data cleaning capabilities with new models and views designed to improve data quality and consistency. The changes focus on unifying and merging data from different sources within the system, ultimately leading to more reliable reporting and business insights.
Enhancements to existing features
This update ensures that employee names are displayed in their full, correct length on pay run reports. Previously, names were truncated, which could lead to confusion and errors when reviewing payroll data. This change improves clarity and accuracy for HR and finance teams.
Original PR description
. Display Employee name in ful length on pay run listview task-5916582
Resolved issues and error corrections
This update streamlines the process of finding or creating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, reducing potential errors and improving data consistency. This enhancement ensures more reliable financial transactions and reporting.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update resolves an issue where a specific configuration of salary inputs on employee records would cause a calculation error during payslip generation. The fix prevents the system from incorrectly interpreting a hidden input field as a valid number, ensuring accurate payroll processing. This improves the reliability of payslip calculations.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247 Forward-Port-Of: odoo/enterprise#108731 Forward-Port-Of: odoo/enterprise#107326
This update fixes an issue where the payroll update process would fail when a common working schedule was deleted. The fix ensures that the system correctly handles situations where a referenced schedule is no longer present, preventing errors and maintaining accurate payroll calculations. This impacts all localized payroll modules.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553
Forward-Port-Of: odoo/enterprise#108730
Forward-Port-Of: odoo/enterprise#106950This update resolves a technical issue preventing the account reports annotation tour from functioning correctly. The change adjusts the confirmation button used in the tour to align with recent styling updates, ensuring the tour operates as intended. This improves the user experience for accessing and utilizing the account reports feature.
Original PR description
This PR updates the account reports annotation tour to use the correct confirmation button after the dialog styling change, fixing the failing test trigger. community: https://github.com/odoo/odoo/pull/247708 task-5873845 Forward-Port-Of: odoo/enterprise#108806
This update fixes an issue where the system incorrectly identified companies in certain localization modules (Brazil and Ecuador). Now, Brazilian partners with a CNPJ and Ecuadorian partners with a RUC are correctly recognized as companies. For other countries, a partner is considered a company if a VAT is provided.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797 Forward-Port-Of: odoo/enterprise#108599 Forward-Port-Of: odoo/enterprise#107674
This update corrects a potential data issue where OCR processing of CVs could incorrectly overwrite existing contact information (like company or user details) within the system. The fix adds safeguards to ensure OCR data is only applied when appropriate, preventing inaccurate data propagation. This ensures data integrity for applicant records.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places to precisely match the 'Quantity × Amount' displayed on payslips. This ensures accurate and consistent payroll reporting for employees.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108606 Forward-Port-Of: odoo/enterprise#106753
This update fixes a technical issue related to how numeric values are handled in the web_studio interface and ensures consistent use of the new badge widget across the appointment module. It improves the reliability of data entry and aligns with recent changes to the core widget system, enhancing overall system stability.
Original PR description
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a…
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a mandatory follow-up to the migration of icon support and dropdown fallbacks into the standard `selection_badge` widget. ### **Key Changes:** * **Widget Migration:** Replaced all occurrences of `widget="selection_badge_icons"` with `widget="selection_badge"` in appointment question views. * **Studio Property Fix:** Updated `web_studio` property parsing to use `Number()` instead of `JSON.parse` for numeric values. This prevents errors when handling numeric strings with leading zeros (e.g., "032"). * **Test Alignment:** Updated the OWL tests to use the new `.o_field_selection_badge` class name for waiting and selectors, ensuring the test suite remains green. * **Compatibility:** Maintained the existing `icon_mapping` and `size` options, which are now natively supported by the core widget. **Task-5270283** **Related Community PR:** odoo/odoo#243855
This update fixes a technical error preventing managers without appraisal rights from scheduling meetings. The issue stemmed from access restrictions related to employee data. The fix simplifies the process by directly using the employee's work contact information instead of the problematic related partner ID.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
A bug was preventing users from correctly saving approval rules with specific domain filters in the web studio. This was caused by a mismatch in how data was represented between Python and JavaScript. The fix ensures that domain filters are saved accurately, allowing users to properly configure email approvals.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update resolves an issue where payment reference data from the Codabox integration was incorrectly formatted, often with leading or trailing spaces. The change automatically removes these spaces before creating reco models, ensuring accurate data processing and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update resolves an issue where test applications for new hires were failing due to missing applicant name information. The team has added required partner_name values to the test cases, ensuring data integrity and preventing errors during application creation. This improves the reliability of our recruitment testing process.
Original PR description
In the related community PR, we are making the partner_name as required. So need to give the partner_name values in the test cases while creating the `hr.applicant` to resolve the not null violations Community PR:- https://github.com/odoo/odoo/pull/203222 sentry-6409185730
This update corrects a display issue in the chat window where the agent's subtitle was not appearing correctly when the agent description was blank. The fix adds a default message to ensure the subtitle is always visible, improving the user experience. This resolves a previous display problem.
Original PR description
The chat subtitle is false, if the agent description is not set. This commit fixes the issues by adding a default message if subtitle is missing. Task-5916227 Forward-Port-Of: odoo/enterprise#108948 Forward-Port-Of: odoo/enterprise#106949
This update fixes an issue where social security numbers were incorrectly displayed across different company views in Odoo. The change restricts SSN visibility to only appear within the specific country's company records, ensuring data privacy and compliance. This improves data accuracy and reduces potential reporting errors.
Original PR description
[FIX] l10n_hr_payroll: limit l10n_xx_ssn to appear only in xx companies Bug reproduction: Select version >= saas-19.2 -> select your company -> payroll->employee->personal->you will see social security number even though that can belong to SA, MX, EG. Bug cause: added ssn fields are not restricted to their own l18n, then they are appearing in each employee form views. Bug solution: add country restrictions for MX, EG, SA to not appear in other country's company. task - 5974006 Forward-Port-Of: odoo/enterprise#108903
This update fixes a bug that prevented accurate payment advice reports when employees had multiple bank accounts. The team verified all bank accounts and BIC codes to ensure the system correctly generates reports, even with secondary bank information. This ensures accurate financial reporting for our users.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#109002 Forward-Port-Of: odoo/enterprise#107283
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This resolves a technical issue that could have impacted the stability of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
Code cleanup and technical improvements
This update prepares for a change to improve how the portal communicates with the Odoo server. It now allows the server to recognize requests originating from the portal, enabling targeted limitations and better performance. This refactoring enhances the overall system's responsiveness and integration.
This update clarifies the event triggered when the website builder prepares to save a complete document. The change ensures the system correctly handles saving the entire website design, rather than individual snippets. This improves the reliability and efficiency of the website building process.
Original PR description
This commit renames the resource `on_will_reset_history_after_saving_handlers` (formerly `save_handlers`) to `on_ready_to_save_document_handlers`. To convey that: - the event is "the builder is ready to save the document" - this is about saving the whole document (and not a custom snippet)