v9.88 2026-07-13 WeKan ® release

This release adds the following new features:

• Added docs about new Sandstorm WeKan.
  Thanks to xet7.

and fixes the following bugs:

• Sandstorm build: fixed "not writing through dangling symlink" that failed the
  sandstorm.yml workflow at sandstorm-src/build-deps.sh step [3/7]. The
  meteor-spk 0.6.0 base ships some runtime libs in meteor-spk.deps/lib as
  DANGLING symlinks (e.g. libstdc++.so.6 → a library that no longer exists), so
  refreshing them with the host's newer libs failed: cp -fL refuses to write
  through a dangling destination symlink. Added --remove-destination so cp
  deletes the existing destination (dangling symlink included) before copying the
  host's real library. Thanks to xet7.
• Sandstorm build: write the signing keyring to the path meteor-spk pack
  actually reads. The sandstorm.yml "Restore the Sandstorm signing keyring"
  step wrote the decoded SANDSTORM_KEYRING secret to ~/.sandstorm/sandstorm-keyring,
  but meteor-spk / spk read the app private key from ~/.sandstorm-keyring (a
  file directly in $HOME), so packing aborted with
  open(~/.sandstorm-keyring): No such file or directory even when the secret was
  set. Now it writes ~/.sandstorm-keyring, and — since the .spk cannot be signed
  without it — fails early with an actionable message when the secret is missing,
  instead of the cryptic later crash. Thanks to xet7.
• Sandstorm .spk: trim it back toward Cloudflare's 100 MB upload limit. The
  Sandstorm build no longer bundles the ~300 MB of modern MongoDB Database Tools
  (wekan/mongo-tools) — they are unused in Sandstorm (grains back up/restore
  themselves; the MongoDB 3 → FerretDB migration uses the legacy migratemongo CLIs
  • the .mjs importer). Also set PUPPETEER_SKIP_DOWNLOAD=1 for the Meteor build
    (puppeteer is a test-only devDependency, so its ~150 MB Chromium never belongs in
    the .spk), and the pack step now prints the .spk size and warns if it exceeds
    100 MB. (The Database Tools remain in the WeKan .zip bundle / Docker / Snap,
    which do use them.) Thanks to xet7.
• Sandstorm .spk: bundle the matching glibc dynamic loader so grains start:
  the .spk bundled the host's new glibc libc.so.6 (Ubuntu 24.04, glibc 2.39)
  but kept the old glibc 2.31 ld-linux from the meteor-spk 0.6.0 base, so node
  failed at startup with libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE (HTTP-BRIDGE exit 127) and the grain crash-looped.
  sandstorm-src/build-deps.sh now also copies the host's ld-linux-x86-64.so.2
  so the loader and libc are the same glibc, and adds a [verify] gate that fails
  the build if they differ or the bundled node cannot run under them — turning a
  silent grain crash-loop into a loud build failure. Thanks to xet7.
• Sandstorm build workflow: enable unprivileged user namespaces and build the dispatched branch:
  Ubuntu 24.04 defaults kernel.apparmor_restrict_unprivileged_userns=1, which
  blocks the unprivileged user namespaces the Sandstorm install and the spk
  supervisor rely on, so sandstorm.yml now relaxes it on the runner. A new ref
workflow_dispatch input also lets the workflow build a fix branch before it is
  merged, instead of a hardcoded main. Thanks to xet7.
• Meteor unit tests: fix server-boot crash from __dirname in an ESM test file:
  server/lib/tests/dependencies.openapi.tests.js is an ES module that referenced
  the bare __dirname global; under Node 24 / Meteor 3.5 the compiler injects
  const __dirname = fileURLToPath(import.meta.url), colliding with the __dirname
  the CommonJS module wrapper already provides, so the server bundle failed to boot
  with Identifier '__dirname' has already been declared and the "Meteor unit
  tests" CI job died before any test ran. Drop the __dirname seed
  (process.env.PWD already reaches the repo root under meteor test). Thanks to xet7.
