Daily updates from Odoo
Tuesday, April 28, 2026
36 changes · master
New functionality added to Odoo
This update enables users to add employees to existing pay runs after they've been created. Previously, adding employees was impossible, leading to issues with off-cycle pay runs and new employee creation. Now, users can seamlessly add employees to pay runs, automatically generating payslips for them in draft state.
Original PR description
Before this commit, it was not possible to add an employee to a pay run after it was created. This caused problems when: - An employee was removed from an off-cycle pay run. - A new employee was created after the pay run had already been created. - Users should be able to add employees to an existing pay run. In this commit, - In the Employee step, add a new button next to Continue called "Add Employees" - When clicked, it opens the same list view used during pay run creation. - In the list view, show only active employees. - Filter employees within the pay run date range. - Match the correct payroll structure (if required). - If the pay run is validated (payslips validated), the button should be hidden. → Employees cannot be added in this state. - If the pay run is Ready (payslips created in draft state): → Adding employees should automatically generate payslips for them. Task - 5955049
Enhancements to existing features
This update fixes inaccuracies in how tax amounts are calculated for Arabic VAT transactions. By modernizing the calculation engine and ensuring precise formatting of final amounts, the system now delivers more accurate VAT reporting and financial figures. This improves the reliability of financial data within the Odoo Enterprise system.
Original PR description
- Rewrite all tax amounts calculations on `_get_tributes` and `_get_line_details` to properly use the tax computation engine helpers (`base_line`, and aggregating methods) - Ensure that all final amounts from the calculation are formatted with `float_repr` with appropriate precision. related-community-PR: https://github.com/odoo/odoo/pull/223393 task-4891206 Forward-Port-Of: odoo/enterprise#115069 Forward-Port-Of: odoo/enterprise#92639
This update optimizes a key process within the account reconciliation feature. By using record sets instead of individual account IDs, the system avoids redundant database searches, leading to faster performance. This change improves the overall efficiency of the account reconciliation workflow.
Original PR description
This commit will change the _check_and_create_reconciliation_rule function to use the record set instead of the id of the account, same for _prepare_reconciliation_rule_data. That will allow us to avoid doing a browse twice because doing a browse later and using the new record (without the prefetch ids) is not very efficient. task-5081786
This update streamlines the automated processing of POS orders by combining multiple cron jobs into a single, more efficient process. This reduces unnecessary system activity and improves overall performance, leading to better resource utilization. The previous redundant cron job has been removed as part of this change.
Original PR description
This commit consolidates multiple POS order-related cron jobs into a single generic cron to reduce registry wake-ups and CPU usage. A new cron `ir_cron_process_pos_orders` runs every 5 minutes and calls `_cron_process_pos_orders`, which coordinates all related tasks such as `notify_future_deliveries`. The redundant cron `cron_check_future_delivery_orders` has been removed as part of this consolidation. Task-5449515 Related PRs: - https://github.com/odoo/odoo/pull/241800 - https://github.com/odoo/upgrade/pull/9973
This update significantly improves the demo data for the Helpdesk application, making it more effective for showcasing its features and functionality to potential users. The changes include updated data within several related modules, providing a richer and more realistic demonstration of the Helpdesk app's capabilities. This will improve the quality of demos and presentations.
Original PR description
_* = helpdesk_fsm, website_helpdesk_knowledge, website_helpdesk_knowledge, website_helpdesk_slides, website_helpdesk_slides_forum Significantly improved demo data for a more effective showcase of the helpdesk app’s features and functionality. task-3186557
This update prioritizes incomplete tax returns in the tax returns kanban view when no filters are selected. This change ensures users see the most critical returns first, streamlining the process of reviewing and managing tax obligations. It’s a simple improvement to enhance usability and efficiency.
Original PR description
When no filters are applied on the tax returns kanban view, incomplete returns should always be displayed before complete ones. This commit ensure that by ordering tax returns by `is_completed` field. task-6059414 Forward-Port-Of: odoo/enterprise#114043
This update makes the 'Return Types' menu item available in the Odoo Enterprise configuration, previously restricted to debug mode. This change allows users to easily manage return types within the accounting reports, improving workflow efficiency and reporting accuracy.
Original PR description
Before, the menu return types in configuration was only available in debug mode. Now it is available for the group `account.group_account_readonly` task-5912751 Forward-Port-Of: odoo/enterprise#114830
Resolved issues and error corrections
This update resolves an issue preventing AI chat functionality on Safari iOS devices. The fix addresses a compatibility problem with older Safari versions that don't fully support a key streaming technology. By switching to a manual reader loop, the AI chat now functions correctly on Safari, ensuring a smooth user experience.
Original PR description
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests…
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests compatibility, Safari (WebKit) versions prior to 26.4 do not implement the AsyncIterator protocol on ReadableStream. This makes `for await (const chunk of response.body)` throw a TypeError as `[Symbol.asyncIterator]` is undefined. https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream This commit replaces the async iteration with a manual reader loop (`getReader().read()`). This is the low-level primitive supported by all versions of Safari and ensures the stream is properly consumed and unlocked even if the connection is interrupted. Steps to reproduce: 1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4). 2. Send a message. 3. The response triggers a JS error. ```js Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...') ``` opw-6054307 Forward-Port-Of: odoo/enterprise#113926
This update resolves an issue where Peruvian identifiers (like driver licenses) were not being displayed correctly in the system. The change in 19.1 impacted how these identifiers were handled, and this commit restores the visibility of these fields. A related fix was implemented in the Community version to ensure overall consistency.
Original PR description
In 19.1 we changed the `is_company` field to a computed stored field. That change broke the visibility for some Peruvian identifiers (driver license, etc). This commit removes the visibility condition on those fields to be displayed all the time. Note: we still add the correct compute on related Community commit for sake of correctness and completeness. Community: https://github.com/odoo/odoo/pull/260224 Related: https://github.com/odoo/odoo/pull/211043 task-6141307 Forward-Port-Of: odoo/enterprise#115204 Forward-Port-Of: odoo/enterprise#114403
This update fixes a problem where Wise recipient matching failed due to slight differences in data (like spacing or capitalization) between Odoo and Wise. Now, the system uses only financial details like account numbers and routing numbers for matching, ensuring accurate recipient identification and preventing duplicate entries, especially for IBAN accounts.
Original PR description
Previously, _generate_wise_key included partner name and email in the matching key. If these differed between Odoo and Wise (e.g. trailing spaces, casing), the match would fail and a duplicate recipient was created. Use only financial identifiers (account type, routing number, account number) which are the actual unique identifiers for bank accounts. This is for example important with IBAN accounts as the won't have an email stored in Wise. From this we combine IBAN and SWIFT recipients into one non-US group. Forward-Port-Of: odoo/enterprise#115209 Forward-Port-Of: odoo/enterprise#113234
This update fixes a reporting issue for Hong Kong payroll taxes. It adds adjustments to the calculations for IR56B/F/G reports, ensuring that global reimbursements and deductions are accurately reflected in the taxable income totals. This improves the accuracy of tax reporting for Hong Kong businesses using Odoo Enterprise.
Original PR description
Added GLOBAL_REIMBURSEMENT and GLOBAL_DEDUCTION to the AmtOfSalary calculation for IR56B/F/G reports. This ensures adjustments are properly reflected in taxable income totals. task-6126661 Forward-Port-Of: odoo/enterprise#115229 Forward-Port-Of: odoo/enterprise#114041
This update resolves a problem where correction payslips were failing validation due to missing information. The change ensures that correction payslips include the necessary 'structure_id' and adjusts the payrun period to accurately handle multi-month corrections. This improves the reliability of payroll processing.
Original PR description
Ensure `structure_id` is set when creating correction payslips to avoid validation errors. Group payslips by structure before creating pay runs for corrections/reverts, and set the payrun period from the minimum to maximum payslip dates. Fix condition in "Payslip period does not match payrun" to exclude correction payslips (they may span multiple months). task: 6089082
This update corrects a bug where flexible employee hours were incorrectly hidden in the Gantt view for longer work periods. The fix ensures accurate hour calculations across all flexible schedules, displaying progress bars correctly and improving the visibility of employee time tracking. This ensures accurate reporting and scheduling for flexible staff.
Original PR description
For employees having a `resource_calendar_id` with `flexible_hours`, the max hours displayed in the gantt view were incorrectly `days * hours_per_day`. This fixes it by taking the most relevant data between `days * hours_per_day`, `weeks * hours_per_week`, both, or nothing if the range is more than a month. The new calculation is `(weeks * hours_per_week) + min((days * hours_per_day), (hours_per_week))` task 5075953 Forward-Port-Of: odoo/enterprise#114661 Forward-Port-Of: odoo/enterprise#105266
This update resolves an issue where Odoo couldn't import CODA files from Belgian banks when the detail sequence (3.2) was incremented. Banks sometimes provide files with updated sequences, and this fix allows the import process to handle these changes without triggering an error. This ensures seamless bank statement imports for our BE customers.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update resolves a persistent scrollbar flicker issue in the Gantt chart. The problem stemmed from an incorrect row height calculation, which has now been corrected. The fix ensures a smoother and more reliable Gantt chart experience for users.
Original PR description
This commit fixes an issue where the scrollbar would flicker uncontrollably at certain scroll positions. This occurred because grid elements were constantly appearing and disappearing at the edge of the viewport on every animation frame. The root cause was a discrepancy in row height computations introduced in https://github.com/odoo/enterprise/pull/101732. The virtual grid was receiving row heights 8px smaller than the actually rendered rows, leading to miscalculations in visibility. To fix this, the problematic 8px change is reverted. The original design requirement (fitting the progress bar) is instead fulfilled by explicitly adding height to group rows, and providing additional space to regular rows on smaller screens. Forward-Port-Of: odoo/enterprise#115283
This change updates the email address used to receive responses to automated emails from clients. Previously, emails were sent to iap@odoo.com, which led to some responses. Now, emails are sent to noreply@odoo.com for better management and tracking.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update ensures that replacement invoices generated after a cancellation process include the original invoice's 'Source' (origin) information. Previously, this data was missing, leading to traceability issues. This fix maintains accurate links between invoices and Sales Orders, improving document accuracy and compliance.
Original PR description
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice…
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099
This update resolves an issue where the 'Configuration' menu was hidden for users with 'All Timesheets' access, preventing them from managing billing targets. The fix ensures that billing-related menus are correctly displayed or hidden based on user permissions and feature settings, improving usability for approvers.
Original PR description
Steps to reproduce Bug 1: 1. Login as a user with "All Timesheets" (Approver) access. 2. Disable the "Timesheet Assistant" feature for this user. 3. Ensure "Billing Rate Indicators" is enabled in…
Steps to reproduce Bug 1:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Timesheet Assistant" feature for this user.
3. Ensure "Billing Rate Indicators" is enabled in settings.
Steps to reproduce Bug 2:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Billing Rate Indicators" setting in company settings.
3. Ensure "Timesheet Assistant" is enabled in settings.
Steps to reproduce Bug 3:
1. Only install 'sale_timesheet_enterprise'.
2. Go to Timesheets > Configuration > Settings.
3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.
Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.
Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.
Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
- Hide all billing-related menus for all users when the feature is disabled.
- Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.
task-5428010
Forward-Port-Of: odoo/enterprise#106464This update resolves an issue where account return tours weren't functioning correctly across different localization settings (l10n). The fix addressed a missing tag that caused errors, preventing the tours from running properly and leading to unhandled issues. This ensures all users, regardless of their location, receive the correct return tour guidance.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action. Forward-Port-Of: odoo/enterprise#115290
This update resolves an issue where financial reports (FAIA export) were incorrectly linking invoices to accounts. The fix ensures that the AccountID in sales and purchase invoices matches the AccountID defined in the company's general ledger, improving the accuracy of financial reporting. This was part of a larger effort to standardize export formats.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#114254 Forward-Port-Of: odoo/enterprise#113455
This update corrects a technical issue preventing the proper handling of binary data within the l10n_uk_reports_cis module. The change ensures that binary fields now correctly accept the 'BinaryBytes' format, resolving a previous incompatibility. This ensures accurate reporting for UK tax compliance.
Original PR description
Since https://github.com/odoo/odoo/pull/244421, binary field does not accept 'bytes' but to be wrapped explicitly as 'BinaryBytes' task-5481774 Forward-Port-Of: odoo/enterprise#115249
This update corrects a mismatch in transaction identifiers used when generating financial reports (FAIA). Previously, the system used different methods for identifying transactions, leading to potential errors in export data. This change ensures all transaction IDs align, improving the accuracy and reliability of financial reports.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
This update resolves a failing test related to WorldLine integration within our self-order point-of-sale system. The fix ensures that the test only runs if both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are installed, preventing errors and improving test reliability.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed. Forward-Port-Of: odoo/enterprise#115282
A small typo was causing a critical error when users attempted to clock in with a blackbox POS system. This update corrects the error, ensuring receipt data generation functions correctly and preventing system crashes. This resolves a technical issue impacting POS functionality.
Original PR description
There is a typo trying to assign the server version to `this` instead of the `data` object which is used for the receipt. This causes a `cannot set properties of undefined` error when trying to clock in with a blackbox Forward-Port-Of: odoo/enterprise#115098
This update fixes a technical issue that caused a traceback when viewing restaurant bookings with no bookings. The fix corrects an automatic change introduced during a migration, ensuring the correct variable is accessed within the booking list view. This improves the stability and usability of the restaurant booking module.
Original PR description
Inside the custom list renderer for booking for pos_restaurant we access `this.list.records` which doesn't exist and throws a traceback when no there are no bookings. The `this.` was added automatically by a migration script for OWL3 to force this usage to target component variables. But in this case `list` is set inside the web.ListRenderer template with `t-set`. This commit will revert the automatic change for the access to and replace `this.list.records`, with `list.records` Task-[6147678](https://www.odoo.com/odoo/project/1737/tasks/6147678) Forward-Port-Of: odoo/enterprise#114589
This update fixes a bug where bank statement reconciliation could incorrectly match transactions from different companies. The fix ensures that payments and bank statements share the same company hierarchy, preventing foreign tax lines from being added to the wrong company's accounting records. This improves the accuracy of financial reporting.
Original PR description
ticket-5992100 When auto-reconciling bank statement lines, the end-to-end UUID lookup correctly checked that matched AMLs and their payment belong to the same company hierarchy, but missed checking that the payment also belongs to the same company hierarchy as the bank statement line itself. This allowed a payment from an unrelated company (sharing the same end-to-end UUID from an inter-company bank transfer) to be matched against another company's bank transaction, pulling foreign tax lines into the wrong company's journal entry. Fix by adding the same parent-path company check between the bank statement line and the payment. Forward-Port-Of: odoo/enterprise#114881 Forward-Port-Of: odoo/enterprise#113279
This update resolves an issue where SEPA payment files generated with split payslips (using multiple bank accounts) contained duplicate transaction identifiers. The change adds a unique identifier to each transaction block, ensuring compliance with ISO 20022 standards and preventing potential payment processing errors. This ensures accurate and compliant SEPA file generation.
Original PR description
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is…
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is based on the payslip ID When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers https://knowledge.xmldation.com/support/iso20022/general_rules/instrid This commit adds a unique suffix (e.g., -1, -2) to the `InstrId` for each transaction generated from the same payslip to ensure technical uniqueness Nothing change when you only have one account This is the part of the code that use the payment name: https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299 ### Steps to reproduce: - Install `hr_payroll_account_iso20022` with demo data - On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number` - Open the Employee page for Abigail Peterson - In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any) - Click on Salary Allocation and Save (You'll have a 50/50 ratio) - Create a new Pay Run (for Abigail Peterson) - Open the last PaySlip and Validate - Create Payment Report (Export Format: SEPA) - Download the Payment Report and check the <InstrId> tags opw-6069670 Forward-Port-Of: odoo/enterprise#114821 Forward-Port-Of: odoo/enterprise#113113
This update fixes a minor display issue in the Helpdesk dashboard, ensuring that the 7-day average customer rating is shown as a score out of 5 instead of a percentage. This provides a clearer and more intuitive understanding of agent performance for users.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#115176 Forward-Port-Of: odoo/enterprise#109804
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, only in the Kanban view. The change ensures that contact types are consistently displayed in the user's preferred language across all views, improving user experience and data clarity. This was achieved by updating the field used to display contact information in the list view.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#115331 Forward-Port-Of: odoo/enterprise#114786
This update resolves an issue where testing custom Sign app configurations caused data conflicts. By creating unique role records for demo templates 2-6, the system now avoids overwriting configurations and provides a more accurate testing environment. This ensures consistent and reliable testing of Sign app features.
Original PR description
Before this commit, all demo templates in the Sign app shared the same global `sign.item.role` record (`sign_item_role_default`). When testing custom server actions or automations that attach configurations to a specific role, testing with demo data caused silent overrides. Modifying the automation for one demo template would overwrite the shared role record and break the automation for all other demo templates. This commit introduces unique `sign.item.role` records for demo templates 2 through 6. Template 1 retains the default role. This prevents data collisions during testing and better reflects a real-world database structure where different documents often utilize distinct roles. Task: 6128909
This update resolves an issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The fix now directly uses the partner ID from the invoice data, streamlining the process and preventing errors. This ensures smoother and more reliable invoice settlement operations.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#114927 Forward-Port-Of: odoo/enterprise#111957
This update resolves a technical issue preventing the 'Ask AI' graph view from functioning correctly. The fix ensures that AI-generated groupings are processed properly, preventing a crash and restoring the graph view's functionality. This improves the user experience when using the AI tools.
Original PR description
Steps to reproduce:
1. Install `crm`, `sale_management`.
2. Navigate to a list view (e.g. Sales > Orders).
3. Open the "Ask AI" chatbox from the system bar.
4. Ask: "graph view of opportunities per month".
5. [ISSUE] Client traceback after the agent loop tries to open the graph view with groupbys.
The pivot and graph AI tools emitted `rowGroupBys` / `groupBys`, but `search_model_patch` relies on `selectedGroupBys` (the key already used by the list/kanban tools). As a result, groupbys bypassed `applyAISearch` and, for graph, landed as raw `{field_name, intervals}` dicts in `modelParams.groupBy`, where `_normalize` crashed.
Rename the keys to `selectedGroupBys` so pivot/graph go through `applyAISearch` like list/kanban.
Task-ID: 6148879
Forward-Port-Of: odoo/enterprise#114802This update resolves an issue where portal users creating tickets via email would experience errors due to permission restrictions accessing employee calendars across different companies. The fix ensures the system correctly accesses calendar data, allowing ticket assignments to proceed smoothly. This improves the reliability of the helpdesk system for all users.
Original PR description
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the…
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment. This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read. If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated. The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation. Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there. Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender. A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds. Steps to Reproduce: 1. Install Helpdesk, Employees, and enable multi-company 2. Create two companies (e.g., Company A and Company B) 3. Create one internal user (User X) with access to both companies 4. Create two employees linked to the same user: - Employee 1 in Company A - Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee. 5. Create a Helpdesk team in Company A 6. Add Agent X as a team member 7. Enable automatic assignment 8. Configure an email alias for the helpdesk team 9. Create a portal user 10. Send an email from the portal user to the alias Related Ticket: opw-6035099 Forward-Port-Of: odoo/enterprise#114986 Forward-Port-Of: odoo/enterprise#113047
This update allows administrators to control when subscription users are automatically reset. Previously, this process was automatic and inflexible. By making it configurable, we provide greater control over user management for subscription-based customers.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update fixes an error in how degressive assets are depreciated when companies use shortened fiscal years. Previously, depreciation entries were incorrectly skipped for months within the wrong fiscal year. The fix ensures accurate depreciation calculations by correctly determining the start date of the next fiscal year, preventing missed entries and improving financial reporting.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113895 Forward-Port-Of: odoo/enterprise#113521
Code cleanup and technical improvements
This update enhances the testing environment for Odoo's Web Studio module. Specifically, it allows for a dedicated 'registry test mode' context, enabling developers to more reliably test and debug features within this area. This change improves the stability and quality of Web Studio development.
Original PR description
https://github.com/odoo/odoo/pull/259832