183 Commits

  • fix: knowledge file search finds nothing for escaped punctuation like Art\. 40 (#33936)
    When the model searched knowledge, chat or skill files with an escaped character such as Art\. 40, \(note\) or \$100, the search took the backslash literally and came back empty even though the text was there. A backslash in front of a regex special character now marks the pattern as a regex, so these searches find the text. Searches without a backslash, like C++, 1.5 or $100, still match exactly what was typed.
    
    Fixes #33933
  • feat: optional size limit for chat history tool results (#33695)
    * feat: optional size limit for chat history tool results
    
    Reading a long earlier chat through the Chat History tools could return far more text than a model's context window holds, so the next request failed. Admins can now set VIEW_CHAT_MAX_CHARS to cap what is returned. The newest messages are kept, older ones are dropped, and the result says it was cut and how many messages came back. Unset keeps the full chat as before.
    
    Fixes #33608
    
    * feat: set the chat read limit from the admin settings
    
    The limit on how much of an earlier chat a model can read could only be set with an environment variable. It is now a Chat Read Limit field in Admin Settings under General, next to the skill limits. The environment variable still works as the starting value, and the setting saved in the panel takes precedence.
    
    * fix: chat read limit failing on chats with empty or non-text messages
    
    With a chat read limit set, reading an imported chat that held empty or non-text message content ended in an error instead of the chat. Such content is now counted and cut as plain text.
  • fix: automation tool examples teach models a schedule format that gets rejected (#33732)
    The built-in tool for creating automations showed its example schedules with a literal backslash-n between the start time and the rule. Models copied that, and the schedule was rejected with an "Invalid RRULE" error, so they retried until they happened to write it differently. The examples now show a real line break, which is what the schedule parser expects.
    
    Fixes #33730
  • fix: reading a file by line range ignores the read size limit (#33696)
    Asking for a line range (for example the whole file by its last line number) returned every requested line, however large, so one tool call could exceed the model's context window and fail the chat. Line ranges now stop at the last whole line that fits the same limit as character reads, and report where to continue from.
    
    Fixes #33607
  • fix: file viewer tools ignore the end line when no start line is given (#33154)
    The view_file and view_knowledge_file built-in tools let a model ask for a start and end line, but passing only the end line did nothing: the tool returned the first block of characters and dropped the end line without a word. Models that asked for "up to line N" kept getting the same opening slice and no error, so they retried the call over and over. An end line on its own now reads from line 1 up to that line, the same result as passing start line 1 explicitly.
    
    Fixes #33100
  • fix: file reading tools skip text when paging with line numbers on (#33155)
    When a model reads a file or knowledge-base file in pages with line numbers turned on, the position it was told to continue from pointed past the end of the previous page, so a chunk of text between pages was silently skipped and never returned. The gap grew with every page, dropping a few percent of a large file. Reading now continues from the right place and returns every character exactly once; paging with line numbers off is unchanged.
    
    Fixes #33099
  • fix: misleading ask_user error when questions are not sent as a list (#32727)
    When a model sent the ask_user questions as anything other than a list, for example a JSON-encoded string, the tool answered "ask_user requires 1-3 questions." The model had sent the right number of questions, so it did not understand the error and often repeated the same call in a loop. It now gets a separate error saying the questions must be an array of question objects, and the count error only appears when the count is actually wrong.
    
    Fixes #32662
  • fix: external knowledge citation links lead to a not found error (#32233)
    Clicking the title of a citation from an external knowledge base (Qdrant, Milvus, pgvector), or its Content link, opened a link to a file inside Open WebUI that does not exist, so the browser showed a not found error. These results are no longer treated as uploaded files, so when the citation's source is a web address both links open that page, and otherwise the title is plain text. This works whether or not the model uses native tool calling.
    
    Fixes https://github.com/open-webui/open-webui/issues/32231
  • fix: reranker gets no user info headers in chat and knowledge search (#32061)
    With ENABLE_FORWARD_USER_INFO_HEADERS on and hybrid search enabled, rerank requests went out without the user headers when a chat searched attached knowledge, when a model used the built-in knowledge search tool, and when the collection query API was called with hybrid turned off for that one request. The embedding requests of the same search did carry them, so external rerankers that use these headers for per-user auth, rate limits or auditing saw anonymous calls. Rerank requests now carry the signed-in user, the same as embedding requests.
    
    Fixes #32060
  • refac: calendar event tools use the calendar's access check (#31537)
    Editing or deleting a calendar event through the chat tools now checks access to the event's calendar the same way the calendar API does.
  • feat: let operators expose chosen file metadata to the model in retrieved sources (#29696)
    Custom metadata attached to a file upload now reaches the vector DB, but the model still never sees it. Both prompt-assembly paths build their output from a fixed field set: the classic RAG <source> tag carries only id, name and resource type, and the retrieval tools return only content, source and file id per chunk. A scraper that records where each document came from therefore cannot get that origin in front of the model, so answers cannot state it.
    
    RAG_SOURCE_METADATA_KEYS names the chunk metadata keys allowed through to the model. Configured keys are emitted as extra attributes on the <source> tag and as extra fields on tool result chunks, covering both retrieval paths. It is empty by default, so nothing changes for existing deployments.
    
    An allowlist instead of passing everything through, because chunk metadata also carries file hashes, collection names, embedding config and relevance scores, which would then be added to every retrieved chunk of every request. Values are attacker-controllable through an uploaded file, so they are escaped before they go into the tag, and a configured key can never displace a field the tag or the chunk already defines.
    
    Reported in open-webui/open-webui#29486.
  • fix: tell ask_user models that the first option is shown as Recommended (#30196)
    The ask_user card badges the first option of every question as "Recommended", but nothing ever told the model that. The model picks whatever order it likes, so the badge really means "listed first" and users act on a recommendation the model never made.
    
    The ask_user tool description now states that the first option is labelled Recommended and that the model should list the option it recommends first, so the badge reflects an actual choice.
    
    Kept the badge and instructed the model instead of adding a per-option "recommended" flag: the flag would need a schema change, validation in the request normalizer and a frontend change, for the same result in the common case. Dropping the badge was the other option, but it removes a useful affordance rather than fixing it.
    
    Verified that the added line reaches the model by running the docstring through the tool-spec builder and checking the generated OpenAI function schema.
    
    Fixes #30195
  • fix: steer models to replace_range in the replace_note_content tool description (#30048)
    Asked to add a section or change a few lines, models answer with a whole-note
    replace_note_content call and the rest of the note is gone, with nothing to
    undo because the editor only records versions on chat inserts. The tool
    already supports replace_range operations with an expected guard, but its
    description never said when to use them or how the offsets work, so models
    defaulted to sending the whole note back.
    
    The docstring, which is the description every model receives for this tool
    in note chats and normal chats alike, now states the preference for range
    edits and the offset, overlap and expected rules the handler enforces.
    Verified the text lands in the generated tool spec unchanged and that range
    edits, the expected mismatch rejection and whole-note replace behave as
    described against a sqlite data dir.