• Sandstorm .spk: point FerretDB state dir to writable /var so the grain starts:
  FerretDB persists a state.json (version/UUID) via its state provider even with
  telemetry disabled, and its --state-dir defaults to . — which in a Sandstorm
  grain is /, read-only. So FerretDB failed with Failed to create state provider: failed to persist state: open /state.json: read-only file system,
  exited (code 1), and the grain crash-looped. sandstorm-src/start.js now creates
  /var/ferretdb and passes --state-dir=/var/ferretdb (plus FERRETDB_STATE_DIR)
  in startFerret(), covering both the migration and steady-state FerretDB launches.
  Thanks to xet7.
• Sandstorm .spk: don't crash the grain when capnp.node can't load on Node 24:
  WeKan on Sandstorm bundles Node 24, but capnp.node (node-capnp) is built for an
  older Node ABI (NODE_MODULE_VERSION 83 = Node 14), so Npm.require('capnp') in
  sandstorm.js failed with ERR_DLOPEN_FAILED and crash-looped the whole grain on
  boot. Cap'n Proto is now loaded lazily in a try/catch and degrades gracefully:
  the grain boots and core WeKan works, because login and user identity come from
  the sandstorm-http-bridge X-Sandstorm-* HTTP headers (wekan-accounts-sandstorm)
  and need no Cap'n Proto. Only the two capnp-only features are skipped when the
  addon cannot load — the Powerbox identity-claim method and Sandstorm activity
  notifications — with a clear warning. They can be restored by rebuilding node-capnp
  for Node 24, or reimplemented over the bridge's HTTP/JSON API. Thanks to xet7.
• Snap release: build amd64+arm64 natively on GitHub, exotic arches non-blocking on Launchpad:
  the single snap job ran snapcraft remote-build for all 5 platforms on Launchpad
  and blocked until the slowest resolved, so the release hung ~3.5h on riscv64's
  Launchpad queue even though amd64+arm64 finished in minutes. It is now split in
  two: snap-native builds amd64 (ubuntu-24.04) and arm64 (ubuntu-24.04-arm)
  natively on GitHub runners via snapcore/action-build; snap-launchpad builds
  s390x/ppc64el/riscv64 on Launchpad in a non-blocking (continue-on-error),
  per-arch matrix (remote-build --build-for <arch>) so a slow or failed exotic
  arch never delays the release or the other arches. Each arch publishes to the
  Snap Store (candidate,beta,edge) and attaches to the GitHub Release the moment it
  finishes — all 5 arches still ship. Thanks to xet7.
• Sandstorm .spk: fix server-boot crashes from stale globals (Users, HTTP) in sandstorm.js:
  once the capnp load was made non-fatal, the grain reached the rest of
  sandstorm.js and hit two latent Meteor-2.x-isms the Meteor 3.x migration missed
  (this file only runs on Sandstorm, so it was not exercised): it referenced the
  Users/Boards/Swimlanes/Activities collections as implicit globals, but
  those are now ES module default exports, so Users.after.insert threw
  Users is not defined at boot; and it monkey-patched HTTP.methods from the
  removed meteor/http package, so HTTP was undefined. The collections (and
  Accounts) are now imported explicitly, and the obsolete HTTP.methods patch is
  removed. Thanks to xet7.
• Sandstorm .spk: use boolean index options so FerretDB accepts the users index:
  wekan-accounts-sandstorm created the unique index on services.sandstorm.id
  with {unique: 1, sparse: 1}. Real MongoDB accepts the truthy 1, but FerretDB
  (used by the Sandstorm .spk) is strict and rejects it with The field 'unique' has value unique: 1, which is not convertible to bool, crashing the grain at boot
  during index creation. Now uses real booleans (unique: true, sparse: true).
  Thanks to xet7.
