v9.78 2026-07-06 WeKan ® release

This release fixes the following bugs:

• Fix “Internal Server Error” when signing up despite the account being created: Registering a new account showed a red “Internal server error” on the sign-up form even though the account was created and could sign in — which typically happens when SMTP is not configured. Root cause: useraccounts’ ATCreateUserServer creates the account and then calls Accounts.sendVerificationEmail() (because sendVerificationEmail: true); when SMTP is missing/misconfigured that send throws after the user row is inserted, and with no try/catch the exception leaves the createUser method as an opaque HTTP 500. The verification email is best-effort at sign-up, so Accounts.sendVerificationEmail is now wrapped to log and swallow a transport failure — registration completes and redirects to sign-in — while an “already verified” error is re-thrown so the resend-verification flow still reports it. This mirrors the #5706 reset-password hardening. Covered by tests/verificationEmail.test.cjs. Thanks to Firas-Git and xet7.

• Fix can not add members to a Linked Card: A linked card (created by “Link card to this card”) is only a placeholder on the board that links it — its members are stored on the real card it points at (linkedId), which lives on another board, and Card.getMembers() / assignMember() / unassignMember() already read and write that real card. But the member picker listed the members of the board you were viewing the linked card on, not the board the real card lives on. So on a board that links a card from another board, the picker offered the wrong set of members and toggling them did not behave as a consistent add/remove — “can not add members to the linked card”. The picker now resolves a linked card to its real card’s board and offers that board’s active members (matching where the membership is actually stored), falling back to the current board for normal cards or when the real card isn’t loaded yet. Extracted the target-card/target-board resolution into models/lib/linkedCardMembers.js, covered by tests/linkedCardMembers.test.cjs. Thanks to ITT5 and xet7.

• Fix can’t search numbers in custom fields: Searching a board for the value of a number or currency custom field (e.g. a transaction number 2025001, or a currency amount 123) found nothing. Those field types store their value as a JS Number (the inputs save parseInt(...) / Number(...)), but Board.searchCards() only matched custom fields with { value: <regex> } — and a MongoDB / Minimongo regex only matches string values, so it silently skipped every numeric custom field. The search now also adds an exact numeric-equality clause when the term is a plain number (a comma is accepted as a decimal separator, matching the currency input), so numeric custom fields match too; text/title/description matching is unchanged. Card search runs against Minimongo on the client, which — like MongoDB — cannot regex a numeric field, so equality is the correct cross-environment match. Covered by tests/cardSearch.test.cjs. Thanks to MarcusDger and xet7.

• Fix “Removed nonexistent document” crash during notification_cleanup: The scheduled notification-tray cleanup logged Exception in removed observeChanges callback: Error: Removed nonexistent document …. The crash itself came from the old cottz:publish-relations package (since replaced by reywood:publish-composite), but the cleanup that provoked it still fired one un-awaited removeNotification() per expired notification — a separate Users.update $pull each time — so a user with K stale notifications produced K writes to the Users collection, and every publication that republishes user documents re-ran its observers K times in quick bursts (the churn that surfaced the removed-document error), while any rejected write went unhandled. The cleanup now scans only users that have notifications and prunes each user’s stale notifications in a single awaited $pull … $in. It also removes an activity’s notifications only when every entry for that activity is read and past its removal age (so a freshly re-created unread notification sharing an activity id is not dropped), and guards missing/invalid read timestamps. Covered by tests/notificationCleanup.test.cjs. Thanks to xet7.

• Fix impossible to select another board in rules: In the IFTTT-Rules “Move card to the board” and “Link card to the board” actions, the board dropdown was empty for some users — the current board included — while colleagues in the same company could pick boards normally. Root cause: the dropdown filtered the (already access-scoped) client cache with 'members.userId': me, i.e. it only kept boards where the user has a direct member entry. A user who reaches a board through an Organization, Team or email-domain share — but is not listed individually in board.members — matched nothing, so the whole selector came up empty. The dropdown now filters by the same visibility rule as Boards.userBoards() (public OR active member OR active org OR active team OR active domain), so org/team/domain-shared boards appear too, while archived boards, template containers, the user’s templates board and internal helper boards stay excluded. Thanks to Augustin356 and xet7.

• Fix board disappeared after adding another user: A board admin adding another user could make the whole board silently vanish from a user’s board list, with no archive and “nothing out of order” in the logs. Root cause: the setBoardTeams server method (used by the board Teams/Members management popups) blindly overwrote the board’s entire members array with a snapshot sent by the client. When that client’s board document was stale — e.g. a member had just been added via inviteUserToBoard on the server and the change had not yet propagated to the client — the overwrite dropped members, and in the worst case the board’s own admin, so the board no longer matched the board-list publication (which requires an active membership) and disappeared. Because a wholesale $set: { members } never passes through foreachRemovedMember(), no removeBoardMember activity was logged and no card/watcher/star cleanup ran, which is why the logs looked normal. setBoardTeams now reconciles against the authoritative server-side members instead of trusting the client snapshot: it never drops an active admin, keeps every existing member the client still lists, adds the members the client introduces, and only removes non-admin members the client explicitly omitted (an intentional team-leave) — logging and cleaning up each such removal so it is auditable rather than silent. Thanks to DVNBLMHC and xet7.

Thanks to above GitHub users for their contributions and translators for their translations.