Daily updates from Odoo
Tuesday, March 31, 2026
28 changes · master
New functionality added to Odoo
This update introduces a new 'ATN_MISC' benefit of kind to Odoo's payroll calculations. The employee PFI and CP200 salary rules have been adjusted to incorporate this new benefit, ensuring more accurate payroll processing. Unit tests have been added to verify the changes and maintain data integrity.
Original PR description
[IMP] l10n_be_payroll: new benefit of kind (ATN_MISC)
Miscalleneous Benefit Kind is added
employee_pfi and cp200_employee salary rules are adjusted with new added benefit of kind.
Test:
Unit tests are written to
1. check new ATN_MISC and ATN.MISC.2 lines are there
2. control payslip line_ids and their totals in the payslip.
task - 6032480This update introduces a new module for importing blog content directly into Odoo websites. The module allows users to utilize the import tool to manage blog posts, tags, and categories, streamlining the process of creating and publishing blog content. Initial support is focused on WordPress websites, with plans for future platform integration.
Original PR description
Add new website_generator_blog module to import blogs using the import tool. We import blog.blog, blog.post and blog.tag, currently only supported for websites using the WordPress platform. Future platforms to be supported. Added cogwheel import button to views: "blog.post" "blog.tag" "blog.blog" "blog.tag.category" Added API check for blogs in the import form. Updated the email template to include blog information. task-6003434
This update introduces the required 2031 tax income report (liasse fiscale) within the Odoo Enterprise system. The changes include new report templates and data formatting improvements to ensure accurate and compliant tax reporting for French businesses. It also incorporates minor adjustments to existing reports for enhanced presentation.
Original PR description
This commit will add the 2031 tax income report for the liasse fiscale. task-5436868
Enhancements to existing features
This update enhances the user experience when managing employee types within Odoo Enterprise. Changes were made to the search and modification functionalities, streamlining the process for HR teams to accurately define and update employee type settings. This improves overall efficiency and data accuracy.
Original PR description
In order to improve the user experience in viewing and modifying the employee types, certain changes had to be introduced to the search domain and functionalities. Task: 6071046
This update clarifies the naming of roles within Odoo's planning slots. The 'Roles' field has been renamed to 'Resource Roles' for better clarity and consistency. This change improves the organization and understanding of user permissions within the planning module.
Original PR description
rename `Roles` field into `Resource Roles` in planning.slot --- task-4329025
This update enhances the Manufacturing Order Kanban view by adding a progress bar that accurately reflects the remaining time for each order. The changes address a technical limitation regarding data storage and improve the visual representation of order progress within the Kanban interface. This provides a clearer understanding of order status for users.
Original PR description
Enhace Manufacturing Order Kanban view (progress bar) - override group aggregate on remaining_time as it is not stored - format according to remaining time in Kanban's card - disable animations task: 5882943
This update brings a more consistent experience for requesting and managing signatures within Odoo. By consolidating signature logic into the Activity model, users can now easily request, resend, or sign documents directly from the activity popover, mirroring the standard Chatter interface. This refactoring simplifies the codebase and improves efficiency.
Original PR description
This PR brings feature parity to the signature Activity Popover by aligning its buttons with the standard Chatter, allowing users to request, resend, or sign documents directly from the popover.
To achieve this cleanly, the PR also includes:
Refactoring: Moves shared signature logic (like requestSignature) into the Activity frontend model, eliminating duplicated JS code across UI components.
Task: 5989542This update enhances the IoT module by adding type hinting to the Python code. This improves code readability and maintainability, which will help our development team identify and resolve potential issues more efficiently. Additionally, outdated header files have been removed to streamline the codebase.
Original PR description
This commit adds some basic type hinting to the Python code in the IoT module. It also removes outdated 'coding utf-8' headers in the Python files.
Resolved issues and error corrections
This update resolves an error that occurred when converting helpdesk tickets to opportunities. The fix ensures the system correctly handles cases where a ticket lacks a partner email, preventing a technical error and allowing users to successfully convert tickets.
Original PR description
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. -…
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. - Create a `new ticket`, set only the `ticket name`, and `save` the record. - Click on the `Convert to Opportunity` button. **Error:** `TypeError: 'bool' object is not iterable` After this [recent commit], the system attempts to find the partner using the partner email. Since the helpdesk ticket does not have partner email, False is passed as the email [1]. As result, when retrieving emails based on the ticket record, it returns False, and iterating over it raises the error [3]. This commit ensures that the system attempts to find the partner from the email only if the partner email exists. It also passes the partner email as a list, since _partner_find_from_emails_single expects emails in list format. [recent commit]: https://github.com/odoo/enterprise/commit/41aa34b74f59d48c3ad2fc87a5655866fda968c9 [1]- https://github.com/odoo/enterprise/blob/241b2b0174731558795572d8843d9b184d98e2e0/crm_helpdesk/models/helpdesk_ticket.py#L21 [2]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2050 [3]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2052 sentry-7359614247 Forward-Port-Of: odoo/enterprise#111953
This update resolves an issue where custom payrun filters weren't consistently applied across different payruns. The change ensures that saved filters now correctly apply to the current payrun, providing a more reliable and user-friendly experience when managing payroll data. This prevents users from being directed to the payrun where the filter was originally saved.
Original PR description
Before this commit, when a user saves a custom filter on a payrun in step "payslip", then moved to another payrun, trying to apply the saved filter takes him to the payrun in which the custom filter was saved. Solution: Removing the search default parun id from the context of the action that opens the payslips of a payrun, and instead, adding a domain on the action to only show the payslips of the current payrun to avoid having the filter binded to a specific payrun. task-6075315
This update resolves an issue where the Paid Time Off Allocation wizard appeared empty in the demo data due to a filter requiring a 'dimona' category. The PR sets the 'Other' category as the default for demo employees, ensuring the wizard displays accurate results. This improves the usability of the demo environment.
Original PR description
Due to this PR (https://github.com/odoo/enterprise/pull/103118), the query that is run when using the Paid Time Off Allocation wizard now includes a filter on the dimona category, only returning results with category "Other". The demo data employees don't have a dimona category set and therefore the wizard appears empty: in order to avoid this confusion we set the dimona category of the demo data employees to Other by default. Task: 6067231
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The fix skips PDF extraction when no raw data is present, ensuring that documents are processed correctly and preventing errors. This improves the reliability of document generation.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves a technical issue where the suspense line validation process was failing due to an incorrect data type. The change improves the reliability of the suspense line calculation, ensuring accurate reporting. This primarily affects the account accounting module.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update resolves an issue preventing SBR tax reports from submitting due to incorrect date formatting and overly long consultant descriptions. The commit restores the original date format and simplifies the consultant name to only display the abbreviation, ensuring compliance with validation requirements and successful report submission.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update fixes an issue where searching for deliveries by zip code alone resulted in inaccurate location suggestions. The fix ensures that the system correctly includes city information when searching through Sendcloud, leading to more precise delivery options for customers. This improves the overall efficiency of our delivery process.
Original PR description
Issue ----- Searching for locations by only providing a zip code has unexpected results. Steps to reproduce ----- - Set up Sendcloud with Mondial Relay - Create a sale through the website - Get to the delivery part - Select sendcloud delivery - Search for a zip code only (11000) > Points are all in the 12200 area Cause ----- When searching through the wizard, a temporary address is created in https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/delivery/models/sale_order.py#L108-L112 which always has its' city field set to `False`, as all of the wizard's info is interpreted as the zip code. This leads to the address field sent to Sendcloud being '11000 False' instead of the expected '11000', which Sendcloud fails to interpret correctly. ----- Ticket: opw-5999194 Forward-Port-Of: odoo/enterprise#112219 Forward-Port-Of: odoo/enterprise#110459
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal comparisons and successful invoice transmission. This prevents errors related to differing decimal amounts.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#111518 Forward-Port-Of: odoo/enterprise#110706
This update resolves an issue where the CFDI invoice reports incorrectly displayed '99 - False' instead of '99 - Por definir' for a specific payment method (99). The fix ensures that the report accurately reflects the payment method used on invoices, particularly those with payment policies.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111661 Forward-Port-Of: odoo/enterprise#107267
This update corrects a minor visual issue in the appointment scheduling forms, specifically aligning the checkbox labels correctly. The recent M3 update caused a slight misalignment, and this change ensures a cleaner and more professional appearance for users. This improves the overall user experience for scheduling appointments.
Original PR description
The js M3 update broke some of the form layouts. this commit fixes a checkbox suffix being displayed on the far right of the column by enforcing w-auto on the checkbox instead of w-100 Task-6048484
This update resolves an issue where commissions weren't correctly calculated when the target completion was set to 0%. The fix ensures that commissions are accurately applied even when the target amount is zero, addressing a previous bug that resulted in incorrect commission values.
Original PR description
Before this commit, when target completion was 0% and the commission was equal to X (where X is not null), the commission could not be equal to X. It would be equal to 0. It was working with target amount equal to 0. Forward-Port-Of: odoo/enterprise#112337
This update fixes an issue where the tax return reports incorrectly included Italian pension fund taxes, leading to discrepancies between the report and the backend view. The change excludes these taxes from the tax return domain, ensuring accurate calculations and consistent reporting for Italian customers.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
This update resolves a technical issue where a controller was incorrectly referencing outdated code from a previous Odoo version. The fix ensures the E-Commerce functionality is working as intended, preventing potential disruptions to the sales process. This is a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it. Forward-Port-Of: odoo/enterprise#112451
This update fixes an issue where AI tool responses with non-string data (like dates) were causing errors. By standardizing how tool results are formatted, this ensures consistent and reliable communication between Odoo's AI services and providers like Gemini, improving overall AI performance.
Original PR description
#### Description When a tool returns a non-string result (e.g. a dict containing datetime values), it was passed as-is into the response parts, causing a TypeError for Gemini provider's agents. Move json.dumps with json_default into the shared format_tool_result method so all providers benefit from proper serialization, and remove the now-redundant serialization from the OpenAI provider's `format_tool_result` method. task-id-6072688
This update resolves a bug that prevented users from successfully updating documents. The system was previously crashing due to incorrect handling of PDF data (specifically base64 strings). Now, the system correctly decodes the data into bytes, ensuring smooth document updates.
Original PR description
Before this commit, with the changes from updating a document could crash with a TypeError because the PDF data was passed as a base64 string instead of raw bytes. After this commit, we decode the base64 string into bytes before trying to read the PDF, preventing the crash and allowing the document update. task-6071104
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when tax lines are shared across expense lines with and without vehicle assignments, ensuring correct tax calculations.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112440 Forward-Port-Of: odoo/enterprise#110616
This update fixes a visual issue with the 'per employee' suffix field in the MRP Workcenter module. The change restores the standard inline display, ensuring a cleaner and more intuitive user experience. This improves the clarity and usability of the workcenter configuration.
Original PR description
This commit restores the correct inline display for the field containing the "per employee" suffix. task-6037387
This update ensures the subtotal row is always visible when calculating taxes externally. Previously, the subtotal was hidden in tax-included scenarios. This change maintains a consistent and clear layout for customers during the checkout process, regardless of how taxes are calculated.
Original PR description
Before this commit: With the tax-included display logic, the subtotal row was hidden in tax-included mode. In the `website_sale_external_tax` module, both total and tax rows are hidden before the payment step when tax is calculated externally. This results in subtotal row being hided in tax-included scenarios. After this commit: Adapted the subtotal row condition to also be visible when `is_tax_computed_externally` is true, ensuring that in external tax flows the subtotal remains visible in both tax-included and tax-excluded modes, keeping the layout consistent. task-5887432 See also : https://github.com/odoo/odoo/pull/251698
This update fixes a minor visual issue in the Odoo test environment related to date fields. The change ensures that date fields are correctly displayed as inputs, not buttons, after the datepicker is closed. This improves the consistency and usability of the test setup.
Original PR description
This commit adapts an iap_test interacting with date and datetime fields, according to the small behavior change done in odoo/odoo#256671. Before, the field was already blured due to the datepicker when it was being edited in the test. Now that the picker isn't open anymore, the field isn't blured, so it is still displayed as an input, not a button, which must thus be correctly targetted to be blured. task~6045658
This update resolves an issue where the Bank Reconciliation widget could crash when deleting a counterpart line. The fix ensures the method returning data from the Bank Reconciliation process is always valid, improving the stability and reliability of this key financial reporting feature. This prevents unexpected errors and ensures accurate reconciliation.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112546 Forward-Port-Of: odoo/enterprise#112175