• Sandstorm .spk: strip Accept-Encoding so the grain doesn't serve corrupted (gzip) content:
  the grain boots, but the page failed to load with a browser "Corrupted Content
  Error" (NS_ERROR_NET_CORRUPTED_CONTENT). sandstorm-http-bridge advertises
  Accept-Encoding: gzip to the app regardless of what the browser actually sent,
  so Meteor served gzip/brotli-encoded responses the browser could not decode. A
  WebApp.rawHandlers middleware now strips Accept-Encoding (it runs before
  Meteor's static/boilerplate serving) so responses go out uncompressed; bandwidth
  is a non-issue behind the local bridge. Thanks to xet7.
• Sandstorm .spk: bundle a modern sandstorm-http-bridge to fix "Corrupted Content":
  the grain boots, but the page failed with a browser "Corrupted Content Error"
  (NS_ERROR_NET_CORRUPTED_CONTENT) on WeKan's / redirect. The meteor-spk 0.6.0
  base bundles an ancient (~2016) sandstorm-http-bridge that mangles responses
  (it always advertises Accept-Encoding: gzip to the app and mishandles
  redirect/encoding). build-deps.sh now overwrites the bundled
  /sandstorm-http-bridge with the modern one from a Sandstorm install
  (/opt/sandstorm/latest/bin/sandstorm-http-bridge; override with
  SANDSTORM_HTTP_BRIDGE), and sandstorm.yml installs Sandstorm before assembling
  the deps so the bridge is available on the CI runner. Thanks to xet7.
• Sandstorm .spk: fix the "/" redirect (malformed Location + Content-Length mismatch):
  the grain's / served a broken 301: the Location was .../:6080board because
  FlowRouter.path() does not resolve on the server in Meteor 3.x (it returned the
  bare route name board), and the response advertised Content-Length: 90 while
  sending an empty body — which the browser rejected as a "Corrupted Content Error"
  (NS_ERROR_NET_CORRUPTED_CONTENT). The handler now builds the board path directly
  (/b/:id/:slug) and sends a real HTML body (meta refresh + link) with a matching
  Content-Length, so the redirect to the hard-coded Sandstorm board works. Thanks
  to xet7.
• Sandstorm .spk: open the grain on the All Boards page, not a hard-coded board:
  WeKan on Sandstorm originally opened a single hard-coded board
  (/b/sandstorm/libreboard) and redirected / to it. It now supports many boards
  and that board is no longer the right destination, so the WebApp.handlers.get("/")
  redirect is removed entirely — / now falls through to WeKan's normal serving,
  whose client home route renders the All Boards list, the right landing page
  for a multi-board grain. This also removes the last server-side redirect the
  browser was rejecting as a Corrupted Content Error. Thanks to xet7.
• Sandstorm .spk: don't auto-create a board; map grain permissions to global role:
  a new grain/user no longer gets a hard-coded sandstorm/libreboard board
  auto-created — WeKan on Sandstorm is multi-board now, so the user creates their own
  boards from the All Boards page. updateUserPermissions previously added the user
  as a member of that single board (which would now crash since the board no longer
  exists); it now maps the grain's Sandstorm permissions to the user's global
  WeKan role — configure (grain owner) becomes a WeKan admin, everyone else is a
  regular user who can create and manage their own boards. Thanks to xet7.
• Sandstorm .spk: set SANDSTORM=1 so the header-based auto-login runs:
  WeKan loaded in the grain but every page showed "Must be logged in". The
  wekan-accounts-sandstorm client only starts the automatic X-Sandstorm-* header
  login when __meteor_runtime_config__.SANDSTORM is set, and the package only sets
  that when process.env.SANDSTORM is present — which nothing did. The launcher now
  sets process.env.SANDSTORM = '1' before loading the WeKan bundle, so the client
  auto-logs-in the Sandstorm user from the headers. Thanks to xet7.
• Sandstorm .spk: rewrite ROOT_URL per request to the grain URL (fixes login + CORS):
  WeKan loaded but stayed on "Must be logged in", and the console showed
  Cross-Origin Request Blocked … http://127.0.0.1:4000/__meteor__/dynamic-import/fetch.
  The launcher sets a fixed ROOT_URL (http://127.0.0.1:4000, the internal bridge
  target), but Sandstorm serves each grain at a per-session host
  (ui-<hash>.<host>), so the client sent its DDP connection and dynamic-import
  fetches to 127.0.0.1:4000 — cross-origin and unreachable — and the header-based
  login handshake (a DDP method call) never completed. A WebApp.addRuntimeConfigHook
  now rewrites ROOT_URL to the grain's real base URL (X-Sandstorm-Base-Path) per
  request, so DDP, dynamic imports and the Sandstorm auto-login work. Thanks to xet7.
• Sandstorm .spk: bounce from sign-in to the boards list once auto-login lands:
  the Sandstorm login was actually succeeding (Meteor.userId() gets set), but the
  grain stayed on the sign-in page. WeKan's home route checks Meteor.userId() once
  and, because the Sandstorm header login is asynchronous and uses
  connection.setUserId() (bypassing accounts-base, so Accounts.onLogin never
  fires), finds it still null on first render and redirects to atSignIn — where the
  user is stranded even after login completes. A Sandstorm-only reactive autorun now
  sends the user from atSignIn back to home as soon as Meteor.userId() is set,
  so the grain lands on the All Boards page. Thanks to xet7.
• Sandstorm .spk: keep the grain URL in sync with the in-app route:
  navigating between boards worked but the Sandstorm shell's grain URL never updated
  (it stayed on the grain root), unlike standalone WeKan. The path was synced via a
  global FlowRouter.triggers.enter callback, which does not fire reliably on client
  navigation in this flow-router-extra / Meteor 3 setup; it is now synced from a
  reactive Tracker.autorun on FlowRouter.watchPathChange() (the same mechanism
  the title sync uses), so every route change updates the grain URL to
  /grain/<id><path>. Thanks to xet7.
• Sandstorm .spk: upload attachments over DDP (bridge strips Meteor-Files' HTTP headers):
  adding a file to a card in the grain failed with HTTP 400 Can't continue upload, session expired [408] and the file silently disappeared. Meteor-Files' HTTP
  upload signals the first chunk with an x-start header and tracks the session
  with x-mtok/x-chunkid/x-fileid/x-eof, but Sandstorm's request-header
  whitelist does not include them, so the sandstorm-http-bridge strips them — the
  server never sees x-start, treats every request as a chunk continuation, cannot
  find the session and returns 408. Attachment uploads now use transport: 'ddp' on
  Sandstorm (DDP method calls, no custom HTTP headers); HTTP transport is kept
  everywhere else. Thanks to xet7.
• Sandstorm .spk: authorize attachment/avatar downloads via X-Sandstorm-User-Id:
  once uploads worked, the uploaded image still showed as a broken thumbnail,
  minicard cover and slideshow in the grain — the file was on disk but the download
  returned HTTP 403. The download route (server/routes/universalFileServer.js)
  authorizes files on private boards with a Meteor login token (Authorization /
  X-Auth-Token / authToken query / meteor_login_token cookie), but Sandstorm has
  none of these: authentication is via connection.setUserId() and the
  sandstorm-http-bridge X-Sandstorm-* request headers, so extractLoginToken()
  returned null and isAuthorizedForBoard() denied every request. Sandstorm already
  gates grain access at the platform level, so any request that reaches WeKan is an
  authenticated grain user — both isAuthorizedForBoard() and
  isAuthorizedForAvatar() now allow when Meteor.settings.public.sandstorm is set
  and the request carries the bridge-injected X-Sandstorm-User-Id header. Gating on
  the setting means a spoofed header cannot bypass auth on non-Sandstorm deployments.
  Thanks to xet7.
• Sandstorm .spk: open All Boards (not sign-in) and keep the grain URL in sync:
  two grain-navigation regressions against the last working Sandstorm build (v6.15).
  (1) Opening a grain showed "Must be logged in" instead of the All Boards page: on
  Sandstorm the platform authenticates the user asynchronously over DDP via
  connection.setUserId(), which (unlike a password login) does not set
  Meteor.loggingIn(), so Meteor.userId() is null for the first moments after the
  grain opens — and useraccounts' ensureSignedIn trigger plus renderBoardList()
  both bounced that brief null window to the atSignIn route, a sign-in page that
  does not exist inside a grain. config/router.js now uses a Sandstorm-aware
  ensureSignedInUnlessSandstorm wrapper (a no-op on Sandstorm) and
  renderBoardList() no longer redirects on Sandstorm; the list renders and fills in
  reactively once the login lands. (2) The Sandstorm shell's outer grain URL did not
  update when switching boards — the shell rewrites /grain/<id><path> when the app
  posts a { setPath } message, but the sync was a bare top-level Tracker.autorun
  that could run before flow-router-extra's reactive path tracking was ready and then
  never re-run. Restored v6.15's event-driven FlowRouter.triggers.enter (fresh
  entering path, order-independent) and kept a watchPathChange() autorun wrapped in
  Meteor.startup as a backup. Thanks to xet7.
• Sandstorm .spk: fix the MongoDB 3 → FerretDB migration of an existing grain:
  importing an old WeKan grain crash-looped in the one-time migration — mongod 3.0
  forked and its child aborted with exit code 14. Two bugs. (1) WiredTiger
  cache_size=0G: mongod 3.0 sizes its WiredTiger cache from detected RAM
  (RAM/2 − 1GB), but inside a Sandstorm grain sandbox RAM detection returns 0, so it
  computed cache_size=0G and WiredTiger refused to open (minimum is 1MB), logging
  "Value too small for key 'cache_size'" / "Fatal Assertion 28561" to
  /var/migration-mongod.log before aborting. Both mongod invocations (the niscu →
  3.0 stage and the 3.0 → FerretDB stage) now pass an explicit
  --wiredTigerCacheSizeGB 1 so the cache size never depends on RAM detection
  (mongod 3.0.7 parses this option as an integer number of GB — a decimal like 0.25
  fails with Bad digit ".", fixed to 1 —
  and it is a cache cap, not a preallocation). The data
  itself is intact (the "unclean shutdown" notice is harmless —
  WiredTiger recovers from the last checkpoint). (2) Wrong source database:
  Sandstorm WeKan grains store their data in the Meteor-default database meteor, but
  the importer was told SRC_DB=wekan, so even once mongod started it would have
  exported zero collections; only the FerretDB target database is wekan. Thanks to
  xet7.
• Sandstorm/Snap migration: import mongodb and bson as default (CommonJS) exports under Node 24:
  with the WiredTiger cache fixed mongod 3.0 started and the migration importer ran,
  but crashed immediately on its named imports — import { EJSON } from 'bson' and
  import { MongoClient } from 'mongodb' each threw "Named export '…' not found. The
  requested module is a CommonJS module". Both packages, as bundled in WeKan's server
  node_modules, are CommonJS, so Node 24's ESM loader exposes no named exports on
  them. Import the default and destructure, as Node's own error message advises (bson in
  the commit linked above; mongodb in the same way).
  Shared by the Snap MongoDB 3 → FerretDB migration too (same Node 24). Thanks to xet7.
