Thursday, September 11, 2025
5 changes · master
Resolved issues and error corrections
Changing the signing order on a document now stays in place instead of reverting automatically. This ensures notification emails go to the right people at the right time, so documents are signed in the intended sequence.
Original PR description
### Issue: - When the signing order was changed, the changes were reverted back. - Because of this, emails were sent to the wrong users (those supposed to sign later got emails earlier). ### Fix: - Updated the `_compute_signer_ids` method to correctly compute and store the signing order. ### Impact: - Users will receive emails and can sign in the correct sequence according to the set signing order.
DHL and USPS delivery integrations now retrieve package details correctly from sales orders. This prevents shipping information errors and helps ensure accurate carrier processing for affected orders.
Original PR description
This commit fixes the same issue in #89771, but for sale orders instead of pickings. opw-4979982 Forward-Port-Of: odoo/enterprise#94186
AI chat and document features now handle invalid tool requests and usage limits more clearly instead of stalling or returning empty responses. This improves reliability for users by allowing the AI to recover from mistakes and by making failures visible when a request cannot be completed.
Original PR description
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an…
This commit introduces several related fixes to the LLM API service to make tool
call processing more robust and prevent silent failures.
- **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown
name, it previously resulted in an empty response, causing the conversation to
stall. This change ensures that a proper error message is now returned to the
LLM for the invalid tool call. This allows the LLM to process the failure and
continue the conversation.
- **Failing on Limits**: The query processing loop in `_request_llm` has limits
for both successive API calls and the number of tool calls per request.
Previously, these limits would be reached silently.
- **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached
without the LLM providing a final answer, a `ValueError` is now raised. This
prevents silent failures and makes it clear to the calling code that the
request could not be completed.
- **Tool Call Limit**: If the number of tool calls in a single response
exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now
provided with a result stating that the limit was reached. This gives the
LLM the opportunity to try the unprocessed tool calls again in a subsequent
turn.
- **Ignore Explanatory Text**: The text that LLMs often include alongside a tool
call request (the "thinking" text) is now ignored to provide a cleaner and
more concise final response to the user.The AI assistant can now correctly apply date filters when users ask for time-based information, such as orders from last month. This makes search results more accurate and avoids unreliable fallback behavior for common business queries.
Original PR description
Enable AI agent to handle date-based queries by adding date filter support to all terminating tool calls (open_menu_*, adjust_search). - Extract date filter info from search views in clean_search_view_xml() - Add date_filters parameter to all terminating tool methods and schemas - Update frontend handlers to process date filters via toggleDateFilter() - Fix param schema validator to support arrays of objects (required for date_filters) - Add tests for new array-of-objects schema validation - Update AI instructions with correct period IDs (month, quarter, year vs this_month) This allows natural language queries like "show orders from last month" to properly apply date filters instead of falling back to custom domains.
Creating a payroll run no longer fails for Swiss payroll users. This restores the expected payroll workflow and prevents an error that blocked pay run creation.
Original PR description
Currently on master when you try to create a pay run it creates a traceback, mentioning that _get_valid_version_ids is given 7 arguments and only 6 were taken, this probably happens because the overloaded function in Swiss l10n wasn't adapted task: 5082011