v10.12 2026-07-21 WeKan ® release
This release fixes the following bugs:
- Fix: Docker fresh
docker compose upshowed "Connection reset by peer" and never
loaded (#6500). The compose ferretdb service downloads its binary on first run, so
it is not listening for a while after its container starts, but WeKan's
depends_onusedcondition: service_started(waits only for the container to
start, not for the database to accept connections) — so WeKan started against a
not-yet-ready database and failed. A healthcheck (a dependency-free bash/dev/tcp
probe of127.0.0.1:27017, with astart_periodthat covers a slow first
download) is added to the ferretdb service and WeKan now waits for
condition: service_healthy, matching the intent already documented in the
compose file.
Thanks to youhajjioui and xet7. - Fix: the admin Files report showed "No results" on FerretDB (every attachment was
hidden). Reproduced against a real FerretDB with the Mongo driver: older FerretDB
v1 builds reject{members:{$elemMatch:{userId,isActive:true}}}with "(BadValue)
unknown operator: userId", andaccessibleCardIdsused exactly that query while
the publication's catch swallowed the error, so the report silently returned
nothing. It now matches board membership by the dotted path{'members.userId': userId}(which works on every FerretDB build) and confirms the user's own member
entry is active in JS, preserving the exact$elemMatchsemantics; the publication
also no longer swallows query errors
silently.
Thanks to xet7. - Import always creates virtual users; map to real users later from the board
sidebar; imports can no longer hang. Board import no longer asks for member
mapping up front — every imported member is brought in as a virtual (placeholder)
user carrying its avatar, username and full name, added to the board inactive with
no permissions, and import runs immediately (single step, nothing to get stuck on).
Mapping a virtual member to an existing user is a deliberate, later action by a
board admin from the sidebar member-avatar popup ("Map to existing user"), and
cannot be used to gain privileges: it only maps a virtual member onto an existing
ACTIVE, REAL member of the SAME board and never changes that member's role (no new
membership, nothing escalated); it reassigns that virtual member's
cards/comments/activity on the board to the target and removes the placeholder.
Automatic hang mitigation bounds every import so it can never spin forever — a
client watchdog surfaces a timeout (and clears the spinner) and the server bounds
the import with the same deadline (WEKAN_IMPORT_TIMEOUT_MS, default 2 min) via a
new genericwithDeadlinewrapper. Covered by unit tests (no-escalation + auth
matrix, the deadline wrapper) and wiring
tests.
Thanks to xet7. - Fix: board/JSON import "Assign members" — typed suggestions appeared but could
not be selected, so a migrated board's members could not be mapped to existing
WeKan users (neither clicking nor Enter did anything). The "Select member" popup
mappedTemplate.currentData().__originalId, a field never set on the search
results (they are plain user documents with_id), so it mappedundefinedand
silently did nothing. It now maps the clicked result by its_id, and Enter
selects the first (highlighted) result so a name can be assigned by keyboard.
Member mapping stays optional — the step-1 "import without mapping" and the
in-step "skip mapping" buttons import immediately (unmapped members default to
the current user). Guarded by a
test.
Thanks to xet7. - Fix: cards not opening — clicking a card did nothing (#6493). The global
cleanFilename/downloadFilenametemplate helpers (which show every filename
safely) are registered byclient/components/main/safeFilename.js, but that module
was never imported on the client, so the helpers were never registered. Every
template using{{cleanFilename name}}— card attachment thumbnails and the admin
Files report — then threw "No such function: cleanFilename" during render, and on a
card with attachments that aborted the card's Tracker recompute so the card would
not open.client/features/main.jsnow importssafeFilename.jsso the helpers are
registered at startup; guarded by a
test.
Thanks to mueschel, brlin-tw and xet7.
Thanks to above GitHub users for their contributions and translators for their
translations.