• Sandstorm/Snap migration: connect mongoexport over IPv4 so it can read the old data:
  with the importer finally running, every mongoexport of a source collection failed
  — at first silently (its own --quiet flag suppressed the reason),
  and once that was
  dropped the real error showed: "error connecting to db server: no reachable
  servers". mongoexport is a Go tool whose --host defaults to localhost, which
  resolves to ::1 (IPv6) first, but the migration mongod listens only on
  --bind_ip 127.0.0.1 (IPv4); the mongo shell defaults its host to 127.0.0.1 and so
  connected fine (it listed all 42 collections), which is why only the shell worked.
  Pass --host 127.0.0.1 explicitly. The one-time progress dashboard also now shows a
  live Activity panel (mongoexport-ready line, per-collection export/insert counts, GridFS
  extraction counts) with a spinner and an auto-updating timestamp,
  so it is
  clear what the migration is doing rather than sitting on "(waiting…)". Thanks to
  xet7.
• Sandstorm/Snap migration: resolve bson/mongodb from the modern server bundle so EJSON exists:
  once mongoexport connected, every collection failed with "Cannot read properties of
  undefined (reading 'parse')" — EJSON was undefined. The importer script sits at the
  deps root right next to the OLD meteor-spk 0.6.0 base node_modules (kept only for the
  niscu → 3.0 stage): its bson is 1.x with no EJSON at all, and its mongodb is
  ancient — it has MongoClient (so the connection worked) but no EJSON re-export. A
  bare import/require from the script resolved those adjacent old copies, so every
  way of reaching EJSON (bare bson, mongodb.EJSON) came back undefined. WeKan's
  current bson 7.3 and mongodb driver (with EJSON) live under
  programs/server/npm/node_modules; anchor createRequire
  inside that modern bundle
  first (falling back to the deps root) and load both mongodb and bson through it —
  which also moves the importer to the same modern mongodb driver the WeKan app uses
  against FerretDB. An upfront guard fails loudly with a diagnostic list if EJSON.parse
  is still unreachable. Thanks to xet7.
