v9.69 2026-06-23 WeKan ® release

This release fixes the following bugs:

• Can't edit a card's members in the UI after removing them via the REST API,
  #3697: clearing a card's members (or assignees) over REST left the
  field uneditable in the UI. The card PUT handler guarded with if (req.body.members) — falsy for the two natural
  clear payloads (null and "") — so "remove the last member" was a silent no-op, and its string branch was written
  to store null rather than []; a card with members: null then breaks UI code that treats it as an array. The
  handler now uses an !== undefined guard plus a shared coercion helper so any clear payload (null / "" / [])
  stores a clean String[] (never null), a single id is wrapped into an array, and stray non-string entries are
  dropped; getMembers()/getAssignees() also coerce a legacy null to [] on read so existing corrupted documents
  edit cleanly. Pure logic in models/lib/restArrayParam.js with a Meteor-free Node unit test
  (tests/restArrayParam.test.cjs, npm run test:unit:node, incl. a negative test reproducing the old
  null-writing logic), plus a REST regression in tests/playwright/specs/17-rest-api.e2e.js.
• Can't create a card with no member via the REST API,
  #2875: the card-create endpoints (POST .../cards and
  POST .../cards/bulk) wrote req.body.members/assignees straight to the insert with no normalization — the
  create-side twin of #3697 — so a null/"" payload persisted as null (breaking later UI editing). Both handlers
  now run the same coerceRestArrayParam helper: the field is omitted when not provided (so the schema default []
  applies), any clear payload becomes [] (never null), and a single id is wrapped into an array. REST regression in
  tests/playwright/specs/17-rest-api.e2e.js.
• Board created through the REST API shows in the API but not in the browser UI,
  #5650: POST /api/boards set the board's sole member's userId from
  req.body.owner with no fallback, so a request that omits owner created a board whose only member had
  userId: undefined. The board-list publication matches members.$elemMatch: { userId, isActive: true }, which can
  never match an undefined id — so the board was returned by the REST API but invisible in the browser. owner now
  falls back to the authenticated caller (req.body.owner || req.userId), mirroring the Meteor create method. REST +
  DB regression in tests/playwright/specs/17-rest-api.e2e.js.
• Copying a card to another board left its comments on the wrong board,
  #5166: CardComments.copy() cloned a comment but only changed its
  cardId, so a card copied to another board produced comments that kept the source board's boardId. Comment
  permission checks key off the comment's boardId, so edit/delete on a copied comment was validated against the wrong
  board, and any board-scoped query saw it on the old board. copy() now also sets the destination boardId (the
  author userId is intentionally preserved). Cross-board copy regression in
  tests/playwright/specs/17-rest-api.e2e.js. Note: the related "wrong author shown" symptom is a separate display
  issue — when a copied comment's author is not a member of the destination board, their user document isn't
  published there, so the UI can't resolve the name; adding those users to the board resolves it. A broader fix
  (publishing comment authors' minimal profile on boards where their comments appear) is left as a follow-up.
• Exception "Removed nonexistent document" when deleting a card detail,
  #3252 (partial): deleting a comment or checklist/checklist-item could
  throw Removed nonexistent document on the client. The delete handlers called Collection.remove(_id) directly, but
  under heavy archive/delete churn the target doc can already have been evicted from the client's Minimongo cache, and
  removing a missing _id throws. The comment / checklist / checklist-item delete handlers now check the doc still
  exists in the local cache before removing it
  (client/components/activities/comments.js, client/components/cards/checklists.js). The server-side
  before.remove hooks were already hardened to guard + log instead of throwing. (No automated regression for the
  thrown exception — the eviction race is not deterministically reproducible; the guard itself is a self-evident
  findOne-then-remove.) The high CPU on bulk delete the issue also reports is reduced by the cascade change below;
  the remaining cost is on the archive path (a bulk update, not a delete) and is a separate follow-up.
• Performance: deleting a card no longer fans out per-child activity churn (#3252,
  #5322). cardRemover removed a card's checklist items, checklists and
  comments with the hooked removeAsync, so collection-hooks fired each child's before.remove once per document —
  every one doing a getCard and inserting an activity (e.g. a removedChecklistItem per item), which then triggered
  the notification + publication observers. Deleting (or bulk-deleting) a card with many children produced an
  activity-insert storm and pegged the CPU. cardRemover now removes those children with .direct (skipping the
  per-child hooks — they only logged activities that are unviewable once the card is gone) and clears all of the
  card's activities in a single bulk op, which also removes the activities that a delete previously left orphaned. The
  deleteCard activity is still logged afterward (so the outgoing webhook fires), and attachments still go through the
  normal remove so their files are deleted. Cascade + activity-cleanup regression (also a negative test) in
  tests/playwright/specs/17-rest-api.e2e.js.

and this issue is verified resolved in current code (could not reproduce / no error observed here; re-test on the
reporter's data requested):

• #2292 (archiving a swimlane appeared to delete all its cards):
  Swimlane.archive() (models/swimlanes.js) only sets archived: true on the swimlane — it
  does not touch or delete the cards, and restore() brings the swimlane and its cards back. While a swimlane is
  archived its cards are merely hidden from the board view (board queries filter to archived: false swimlanes), not
  lost — the v2.27-era cascade described in the report no longer happens. (A dedicated way to view an archived
  swimlane's cards before restoring would be a separate UX improvement.)