After a successful registration the frontend auto-logs-in. With email
confirmation enabled that login fails with 412 (code 1012), which
surfaced as a raw "Request failed with status code 412" error in the
register form even though the account was created fine. Treat that case
as a success and tell the user to check their inbox instead.
The default-project creation triggered by the user-created event wrote the
stale in-memory user back with a full UpdateUser, racing registration and
sometimes resetting the status from "email confirmation required" back to
active. Only update the default_project_id column and keep the returned
user's status in sync with what was persisted.
Webhook target URLs like Discord's contain no break opportunities, so the
cell's min-content width forced the whole table past its container and
pushed the other columns out of view.
Fixes#3456
shouldShowTaskInListView() skipped the parent-in-view check for saved
filters, so a subtask expanded for context was rendered nested *and* as
its own top-level row, even when it did not match the filter.
The bypass was a stopgap for #2494 (a matching subtask was invisible when
its parent did not match). That is now handled in the backend by
buildSubtaskRootCondition, which returns such a subtask as a root, so the
frontend check is safe to apply to saved filters too.
Fixes#3462
Selecting an option unmounts the result list, so focus fell back to the
document body. On the task detail view, subsequent keystrokes were then
picked up by the global task shortcuts, which looked like focus jumping
to the description or assignee field.
Resolves#3464
Since e25295422 the subscriber loops in the comment, assigned, deleted and
project-created listeners logged a failed Notify and moved on. On SQLite the
insert regularly fails with "database is locked" (SQLITE_BUSY_SNAPSHOT: the
listener's deferred transaction cannot upgrade to a write once a sibling
listener has committed), so the notification was silently lost.
Return the error again so the events router retries the handler with a fresh
session, as it did before 2.5.0.
Reported at https://community.vikunja.io/t/notification-problems-since-2-5-0/4750
v1 queried on an already-committed session; v2 opened storage while
still holding the transaction. Both now load meta under the tx, commit,
then open the file. Addresses pr-swarm findings.
Preview generation reads the whole file (a network round trip on s3),
decodes and resizes it — seconds per image — while the request
transaction pinned a pool connection. A board full of image previews
could drain the pool. Commit first; the storage read needs no
transaction.
Querying the global engine while the request already holds an open
transaction acquires a second pool connection. Under concurrent
attachment downloads (e.g. a kanban board full of image previews) all
pool connections end up held by transactions that each wait for an
extra connection that can never be freed, hanging every request until
restart.
The redundant meta load in the upload avatar provider is removed
entirely; the decoded image is all that path uses.
kolaente
renovate[bot]andkolaente
dependabot[bot]andkolaente
Frederick [Bot]