• Sandstorm/Snap migration: insert into FerretDB with the modern mongodb driver (OP_MSG):
  text collections exported and "inserted N/N" was logged, but every document actually
  failed with "Unsupported OP_QUERY command: update" — nothing reached FerretDB.
  requireAny('mongodb') had resolved the ancient meteor-spk base driver (v2.x, at the
  deps root) because the modern driver is not directly under
  programs/server/npm/node_modules — Meteor nests it at
  …/meteor/npm-mongo/node_modules/mongodb (v6.16). The 2.x driver speaks legacy
  OP_QUERY, which FerretDB rejects; the 6.x driver speaks OP_MSG (the same driver the
  WeKan app uses against FerretDB). Add the npm-mongo path as the first resolver anchor,
  and log the resolved driver version. Thanks to xet7.
• Sandstorm/Snap migration: extract Meteor-Files GridFS attachments + parse legacy v1 binary:
  with text migrating, attachments still produced 0 files and "parse attachments.chunks:
  Unexpected Binary Extended JSON format". Two causes. (1) mongo 3.x mongoexport writes
  binary as legacy Extended JSON v1 {"$binary":"<b64>","$type":"00"}, but modern bson
  EJSON.parse only accepts v2 {"$binary":{"base64":…,"subType":…}} — rewrite v1→v2 per
  line before parsing. (2) The grain stores attachments in Meteor-Files' own GridFS buckets
  (attachments.files + attachments.chunks, with the FilesCollection record in the
  attachments collection), not CollectionFS's cfs_gridfs.*. Reassemble those buckets to
  disk, link each GridFS file to its record via metadata.fileId/versionName, then repoint
  the record's versions.<v> at the file and drop versions.<v>.meta.gridFsFileId —
  otherwise WeKan's getFileStrategy keeps choosing the now-empty GridFS backend and the
  image 404s. Verified end to end on a real grain: boards/cards/lists/swimlanes migrate and
  all 3 attachments extract and display. Thanks to xet7.
• Sandstorm/Snap migration: auto-open All Boards after migrating, WeKan-themed dashboard:
  the one-time progress dashboard used to sit on the grain URL for 60s after completion,
  forcing a manual reload to reach WeKan. On success the importer now hands off quickly and
  the done page polls / until WeKan's app shell answers (riding out the brief
  importer→WeKan port hand-off) and then opens All Boards, with the spinner still spinning so
  it is clear the grain is still working. The dashboard is also recoloured to WeKan's
  blue/white/grey. Thanks to xet7.

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