Creating a calendar event after 23:00 saved it ending on the day after the date picked, so it showed on two days. The new event form pre-fills an end time one hour from now, which falls on the next day, and that next-day end date was kept even when the event was set to other times. The end date now stays on the start date when the end time is later in the day than the start time. An event that ends after midnight or spans several days keeps its end date.
Fixes#31994
When a parameter like Temperature was switched to Custom in Chat Controls and then back to Default, the value saved in Settings > General was dropped and the model used its built-in default instead. Default now uses the Settings value again, also in chats where this already happened.
Fixes#32013
When Ollama rejected a new model in the Manage Ollama dialog, for example a model definition with no base model, the form cleared and showed no error, so the admin could not tell the model was never created or why. The dialog now shows Ollama's error and keeps the entered name and definition, so the admin can correct them and try again.
Fixes#32002
The Once schedule in the automation dialog filled in today's date in UTC but the browser's local time. When the browser's date differs from UTC's, the default was a day off: east of UTC it was yesterday, so Create failed with "RRULE has no future occurrences", and west of UTC it was tomorrow, so the automation ran a day late. The earliest selectable date had the same mix-up, so west of UTC today could not be picked. The default date and the earliest selectable date now both use the browser's local date.
Fixes#31999
An automation whose schedule stops after a number of runs or on a date lost that end the first time it was edited and saved, even when only the title changed, so it kept running forever. The Edit dialog showed such a schedule as a plain Daily, Weekly or Monthly one, and those options have no setting for an end, so saving wrote the schedule back without it. These schedules now open as Custom with the stored rule in its text field and are saved exactly as they were.
Fixes#32000
Creating a model in Admin Settings > Models > Manage Ollama from a base model that Ollama has not downloaded yet showed no download progress at all. The progress display hit an error in the browser the moment the download began, so the admin saw nothing until the model was created. The model name and a percentage bar that fills up as the download goes now show the whole time.
Fixes#32001
Picking Settings from the user menu with the keyboard left the focus on the menu item, which disappears as the menu closes. When Settings closed, the focus went back to that removed item, so it was lost and the next Tab started over at the top of the page. The menu now gives the focus back to the user menu button when it closes after an item is picked, the same as when it is closed with Escape, so closing Settings returns there.
Fixes#32017
Pasting an image into a note a moment after another change to that note was saved could lose the image. The note page got the result of the earlier save back after the paste and took over its older, empty list of attached files, so the image was saved without its file. After a reload it showed as a grey placeholder and was missing from the PDF export. The note page now keeps its own attached files while it still has a change waiting to be saved.
Fixes#32123
Stopping a reply did stop it, but the page kept showing it as still generating: the Stop button stayed and the next message was never answered. The same happened when sending a queued message right away with Send now. After the reply was marked finished, the page put back an older copy of it that was still marked as generating. Stopped replies now show as finished again, the Send button returns and the next message gets an answer.
Fixes#32081
In a new chat the reply sometimes stayed blank and looked like it was still generating, with the loading animation and the Stop button, even though the answer was complete on the server. Reloading the page showed it. It happened when the chat's new title arrived while the reply was still coming in: refreshing the chat list with the new title replaced the finished answer with a blank one. A title or tag update no longer overwrites the reply, so the finished answer shows as soon as it is done.
Fixes#32091
Screen readers announced the Response Splitting dropdown in Admin Settings > Audio without a name. It is now announced as "Select how to split message text for TTS requests". Nothing changes visually.
Fixes#32010
Exporting feedback as CSV from Admin Settings > Evaluations > Feedback left the chat_id column empty on every row. Each row now holds the ID of the chat the feedback was given in, the same ID that appears in the chat's URL.
Fixes#32021
Turning on Browser Notifications in a browser that blocks them showed an error, but the switch stayed on even though nothing was saved. The switch now turns back off when the browser denies permission.
Fixes#32024
When an admin changed a group's permissions, members who had the app open saw Workspace show up or vanish in their user menu right away, but the sidebar kept its Workspace entry as it was until they reloaded the page. The Notes, Calendar and Automations entries in the sidebar had the same problem. The sidebar now follows the change right away, like the user menu.
Fixes#32020
Pressing an action button whose function rewrites the reply, as the action docs describe, stored the new text with the chat but the chat kept showing the old reply, right away and after a reload. The reply now shows the new text, and its thinking and tool call sections stay visible. The action gets the reply as one text, so when the reply had text both before and after a tool call, all of it is replaced by the new text, shown after the tool calls.
Fixes#32023
On a phone, swiping right on a channel message to reply to it also opened the sidebar, which slid over the channel and covered the message. A swipe on a message now only starts the reply. On messages that cannot be replied to, for example in a read-only channel, the same swipe still opens the sidebar.
Fixes#32016
On a narrow phone screen, the Download choices in the chat header menu, in a chat's menu in the sidebar and in the note menu opened to the left of the menu, past the edge of the screen, with their labels cut off. When there is no room for them on either side of the menu, they now open over the menu, fully on screen. Where there is room beside the menu, they open as before.
Fixes#32015
The create menu's content is moved to document.body by Dropdown, which
puts its Create link outside the element where SvelteKit handles link
clicks, so the browser followed the link as a full page load. A plain
click now prevents the default and navigates with goto, the same way the
Create button and the user menu links do; modified clicks still open the
link in a new tab or window.
Select always placed its list on the requested side, so a list opened
near the bottom of the window (such as the model selector's filter
list) ran off the screen. It now flips to the other side when the
requested side is too short and the other side has more room, the same
check the shared Dropdown already uses.