When someone replied to an app message that holds only a card, the quote above the reply showed the app's name and nothing else after the channel was opened or reloaded. The quote now shows the card's author, title, description, fields and footer, after a reload, inside threads and for replies that arrive while the channel is open.
Fixes#32361
Chat search checks the whole query and each word in it separately. With a single word those are the same check, so every chat got searched twice. It is now searched once, with the same results. On PostgreSQL with 2164 chats (533 MB of chat data) a one-word search is about 40% faster:
| search | before | after |
|---|---|---|
| proxy | 6.0 s | 3.6 s |
| opnsense | 6.1 s | 3.8 s |
| no match | 5.4 s | 3.0 s |
Refs #32266
Automation runs, timers and sub-agents stopped getting a reply after the shared chats rework: the chat shows an empty answer and the run fails with `409 Message already exists or has an invalid ID.` Each of them creates the empty answer before asking the model, and the backend began refusing to fill an answer that is already in the chat; the server-side API flow in the docs and API calls without a user message broke the same way. Such an empty answer is now filled in again when it belongs to the same user and answers the same message, and API calls without a user message work as before, saving the reply on its own as the docs describe. A firing timer or sub-agent also no longer cancels the chat's other timers that are set to stop when the user writes next. Answers that are already finished, or that belong to another user in a shared chat, are still refused.
Fixes#32066
Account creation times are stored in whole seconds. On Postgres, a user created in the same second as the first admin, which is normal when a script sets up an instance, could be picked as the primary admin. Other admins could then demote or delete the real first admin, nobody could edit, lock or delete that user, and pending users were shown that user as the admin contact. An admin account now wins a same-second tie against a regular one.
When a skill was saved several times within one second, its version history in the skill editor listed those versions in a shuffled order. This happens when a model edits a skill several times in one reply, or when an import replaces a skill right after it was created. Each new version now gets a save time at least one second later than the one before it, so the history keeps the order the versions were saved in. During such a burst, the shown save time runs ahead by about one second per extra save.
Fixes#32134
Searching Workspace > Skills only matched a skill's original name, description and id, so typing the German name given to a skill in its editor found nothing, even with the interface in German. The search now also matches the names and descriptions translated in the skill editor, in any language, so both the translated and the original name find the skill, as the Translations page in the docs says.
Fixes#32018
With All time selected, the Daily Messages chart in Admin Panel > Analytics failed to load (the daily analytics request returned a 500) as soon as one message had been saved without a timestamp, for example a chat created through the API with a null timestamp. A date range still worked because those messages were left out of it. Such messages now get the time they were saved, and ones already stored without a timestamp are counted on today's date instead of breaking the chart. Messages that came after the missing timestamp in the same chat were also left out of analytics before and are now counted.
Fixes#27316
When files were attached to a chat message and one of them was already attached to that chat (on the same message or another one), none of the new files were recorded as part of the chat, and nothing showed up in the logs. The sender still saw every file in their own chat, but anyone opening a shared copy of the chat could not open the new ones. Files already attached to the chat are now skipped and the new ones are recorded normally.
Fixes#31648
* fix: automation still shows "Last run Never" after "Run now"
Running an automation with "Run now" added the run to its history, but the automation page and the Automations list kept showing "Last run Never" (or the time of the last scheduled run). Only scheduled runs recorded a last run time. A manual run now records it too, so the automation page and the Automations list show the time of the run you just started.
Fixes#31580
* fix: show the new last run time right after Run now
The automation page now takes the automation the server returns after Run now, so the last run time updates on the spot and no reload is needed.
On PostgreSQL with ENABLE_ORJSON off (the default), searching automations by a word from their prompt, or filtering models by a tag, found nothing when the word was non-ASCII, for example Chinese. SQLite, and PostgreSQL with ENABLE_ORJSON on, were fine. With the default setting non-ASCII text is saved as \uXXXX codes, and PostgreSQL reads the backslash in a search pattern as a special character, so the search never matched. Special characters in the search text are now taken literally, so these searches work on both databases, and a % or _ typed into them now matches only itself.
Fixes#31422
