The armhf snap failed all three attempts in v10.77 while s390x, ppc64el
and riscv64 each built on attempt 1. The Launchpad build log says why,
one line into the mongodb part:
Stage package not found in part 'mongodb': libcurl4.
Build failed
Ubuntu 24.04's 64-bit time_t transition renamed the library, and
`libcurl4` is not a real package on ANY architecture in noble - the
binary is `libcurl4t64` everywhere. On the 64-bit architectures the
renamed package keeps the old name alive:
Package: libcurl4t64
Architecture: amd64
Provides: libcurl4 (= 8.5.0-2ubuntu10)
and the armhf libcurl4t64 has no Provides line at all, because there the
ABI really changed. That is what makes this class of bug reach exactly
one architecture, which is also what makes it look like flakiness on
that architecture.
It had already happened, to libssl3 and libgoogle-perftools4 in v10.71;
the comment above this list describes it exactly. libcurl4 was the same
transition and was left behind. Every other stage-package was checked
against the noble armhf main+universe indices at the same time - all 14
of them - and libcurl4 was the only one that did not resolve.
The workflow's own guidance made it worse. snapcraft ends a missing
stage-package as a "Stopped" build with no artifact, which from the
outside is indistinguishable from Launchpad cancelling a build, so the
message said "often an OOM in the Meteor npm install, or a transient
build-farm reset ... re-run, and if it persists on this arch open a
Launchpad question" - the wrong advice for a failure that will never
succeed on a re-run. The step now looks for the line first, names the
package that is missing, says it is NOT transient, explains the t64
Provides asymmetry, and gives the one-line archive query that checks a
name.
New test tests/snapStagePackages.test.cjs, 6 checks: no stage-package is
a known pre-t64 name, libcurl is asked for by the name noble publishes,
the two fixed in v10.71 have not regressed, and - negatively - a name
that was never renamed keeps its plain name, because the rule is not
"add t64 to everything". It also pins that the reason stays written down
beside the list. Verified it fails when libcurl4 is put back.
Thanks to xet7 !
Four things the v10.77 run got wrong, all of them silent - nothing
errored, the reports were simply not what they claimed to be.
THREE GOOD SNAPS WERE REPORTED AS FAILED. s390x, ppc64el and riscv64
each printed "Remote build <arch> succeeded on attempt 1" and downloaded
their .snap, and each job then ended FAILED - because the step that
SAVES the build log could not upload it:
The path for one of the files in artifact is not valid:
/snapcraft-wekan-f82a93c2…_s390x_2026-08-09T11:39:05.txt.
Contains the following character: Colon :
snapcraft names a remote-build log after the recipe and an ISO
timestamp, and upload-artifact refuses a colon because NTFS cannot hold
one. The colons become dashes now, so the timestamp is kept rather than
the name thrown away - and the upload is continue-on-error, because a
DIAGNOSTIC upload must never be able to fail the build it is diagnosing.
The snap is the deliverable; the renaming is not the last thing that
could ever make a log file unuploadable.
EVERY ROW OF THE PROVENANCE TABLE APPEARED TWICE. provenance-table.sh
globbed `provenance/**/*.tsv provenance/*.tsv`, and with globstar `**/`
matches ZERO or more directories, so the first pattern already covered
the second and every file was read twice. It is one pattern now, and
rows are also deduplicated on the WHOLE line - a retried step or a job
that ran again records an identical line, and nothing tells the copies
apart. Deliberately not `sort -u -k1,1 -k2,2`: two rows sharing a bundle
and a binary but differing elsewhere are not a duplicate, they are a
real disagreement about which Node.js went into a bundle, and hiding one
at random is worse than showing both.
AMD64 WAS MISSING FROM THAT TABLE - the platform most people download.
Its step runs `cd .build` before `mkdir -p provenance`, so the rows went
to .build/provenance while upload-artifact looked at provenance/ from
the workspace root and found nothing: "No files were found with the
provided path: provenance/". Every other build job records from the
workspace root, which is why only this one was affected. It uses
$GITHUB_WORKSPACE now.
SIX PLATFORMS SAID VERSION "LATEST". amd64, arm64, win64, win32,
mac-arm64 and mac-x64 passed the literal string; only the
extra-architecture job asked which version `latest` actually was, and it
did so with its own inline curl+python. "Which FerretDB did v10.77 ship"
is the one question that column exists to answer. All seven sites now
call the new releases/ferretdb-latest-tag.sh, which asks once per job
and caches, authenticates when there is a token so a shared 60/hour
limit is not what makes it fail, checks that the answer is shaped like a
tag before printing it into a markdown cell, and prints NOTHING and
exits 0 when it cannot find out - the caller's ${FERRET_TAG:-latest} is
then exactly what it had before. A release note must never fail a build
that produced a good bundle.
The table's own prose linked [wekan/node](https://github.com/wekan/node);
the binaries come from wekan/node-patches, which is what the rows
themselves already linked.
New test tests/provenanceTable.test.cjs, 20 checks, most of them running
the scripts rather than reading them. Verified in both directions: with
the doubled glob restored the glob guard fails, with amd64's relative
path restored its guard fails, and with the literal 'latest' restored
its guard fails.
Thanks to xet7 !
WeKan ships binaries other projects publish - FerretDB, the MongoDB
Database Tools, Node.js - and fetches each from a release URL. There are
many such URLs, across workflows, release scripts and compose files, and
they must all agree: one that names a fixed version stops receiving
security fixes silently, and nothing about the build fails when it does.
That is not hypothetical. A Quay scan of the v10.77 image reported Go
advisories in the FerretDB binary baked into the bundle - stdlib 1.25.9
wanting 1.25.11, golang.org/x/sys v0.38.0 wanting 0.44.0. The source was
already fixed and v1.48.0 was already published carrying go1.25.11 and
x/sys v0.46.0; the image had simply captured an older latest at build
time. Had any of these URLs been pinned instead, the rebuild would not
have fixed it either.
The test finds the URLs by searching the repository rather than from a
list, so a build site added later is checked too, and it accepts three
shapes: latest/download/<asset>, the bare latest API endpoint that
release-all.yml asks which version latest resolved to for the provenance
table, and ${VAR} whose default is checked separately to be latest.
Node.js is a different mechanism with the same effect - NODE_VERSION is
the bare major 24 and resolve-node-source.sh answers with that CPU's
newest 24.x from whichever of nodejs.org, unofficial-builds or
wekan/node-patches has one - so it is asserted to stay that way.
Thanks to xet7 !
BuildKit attaches MINIMAL provenance by default - a build id and a timestamp -
which is what those `unknown on unknown` rows on quay.io are: the OCI marker for
"not a runnable image", one per platform, so `docker pull` never selects them.
mode=max records what actually answers a supply-chain question instead: which
commit, which base image, which build arguments.
WeKan pushes images from FOUR places - docker-publish.yml's build-push-action,
two `docker buildx build --push` in release-all.yml, and one in
releases/docker-build.sh - and none of them said anything about provenance, so
all four took the default. All four ask for mode=max now. The local `--load`
check build in docker-build.sh deliberately does not: the docker exporter cannot
carry an attestation at all.
SBOM stays off, and the test says why so it is a decision rather than a drift:
it enumerates every OS package and npm dependency, taking the attestation from
~10 KiB per platform to megabytes.
tests/dockerProvenance.test.cjs finds the build sites by SEARCHING for them
rather than from a list, so a fifth one cannot quietly fall back to the default.
It also pins a trap I fell into twice while writing this, once in the shell
script and once in a YAML `run:` block:
docker buildx build \
# explain the next flag
--provenance=mode=max \
--platform ... \
A `#` after a line continuation comments out the REST OF THE JOINED LINE, so
that is `docker buildx build` with every argument swallowed - no platforms, no
tags, no push. `bash -n` accepts it, because it is valid syntax; it is simply a
different command. Both comments live above their command now, and the test
fails on any comment sitting among a continued command's arguments - while
ignoring a comment block that merely quotes a multi-line example, which is what
it flagged first.
Thanks to xet7 !
Same group, because it is the same area and the same one-line cause - a gh call
without --repo in a job that does not check out. The subsection is 'bugs' now
rather than 'bug'.
Thanks to xet7 !
The same one-line bug AppImage.yml had, and a second one beside it.
gh release upload 'v10.77' assets/* --clobber
failed to run git: fatal: not a git repository
Both flatpaks built and were uploaded as artifacts; the job that attaches them
does not check the repository out - it only downloads artifacts - so `gh` had no
git remote to infer the repository from. Every gh call in this workflow passes
--repo now, including the ones in jobs that DO check out.
The second: `assets/*` is not the bundles. The artifacts also carry the ostree
repository the flatpak was exported through - config, objects/, refs/,
summaries/, summary, summary.idx - which is build scaffolding, and attaching it
to a release would have put a few hundred directories there beside the two
files anyone wants. The upload names the bundles and their checksums instead.
TSC hit this exact thing and fixed it the same way.
No architectures to add, and the header now says why rather than leaving it to
be rediscovered. A flatpak runs against a RUNTIME, so an architecture exists
here only if freedesktop.org publishes org.freedesktop.Platform for it: x86_64
and aarch64, the i386 and arm runtimes having been discontinued. That is the
difference from AppImage.yml, which could grow to four - an AppImage carries its
own runtime binary, and those exist for i686 and armhf too.
Thanks to xet7 !
v10.77 was cut while they were being written, so they get their own Upcoming
above the release, and the links point at the hashes the rebase onto the version
bump produced rather than the ones that will be collected.
Thanks to xet7 !
x86_64 and aarch64 become four, with i686 and armhf. That is the whole set: an
AppImage BEGINS with a runtime binary the kernel executes, and runtimes exist
for exactly x86_64, aarch64, i686 and armhf. ppc64le, s390x, riscv64 and loong64
have none, so they cannot have an AppImage at all however the job is written -
they are served by the bundle zip and the .deb, and the matrix now says so where
somebody would otherwise try.
The two are not equally safe, and they are not treated as though they were.
i686 builds on the x86_64 runner, which runs 32-bit x86 natively: no emulation,
no multiarch, and appimagetool-i686 runs as-is. It is an ordinary job.
armhf builds on the aarch64 runner, which runs 32-bit ARM only if the kernel has
CONFIG_COMPAT and the 32-bit loader is installed. GitHub promises neither, so it
is continue-on-error - the same treatment TSC gives its emulated armhf job. If
it proves reliable, drop the flag; if it never works, drop the entry. What it
must not do is decide whether the other three reach the release.
The smoke test needed the distinction too. It starts the AppImage and waits for
WeKan to answer on port 8080, which a 64-bit runner cannot do for a 32-bit build
it cannot execute. A CHECK THAT CANNOT RUN IS NOT A FAILED CHECK: when the
binary will not execute at all AND it is not this machine's architecture, the
AppImage is as good as anything here knows, so it warns, says it is uploaded
unchecked, and moves on. A build that DOES start and then does not answer still
fails - that is the bug the step exists for.
The publish job's two hardcoded architecture lists learned all four, so a
missing one warns instead of going unnoticed, and the base-bundle check looks
for wekan-<v>-{i386,armhf}.zip as well.
Untested here: this is a workflow, so the first real run is the test. The two
new jobs are the only ones that can fail, and armhf cannot take the release with
it.
Thanks to xet7 !
Both AppImages built, both passed the smoke test that starts them and waits for
WeKan to answer on port 8080, both uploaded as artifacts, both downloaded by the
attach job with matching digests - and then nothing reached the release:
gh release upload 'v10.77' assets/* --clobber
failed to run git: fatal: not a git repository
The attach job does not check the repository out. It has no reason to - it only
downloads artifacts - so `gh` has no git remote to infer the repository from.
Every other gh call in this workflow already passes --repo; these two did not.
Every gh call passes it now, including the two in jobs that DO check out. A call
that relies on an inferred remote breaks the day somebody removes the checkout,
and the error it gives names neither gh nor the workflow.
Worth recording for whoever reads the failed run: the log looks far worse than
the bug. `::error::` lines appear in the build jobs' output for the bundle-file
check and the port-8080 check, and in the attach job for "no architecture
produced an AppImage" - none of which fired. They are the SCRIPT being echoed by
the ##[group] header, not output. The real failure is one line, in the last step
of the last job.
Thanks to xet7 !
The page listed five architectures and omitted armhf, which snapcraft.yaml has
built all along. It said the release publishes candidate, beta and edge and that
"the stable channel is published manually later" - which is no longer true and
was the reason a build reached three channels of four. And it said nothing about
the two architectures that are bundles but not snaps, so "missing" and "cannot
be there" looked identical.
The matrix is the six `build-for:` entries with the bundle name beside each,
because the two names are not always the same, and a new section explains the
three ways they differ:
ppc64le / ppc64el the same 64-bit POWER under two names - the bundles use
the kernel's, the store uses Debian's. The only rename.
armhf / armv7 NOT a rename, and getting this wrong ships a snap that
crashes. node-patches builds armhf to the Debian baseline
(hard-float, VFPv3-D16, no NEON assumed) so it runs on any
ARMv7-A, and armv7 with NEON for boards that have it. The
store has ONE 32-bit ARM architecture serving every such
device, so it must carry the BASELINE build; the NEON one
would be an illegal instruction on a board without NEON.
armv7 ships as a bundle only.
i386 cannot have a new snap at all, and this is categorically
different from a missing Node.js build. node-patches
patches SOURCE so a binary can be built; here the BASE SNAP
does not exist, because Ubuntu 24.04 has no i386 port. No
patch set can produce a base Canonical does not publish.
The last base with one was core18, end-of-life.
Then what to do about it: the three snaps, all four channels, and why stable is
possible - core24 is a released base, so the snap carries grade: stable, which a
grade: devel core26 snap cannot. A table of what each snap has in the store
today and what is still to upload, including the two fossils that channel
promotion cannot fix: wekan-ondra's armhf at 0.22 and its i386 at 0.X-ci, which
have no newer revision to promote.
And the caveat that matters when running it: without a pinned version the newest
revision of each architecture is promoted, and edge is often ahead of stable, so
a bare run publishes edge builds to stable users.
The armv7 note in models/lib/snapArchitectures.js said "different CPUs", which
was the right conclusion from the wrong reason. It now says what node-patches
actually builds, and a test cross-checks it against that repo's own workflow so
the explanation cannot drift from the binaries.
Thanks to xet7 !
The helper that did this released ONE snap, ONE revision, to THREE channels:
snapcraft release wekan $1 edge,beta,candidate
wrong three ways at once. It names only `wekan`, leaving wekan-ondra and
wekan-gantt-gpl to be done by hand. It takes ONE revision number, and revisions
are PER ARCHITECTURE - the store's own listing shows wekan at 3601 on amd64 and
3600 on arm64 for the same 10.76 - so one number can only ever be right for one
of them. And it leaves out `stable`, so a build reached three channels of four
and somebody had to remember the fourth.
releases/snap-release-all-channels.sh resolves the revision per (snap,
architecture) from the store itself, so no revision number is ever typed, and
releases it to all four channels in ONE call - a revision reaches all of them or
none. A (snap, architecture) with no revision is reported and skipped rather
than failing the run: the three snaps genuinely have different architecture
sets, and one architecture failing must not stop the rest.
THE MAPPING IS THE HAZARD, and it is now in one place with both directions
tested (models/lib/snapArchitectures.js):
ppc64le and ppc64el ARE the same hardware. The bundles at
https://github.com/wekan/wekan name it the way Node.js and the kernel do; the
Snap Store names it the way Debian does. Nothing warns when the wrong one is
used - an unrecognised --arch is simply an architecture the store has never
heard of, so it looks like it worked.
armhf and armv7 are NOT. armhf is 32-bit Raspberry Pi OS; armv7 is the
ODroid-U3. Different CPUs, different bundles. The store has ONE 32-bit ARM
architecture, armhf, so that is what is published; mapping armv7 onto it would
hand Raspberry Pi users the ODroid build. The negative test for that is the
most important one in the suite.
The six architectures are exactly snapcraft.yaml's `build-for` list, and a test
compares the two so the table cannot drift from what is actually built. i386 and
armv7 are recorded as not-built, with their reasons, and the script prints them
on every run - "it is missing" and "it cannot be there" look identical from the
outside.
tests/snapArchitectures.test.cjs: 23 checks including that the newest revision
for THAT architecture wins, that a version filter publishes what was built
rather than whatever was uploaded last, that `snapcraft list-revisions` parses
when a revision has no channels, and that junk never reaches snapcraft.
Thanks to xet7 !
A rebase rewrote the commits these entries link to, so the links named commits
that no longer exist and would have 404ed on GitHub. Repointed by
releases/fix-changelog-hashes.sh, which only touches a link no ref in this clone
can reach.
Thanks to xet7 !
v10.75 was cut while they were being written, so they get their own Upcoming
above the release. The FerretDB one is summarised here and told in full in that
repo's CHANGELOG, since it is the database that changed.
Thanks to xet7 !
Neither of these gave a wrong answer. They asked the right question one document
at a time, and each await is a full round-trip that starts only once the last
one finished - invisible on a board with four cards, and the whole cost of the
request on a real one.
The bulk label endpoint (PUT .../cards/labels) awaited a getCard per id and then
an update per id. At BULK_CARDS_MAX = 500 that is ONE THOUSAND sequential
round-trips for a single request. The reads are all the same question, so they
are one `$in` query indexed into a Map; the writes genuinely differ - each card
merges its own labelIds - so they stay individual updates, but they are issued
together and awaited once instead of each waiting for the last.
Two details that had to survive: the loop still iterates cardIds rather than the
query result, because a batch read comes back in the database's order and
without the ids that matched nothing - iterating it would silently reorder
`updated` and lose `notFound`. And every write is awaited before the 200 is
sent, so the response still means what it says.
The bulk DELETE beside it is deliberately left alone: its per-card work is real
(cardRemover runs the sub-item hooks, each card gets its own activity), so
batching the reads would save one query inside a loop that does far more than
query.
Global search resolved each `user:`/`member:`/`assignee:`/`creator:` name with
its own awaited findOne, so `member:ann member:bob member:carol` was three
serial round-trips before the search itself could start. They are all the same
question - which of these names is an account - so it is asked once, with `$in`,
and answered from a map. A name typed under two operators is one lookup now, not
two. Unknown names are still reported against the operator they were typed
under, because "ann is not a user" is not useful without saying where ann was
typed.
tests/queryBatching.test.cjs pins both, including the negatives: no per-card
read remains in the label handler, no per-username query remains in search, the
response order and notFound list are preserved, and the delete handler is still
per-card on purpose.
Thanks to xet7 !
The release script renamed the old Upcoming to v10.74, and two commits landed
after it: the linked-card cache that could not see a card added later, and the
build-script parity fix. They get a fresh Upcoming section above the release,
which is where development entries go.
Both were rebased onto the version bump, so their hashes changed; the links
point at the ones that will be pushed, not the ones that will be collected.
Thanks to xet7 !
The helper the five linked-card cursors share memoized its result per board, to
spare them the duplicate queries the five copies of that preamble used to make.
That is wrong: publishComposite re-runs a child's find() when the parent
document changes, and a cache living for the whole subscription then serves the
ids computed the FIRST time forever - a linked card added later would never be
published, and one removed would go on being published.
The five cursors each ran these same queries before the helper existed, so
computing per call is exactly the cost they always had, and it is correct. The
guard that pinned the memoization now pins its absence, with the reason.
Thanks to xet7 !
The one red suite in the test run, and it was right twice over.
`Setup: "git pull" and "git push" that finish the job` added two entries to
build.sh's menu and left build.bat behind, so `build.bat git-pull` answered
nothing. It answers to both names now, with its own :gitpull/:gitpush labels -
the ones its interactive menu already used.
The guard also had to learn what a `!` entry is. It marks something build.sh
runs ITSELF rather than by executing a file in releases/. Most are raw commands
and the .bat runs those the same way, so those still compare as before; the
exception is an entry naming a build.sh FUNCTION, which is shell the .bat has no
way to call. Comparing those as scripts is what made this suite fail the moment
"Update git" was replaced. A function entry is now exempt from the script
comparison and checked separately: build.bat must implement a label of the same
name, so one dropping out of a menu still fails.
The node suites are 339 run, 0 failed for the first time in this branch.
Thanks to xet7 !
The five linked-card cursors are its own commit, and its story is told inside
the ParentBleed entry - so a reader could read about the fix and had no way to
reach it.
Thanks to xet7 !
Six dependabot bumps and two developer-facing commits since v10.73 had no entry
at all. Adding them showed the subsections were also out of order - fixes came
before features - so they are now CRITICAL SECURITY, features, dependencies,
bug fixes, developer-facing, which is what CLAUDE.md specifies.
Thanks to dependabot and xet7 !
The page was doing its job and nobody had acted on it. Two real WeKan bugs were
sitting there as rows marked "unknown / unclassified", whose advice was to add a
rule to models/lib/databaseErrors.js. Both are fixed, and both now classify.
1. moveSwimlane, four times over a week:
Error: update is not available on the server. Please use updateAsync()
Board.ensureDefaultSwimlaneId() called the SYNCHRONOUS Swimlanes.upsert().
Meteor 3 removed it on the server, so every move that reached the default
swimlane self-heal threw. The async twin already existed one function below.
This getter is synchronous and cannot await, so the upsert is now STARTED and
not waited for: the self-heal still happens, and the call returns what is in
the cache - which every caller already had to handle, because it was
undefined before the self-heal existed at all. A caller that needs the
swimlane back in the same tick uses ensureDefaultSwimlaneIdAsync().
2. moveList:
ValidationError: Failed validation
Cannot read properties of undefined (reading 'title')
List.move() inserted a new list with `title: this.title`. When a list has no
title, `title` is required by the schema, so the insert fails validation - and
collection2's own error formatter then reads a property of the undefined field
and throws, which is why the admin saw a crash naming neither the list nor the
real problem. It now says what is wrong before the insert: "This list has no
title, so it cannot be moved to another board. Give it a title first." The two
console.log lines that used to sit there printed the title to a log nobody
reads and did not stop the crash; they are gone.
And two classifier rules so neither reads as "unknown" again. Both say plainly
that this is WeKan's bug rather than the database's or the admin's - there is
nothing to configure - and send the reporter to the right place: upgrade, then
open an issue with the method name. Severity `warning`, the vocabulary this
stream uses.
Thanks to xet7 !
Attachments and avatars are files under WRITABLE_PATH, and the database holds one
document per file. NOTHING checked that the two still agree. A file can be
replaced, truncated, back-dated or deleted by anything that reaches the
filesystem - a bad restore, a sync tool, a container rebuild, a shell on the
volume - and WeKan would keep serving whatever is there now, silently.
A baseline is recorded per file in the existing WeKan database (no new files
under WRITABLE_PATH): path, size, modification time, and md5, sha256 AND sha512.
Three digests, because they answer different questions. md5 is what other tools
print, so an admin can compare against a backup with what they already have - it
is never alone, its collision resistance is gone. sha256 is the working digest.
sha512 earns its place on the day the two DISAGREE: two digests over the same
bytes cannot, so when they do, the bytes were not read the same way twice - a
failing disk, a partial write, a truncated copy - which is a different problem
from a substitution and is its own critical finding.
ed25519 is the fourth check and it is NOT a hash - it is a signature, and it
answers the one thing three digests cannot: who says these are the right hashes?
Anybody who can rewrite a file can rewrite a row of hashes. Each entry is signed
over a canonical line (fixed field order, no JSON, whose escaping is not
guaranteed stable) and verified on every scan. A record that does not match its
signature is critical and is NEVER explained away by an ordinary edit. The key
comes from WEKAN_INTEGRITY_PRIVATE_KEY, which WeKan never stores - that is the
configuration that means something against an attacker who reaches the database
too - or is generated and kept in the database, which detects filesystem-only
tampering and is honest about being no more than that. A MALFORMED supplied key
is reported rather than silently replaced by a generated one, which would look
like it was working while checking nothing the operator meant.
The scan is paced by policy, not by hope: once a day, checked hourly; nothing
starts or continues at or above 60% CPU; 50 ms between files plus 20 ms per
megabyte; a fifteen-minute budget, after which it stops and continues tomorrow;
and ONE read per file for all three digests. A run that stopped early does not
report the files it never reached as missing.
The finding is a change WITH NO RECORD SAYING WHY. Files change when people use
WeKan, and those changes are accounted for, reported once at info and
re-baselined so they do not repeat daily. A change with nothing to explain it is
at least medium and is deliberately NOT re-baselined, so it keeps showing until
somebody looks. A modification time that moved BACKWARDS is called out
separately: nothing does that by accident.
Crashes and downtime, in the same stream, because a crash leaves nothing behind:
the process is gone, so it cannot write a message about being gone. A heartbeat
every minute is the only thing that works, and the NEXT start reads it. A first
run and a clean stop record nothing - reporting every deliberate restart is how
a Problems page becomes one nobody opens. A short gap with no clean-shutdown
mark is a note; a long one is a high-severity "it stopped without shutting down
cleanly, and here is how long it was down". Uncaught exceptions and unhandled
rejections land here too, with their cause, before the process goes.
Admin Panel / Problems / Filesystem integrity is the new stream, with the
Username / IP address / Attempts columns. The baseline itself is never published
and never client-writable: it is a map of every file on the server, and the key
document is a private key.
tests/fileIntegrity.test.cjs, 34 checks: every digest case including same-size
substitution and disagreeing digests, the ed25519 forgery attempt, the canonical
line, explained vs unexplained, and the pacing - including that an unreadable
clock does not start a scan, which it did until the test said so.
Thanks to xet7 !
The security event log said what a guard DID - a request blocked, a filename
sanitized - which answers "is WeKan defending itself" and not the question an
admin asks next: who did that, and from where. It also could not tell a browser
that got confused from somebody working through the Hall of Fame one entry at a
time.
A CANARY is a tripwire at a point that only a permission-override attempt
reaches. Ordinary use never gets there - the code path runs when a request asks
for something the rules forbid - so a trip is not noise, and it is worth an
admin's attention with the actor attached. Design:
docs/Security/Remediation/WeKan.md §12.
Three properties, each enforced by a test:
SILENT. Tripping one changes NOTHING the caller can observe. tripCanary()
always returns false and tripCanaryDeny() always returns true, so a call site
reads as the refusal it replaces:
if (forbidden) return false; // before
if (forbidden) return tripCanary('card.vote-field', { userId });
The return value is decided before any reporting is attempted and the reporting
is wrapped, so a canary can never throw into, delay or disturb the request it
watches. The REST handler re-throws the ORIGINAL error object. This is not
politeness: a canary that announces itself is a map of which paths are watched,
and a probe would simply avoid them.
BOUNDED. A canary sits where an attacker can loop, so one row per attempt would
be a denial of service they get for free. models/lib/canaryTokens.js - pure, no
Meteor, no clock of its own - records the first trip of a (canary, actor) pair
at once, COUNTS the rest of the window, flushes one summary carrying the total
when the window closes, and stops writing after 60 summaries for a pair that
never gives up. The tracked-pair map is capped at 5000 and evicts the LEAST
RECENTLY seen, so a long-running attacker is not pushed out by a passing one and
a botnet varying its address cannot grow it. Idle pairs are swept on a timer. A
thousand attempts in a minute cost ONE row, and a suppressed trip costs one map
lookup. The username lookup is cached and capped, and neither it nor the insert
is awaited on the caller's path.
ATTRIBUTED. Every event carries userId, username, ip and count. The username is
denormalised at write time on purpose: it is what the account was CALLED when it
tried, so a rename does not rewrite history and a deletion does not erase it.
The address uses the same spoofing-safe resolver as the login throttle -
X-Forwarded-For only as far as HTTP_FORWARDED_COUNT says to trust it - or an
attacker could write a colleague's address into the security log by sending a
header. `detail` says what was attempted in the words of the feature, never the
payload.
Seventeen canaries are wired at the permission checks that refuse the attempts
behind BoardBleed, ParentBleed, ChecklistBleed, PathBleed and CommentBleed, plus
the direct vote/poker field writes and a stored path that points outside the
storage root. All server-side: no Playwright, no browser, nothing to install.
Admin Panel / Problems / Security gains Username, IP address and Attempts
columns, and both new columns are searchable - the thing an admin does with one
security event is pivot on it.
tests/canaryTokens.test.cjs (25 checks) drives the limiter through bursts, an
endless probe, eviction order and junk input; tests/canaryCoverage.test.cjs (18)
pins every canary to its call site and asserts none of them changes what the
caller gets back.
Thanks to xet7 !
The five linked-card cursors and the streaming attachment read join the
ParentBleed and PathBleed entries they extend; the comment-reaction ownership
fix and the security-test coverage guard get subsections of their own.
Thanks to Alpastx and xet7 !
"Are the security tests enough to prevent what is in the Hall of Fame" was
unanswerable. WeKan publishes 58 named vulnerabilities at
https://wekan.fi/hall-of-fame/ ; some suites name the one they belong to, most
did not, and the Hall of Fame lives in a different repository that CI never
checks out. Answering it meant reading 58 pages against 300 suites by hand,
which means it was never answered - and a regression test that quietly stops
existing is worth nothing, the failure mode tests/testsAreRegistered.test.cjs
already caught once when two *bleed suites drifted out of the mocha index.
So the list lives in the repository that has the tests, and
tests/securityRegressionCoverage.test.cjs keeps the two in step. Every published
vulnerability is either GUARDED - named by a suite that still exists - or
RECORDED, a gap with a written reason, which is the CHANGELOG's "TODO Later"
pattern applied to tests. The gap count is pinned, so a vulnerability cannot be
published with neither a test nor a note; a gap that turns out to be guarded
after all fails too, so coverage is never understated; and a file that merely
REGISTERS suites is not accepted as coverage, or the guard would pass itself.
Getting there meant naming vulnerabilities in the suites that already guarded
them, which is most of what this commit is:
- tests/securityMeifukun.test.cjs guards eight reports and named one. Its
sections are RedirectBleed, SourceBleed, LiveBleed, CasBleed, OidcBleed,
MetricsBleed, ImpersonateBleed and InviteBleed - seven vulnerabilities that
looked untested and were not.
- tests/noIdentityReplacement.test.cjs guards IdentityBleed and PatternBleed,
the same CodeQL finding twice.
- ExportBleed, CrashBleed, MimeBleed and the four LockoutBleed suites now say so.
- tests/crossBoardParentCardLeak.test.cjs also guards BoardBleed's cross-board
move deny, and now checks it on Lists and Swimlanes too, not only Cards.
The count that comes out of it: 29 of 58 published vulnerabilities have a named
regression test, and 29 are recorded gaps - mostly older fixes from before WeKan
tested its security fixes at all. They are not known to be unprotected; they are
known to be unchecked, which is a different and more honest statement, and each
one now says what it would take to close it.
Thanks to xet7 !
Found while auditing for more of GHSA-pqr4-rxgp-hv2m (CommentBleed - the REST
comment delete that checked board membership and nothing about WHOSE comment it
was). A CardCommentReactions document holds
{ cardCommentId, reactions: [ { reactionCodepoint, userIds: [...] } ] }
and the whole array is ONE field, whose allow rule was board membership for
insert, update and remove alike. So any member could $set `reactions` to
anything: add a colleague's userId to a reaction they never made, or remove one
they did. `toggleReaction()` only ever touches Meteor.userId(), so no legitimate
client sends anything else - the rule simply never said so.
Integrity rather than confidentiality: reactions are visible to the whole board
already. But it puts words in another person's mouth, and it is the same shape
as the advisory - a per-user object gated only by "are you on this board".
A deny rule now refuses an update that changes any OTHER user's presence in any
reaction. The decision is pure and lives in models/lib/reactionOwnership.js:
it compares MEMBERSHIP rather than array order, because the client rebuilds the
array on every toggle and a reordered array with the same membership is the same
set of reactions. The modifier forms that cannot be checked that way -
$push/$pull/$addToSet/$unset, or a dotted `reactions.0.userIds` - are refused
outright, since toggleReaction() always $sets the whole array and letting them
through would be a hole the size of the one being closed.
The membership rule it sits on top of is unchanged: read-only and no-comment
members still may not react at all.
tests/reactionOwnership.test.cjs covers both directions - adding and removing my
own reaction, the first reaction and the last one going away, a reordered array,
several of my own toggled at once - and the attacks: adding somebody else,
deleting somebody else's, wiping an array that was not only mine, moving
somebody else between reactions, an anonymous caller, and junk in either array.
Thanks to xet7 !
GHSA-jvv9-498p-hxrg was reported against the ANCESTOR cursor of the `board`
publication - a cross-board `parentId` made it publish a private board's cards
to another board's subscribers. Auditing for more of the same found the
linked-card cursors beside it with the identical hole and a wider blast radius:
five of them, publishing the linked card, its comments, its attachments, its
checklists and its checklist items.
A `cardType-linkedCard` names a card by id exactly as `parentId` does, and that
card may live on any board. Creating one requires read access to that board -
but the person who created it is not the person the publication is sending to.
Every subscriber of the board carrying the linked card was getting the source
card's full document and all of its children, whether or not they may see the
board it lives on.
The same answer as the ancestor cursor: a linked card whose source board the
subscriber cannot see is not sent. Cards on THIS board are their own answer,
since they are already going to this subscriber. The five cursors repeated the
same fifteen-line preamble verbatim; they share one helper now, memoized per
board, which is also what stops the sixth from being written without the check.
Two more findings from the same audit, in the same file and its neighbour:
- Three further hand-written copies of the board-visibility `$or` (the boards
publication, getAllBoardsPage, getAllBoardsTileData). All three were correct,
which is exactly the state RevokeBleed's copy was in before it drifted. They
call boardVisibilitySelectors() now, so there is no hand-written copy left in
the file.
- The STREAMING attachment export read `versions.original.path` with nothing but
an existsSync. The attachment allow rule refuses a client-supplied path, so
this is not the PathBleed hole - but it was the last place a stored path was
read without the containment check, and a path is only as trustworthy as every
way it could have been written.
tests/crossBoardParentCardLeak.test.cjs grows six checks: all five cursors go
through the helper, the helper asks the same visibility question, no cursor
builds its own linkedId list any more, the assigned-only member narrowing
survived the de-duplication, the helper is memoized, and no hand-written
visibility array remains.
Thanks to Alpastx and xet7 !
PathBleed, RevokeBleed, ParentBleed and CommentBleed, each linking its own fix
commit and its Hall of Fame page, under a CRITICAL SECURITY ISSUES header.
Thanks to Alpastx and xet7 !
Over DDP, deleting a comment is author-or-board-admin, and a board that sets
`restrictCommentEditing` takes even the admin's ability away (#5906). That rule
was enforced in a CardComments collection hook keyed off the Meteor userId, with
an early `if (!userId) return` for the genuine server-internal callers - board
copy, cleanup, migrations - that run with no authenticated user.
An HTTP request carries no Meteor userId into the invocation context. So
DELETE /api/boards/:boardId/cards/:cardId/comments/:commentId
which checked only `Authentication.checkBoardAccess` - board MEMBERSHIP - reached
the collection with no user, the hook took its "server-internal, trust it" path,
and any normal member could delete any comment on the board. HTTP 200, the
comment gone, restrictCommentEditing or not, while the same deletion over DDP
was correctly refused (CWE-639, CWE-863). Broken object-level authorization:
harassment and evidence destruction on a shared board.
The fix does not rely on the hook seeing something it cannot see. The handler
loads the comment - 404 when there is none - and applies the same rule itself,
with req.userId, before removing anything. That rule is now an exported function
(`assertCanMutateComment` in models/cardComments.js) that the hooks and the REST
handler both call, so DDP and HTTP cannot enforce different things; it carries a
403 statusCode so a refusal answers Forbidden rather than 500. The no-userId
path stays, documented for the internal callers it was written for.
tests/restCommentDeleteAcl.test.cjs pins that the handler loads the comment,
that the ACL runs BEFORE the removal, that membership alone is no longer
sufficient, that the DDP hooks still call the same function, and - so a future
edit route cannot repeat this - that no REST PUT for comments exists without the
same check.
Thanks to Alpastx and xet7 !
Fixes GHSA-pqr4-rxgp-hv2m.
A card's `parentId` may name a card on ANOTHER board, and setting it was
authorized only against the CHILD board's write ACL - nothing asked whether the
person setting it, or the people subscribed to the child board, were allowed to
see the other board at all.
The board publication walks the whole ancestor chain, because the
'prefix-with-full-path' subtask setting renders a subtask's complete path
(#3453), and it published the complete ancestor card DOCUMENTS to every
subscriber of the child board. So a member who could write on shared board B and
knew a card id on private board A could point a card at it and have A's card -
title, description, custom fields - delivered over DDP to people who are not
members of A (CWE-200, CWE-862).
Closed at both ends, because either alone leaves half the hole open.
The WRITE refuses a parent whose board the actor cannot see. That is one
question, asked in one place (server/lib/visibleBoardIds.js) with the same
selectors the publication and All Boards use - so an ACTIVE org, team or domain
share counts and a revoked one does not. It is enforced on the REST card create,
on the REST card update (the PUT the report used), and on DDP by a deny rule
covering both insert and update, beside the cross-board MOVE deny that
GHSA-gm7v-pc38-53jr added. A parent that does not exist is refused too. Clearing
or omitting a parent is untouched.
The PUBLICATION sends only the ancestors whose board the subscriber may see. The
board being published is its own answer, so a normal same-board subtask path is
unchanged; an ancestor on a board the subscriber cannot see is simply not sent,
and a chain that yields nothing publishes nothing.
This is the shape of the check the linked-card path already made - creating a
linked card requires read access to the source card's board - applied to the
field that did not have it.
tests/crossBoardParentCardLeak.test.cjs pins the filtered cursor, that the
unfiltered publish of every ancestor is gone, that both REST paths validate
before writing, that the deny rule covers insert as well as update, and that
clearing a parent and the pre-existing cross-board move deny still work.
Thanks to Alpastx and xet7 !
Fixes GHSA-jvv9-498p-hxrg.
`isActive: false` is how a board admin REVOKES a share with an organization, a
team or an email domain. The All Boards list honoured it - it matches shares
with `$elemMatch: { ..., isActive: true }` - so a revoked user watched the board
disappear from their list and everything looked correct.
The `board` publication did not. That is the publication that sends the board
document and its lists, swimlanes, cards, comments and attachments, and it
matched shares with a dotted selector instead:
$or.push({ 'orgs.orgId': { $in: orgsIds } });
$or.push({ 'teams.teamId': { $in: teamsIds } });
$or.push({ 'domains.domain': { $in: emailDomains } });
A dotted path matches an element of the array without saying anything about
that element's other fields, so isActive was never consulted. Anyone who still
knew the boardId - a bookmark, a browser tab, a note - could subscribe and
receive the whole private board after their access had been taken away
(CWE-639, CWE-863). A revoke the primary data publication does not honour is
not a revoke.
The rule was written out twice and the two copies disagreed, so it is written
once now: models/lib/boardVisibilitySelectors.js builds the `$or`, both
Boards.userBoards and the `board` publication call it, and every share kind is
matched with `$elemMatch` requiring `isActive: true`. `includePublic: false`
still drops the public clause and only that clause, which is what the search
over all boards needs.
tests/boardShareRevokeBypass.test.cjs pins each share kind's selector shape,
that no clause anywhere matches a share without requiring isActive, that the
three dotted selectors are not produced at all, and that junk in the id lists is
dropped rather than handed to Mongo. tests/searchBoardScope.test.cjs asked its
question of the old array literal; it now asks it of the builder - the
behaviour it protects is unchanged.
Thanks to Alpastx and xet7 !
Fixes GHSA-gwc4-fw7p-gw58.
Attachments blocked client-supplied `versions.*.path`; avatars did not. The
avatar allow rule was the single line `update: isOwner` - being the owner let
you write ANY field of your own avatar document, `versions.original.path`
included. That field is server-managed metadata: it says where on disk the
bytes are.
Board export then read it. For every member whose avatar is a local WeKan file,
the exporter opens `versions.original.path` and embeds the bytes as base64 in
`profile.avatarFile`, so an authenticated user could point their own avatar at
/etc/passwd - or at anything else under WRITABLE_PATH - export a board they are
a member of, and decode the file out of the JSON. Arbitrary file read as the
WeKan OS user (CWE-22, CWE-73), from any account that can own an avatar.
Both halves are closed.
The WRITE: the guards that attachments had are now in one module,
models/lib/fileVersionFields.js, and BOTH permission files import it - avatars
had gone without them precisely because each collection wrote its own copy.
Avatars refuse an insert carrying versions.*.path or .storage, refuse any update
touching the versions subtree, and restrict updates to the same field whitelist
attachments use. Being the owner is still required; it is no longer sufficient.
The READ: nothing is read from a stored path unless the path RESOLVES to
somewhere inside WeKan's own storage (models/lib/storagePathContainment.js).
That is the half that also holds when a path is poisoned some other way - a
document written before this fix, a restored backup, a bad migration. The check
sits at getBase64Data, the one place the export turns a stored path into bytes
for attachments and avatars alike, and at both avatar call sites. The download
path in fileStoreStrategy.js has always checked containment this way; its
private copy of the function is gone and it uses the shared one, so the download
and the export ask the same question.
tests/avatarVersionPathTraversal.test.cjs pins the payload being refused on
insert and on update, that renaming an avatar still works, that ..-escapes are
resolved rather than string-matched, that a sibling directory with the root as a
prefix is not inside it, and that no unguarded read of a stored version path
remains in the exporter.
Thanks to Alpastx and xet7 !
Fixes GHSA-4mxf-m8pq-xc9p.
An audit of releases/ against who actually calls each script. It holds 89 of
them, and they divide cleanly:
20 invoked by .github/workflows - CI checks out the repo and runs the FILE, so
these cannot move anywhere;
65 reachable from the build.sh / build.bat Releases menu, which is what the
menu is for;
1 sourced by another script (ensure-tools.sh);
3 referenced by nothing that runs.
Of those last three, wekan-entrypoint.sh is the Docker image's entrypoint - named
by the Dockerfile, not by a caller in this repo - so it stays.
old-build-bundle-arm64.sh and translations/old-pull-translations.sh are the other
two, and both were already recorded as superseded, by build-bundle-arm64.sh and
pull-translations.sh. Nothing referenced them but the exemption list that excused
them from being menu entries. They are deleted, and their exemptions with them.
Two more exemption notes were wrong rather than stale-adjacent:
fix-changelog-hashes.sh said "Setup -> Update git runs it", an option that no
longer exists - it is Setup -> git pull and git push now, both of which run it -
and resolve-fork-node-tag.sh excused a file that is not in the tree at all. An
exemption naming a missing script is an exemption nobody can check.
Checked after: every remaining releases/ script is either a menu entry or exempt
with a reason, and no exemption names a file that does not exist.
Thanks to xet7 !
"Update git" fetched, rebased, ran the CHANGELOG hash repair, printed git status
and left the rest to the reader - and the rest is where the mistakes were. A
rebase rewrites local commits, so CHANGELOG links written before it name commits
that no longer exist; the repair fixes the file but commits nothing, so the next
push carries a dirty tree; and a push rejected as non-fast-forward leaves a repo
that needs a pull the caller has to know to run. Three manual steps after an
option whose name did not say what it did.
Two options now, one per direction, each ending in a state that is either correct
or unchanged:
git pull - fetch; fast-forward when there is nothing local to replay (no
commit is rewritten, so no link can go stale); otherwise rebase,
then repoint the CHANGELOG links the rebase moved AND commit that,
so the tree is clean. A conflict is the one thing a script must not
paper over - a half-applied rebase IS the wrong state - so the
rebase is aborted, the repo is exactly as it was, and the message
says what to run by hand.
git push - repair the links BEFORE publishing them, since a stale link that
reaches GitHub 404s for every reader; say so when there is nothing
to push; and on the one rejection with an obvious answer, origin
moved, pull and retry ONCE. Never force: force-pushing a branch
somebody has pulled rewrites their history too, and a second
rejection is a different problem that retrying does not fix.
build.bat had a 41-line batch REIMPLEMENTATION of the old flow. It is gone: both
options there call `bash ./build.sh git-pull` / `git-push`, so there is one
implementation of this logic and Windows cannot drift from it. The same two are
CLI commands (./build.sh git-pull, git-push), so the menu, the .bat and the
command line are the same code.
Verified against throwaway repositories - an origin plus two clones - rather than
by reading: already-up-to-date does nothing; origin-only-moved fast-forwards and
rewrites no commit; both-sides-moved rebases, and a CHANGELOG link to a rewritten
commit is repointed to the replayed commit with the same subject and committed,
leaving the tree clean; a conflicting rebase aborts with HEAD, the working tree
and the index exactly as before and no rebase in progress; a rejected push pulls
and lands on the second try; and pushing with nothing to push says so.
Thanks to xet7 !
v10.72 was tagged and published at 08:32; the PatternBleed fix was committed at
09:05. Its entry went into the section directly above the previous release, and
by then that section had been renamed from "Upcoming" to "v10.72" by the release
commit - so the changelog claimed a released version contains a fix that is not
in its tag. Checked rather than assumed: the v10.72 tag points at "Bump versions
for v10.72", and the fix is not an ancestor of it.
There is a "# Upcoming WeKan ® release" section above v10.72 again, holding the
security subsection, and v10.72's first subsection reads "This release updates
the following dependencies:" once more instead of the "and updates" it was left
with. The Upcoming section carries the shape CLAUDE.md prescribes: the
**In short:** paragraph, then the binaries table - v10.72's rows, since nothing
here rebuilds them, and the paragraph says so - then the subsection, then the
closing thanks line.
The entry's commit link is repointed. `git pull` rebased the three commits after
the release onto it, which gave them new hashes, so the link written before the
rebase named a commit that no longer exists.
And a real bug in the guard that was supposed to notice all this:
/^(This release|and ) .*:$/
The space is INSIDE the alternative AND after it, so matching an "and" header
needs "and updates" with two spaces. Every `and ...:` subsection header
therefore failed to match, and the grouping check never reset its current group
at a subsection boundary: entries under a later subsection were attributed to the
last group line above them, which is exactly the mistake that loop exists to
catch. With it fixed, the section reports 22 grouped entries and one loose - the
one-entry security subsection, which CLAUDE.md keeps flat.
Thanks to GitHub CodeQL code scanning and xet7 !
CLAUDE.md's security process is the Hall of Fame as well as the CHANGELOG: the
name, the row in hall-of-fame/index.html and the page under it. I had written the
entry without them.
Thanks to GitHub CodeQL code scanning and xet7 !
Its own SECURITY ISSUES subsection, first in the release as CLAUDE.md prescribes,
so the dependency subsection that used to open it becomes an "and updates".
Thanks to GitHub CodeQL code scanning and xet7 !
Code scanning alert #431, tests/releaseNodeSources.test.cjs:
new RegExp(`^\s*${p.replace('-', '-')}\)\s+nodename=`, 'm')
It reads as "escape the hyphen before interpolating this into a regex" and does
nothing whatsoever, so the value went in raw. Nothing failed, because a hyphen
outside a character class needs no escaping - but the guard it looked like was
not there, and a platform name carrying a `.` or a `+` would have matched the
wrong row or thrown. CWE-116, and CodeQL is right to call it out: the usual cause
of the shape is a mistyped backslash escape, where '\"' is silently just '"'.
The platform name is escaped for real now, with the same escapeRegExp the other
guards in tests/ use.
tests/noIdentityReplacement.test.cjs catches the class rather than the instance,
because code scanning reports these days later in a web UI and the node suites
report in fifteen seconds. Three things it took to make it honest:
* it compares the two sides as VALUES, not as source text. '\"' IS '"' - that
is the entire point of CodeQL's example - so a text comparison would call
them different and miss the mistake the guard exists for.
* the two quote styles are separate alternatives, not a backreference with a
character class excluding both quotes: `replace('"', '\"')` contains a double
quote inside a single-quoted literal, so the first shape of the pattern could
not match the very example above. Caught by asserting the pattern against
that line rather than trusting it.
* comments are stripped and the guard skips its own file: this one and the file
it was written for both QUOTE the bad line to explain it, and a guard that
reports the sentence describing a bug as the bug gets switched off.
Verified in both directions: the repository is clean now, the same scan against
the previous commit reports the offending line, all three bad shapes are detected
and four working replacements - including a real escapeRegExp - are not.
Thanks to xet7 !
The two commits that fixed what the companion-repo move and the cross-board card
fix left failing, and the Playwright retry loop that could not reach its own
error. The run after them was green: 328 node suites, 518 mocha tests,
249/243/243 in the three browsers, 98 conformance cases with none differing, and
FerretDB's own suites.
Thanks to xet7 !
Down from five failures to none. Both of these are the same kind of thing - a
check that described the world before a change, and a loop that could not reach
its own error.
swcLegacyHelpers still required the .gitignore comment block that named each
clone: `- node/ : clone of the Node.js ...`. That comment went with the entries
it described. What has to be explained now is the one directory that replaced
them, so .gitignore says what .tools/ holds - companion repos, cloned inside the
checkout so they work in a Flatpak sandbox that shares only this directory, with
the entries it replaced named so the change is legible - and the guard requires
THAT. An ignore of a whole directory with no explanation is the kind nobody dares
remove later. The rule about the shape of a per-repo entry stays: if one is ever
re-added it must be rooted and a directory, since a bare `node` matches anything
a package happens to call that.
The webkit failure was one test of 243, in the shared boardPage fixture rather
than in an assertion:
Test timeout of 60000ms exceeded while setting up "boardPage".
Error: page.waitForTimeout: Target page, context or browser has been closed
openBoard retries five times, waiting up to 20s for a list each time with a
second between - about 105 seconds, against a 60 second test timeout. So the loop
could never reach its own error: Playwright killed the test first, and the report
said the page had closed instead of saying the board never rendered. Retrying
past the point where the result can still be used is not resilience, it is a
worse error message.
The loop is bounded by a deadline now, 45s, leaving room for the rest of the
fixture inside the 60s timeout. The first attempt keeps the full 20s look, later
attempts get whatever is left, and it stops rather than starting a wait it cannot
finish - so a slow board still gets one long look, and a board that will not
render fails with "did not render any lists within 45s". Simulated across three
cases: never renders (gives up at 45s, 3 attempts), renders at 4s and at 19s
(both on the first attempt) - all inside the test timeout, where the old shape
overran it by 45 seconds.
Thanks to xet7 !
An EVERYTHING run found four node suites and one mocha test failing. All five
are consequences of the two changes before them, and each one is a guard doing
its job.
Three broke on the companion-repo move:
* meteorignoreScanScope listed the foreign checkouts by name - FerretDB, node,
mongo-tools, TSC, gitea, the two WeKan variants - one .meteorignore entry
each. They are in .tools/ now, one entry that covers all of them, so a list
of names is a list of history: it fails for the ones that moved and says
nothing about the next repo somebody clones. It asks the property instead:
.tools is excluded, and nothing at the top of this checkout that is its own
git repository is left for Meteor to walk. The variant check became the
stronger version of itself - no directory with client/, server/ and models/
is reachable from the top - since a second WeKan is loaded EAGERLY, not
merely scanned.
* swcLegacyHelpers checked .gitignore for the same list; one entry now.
* cpuMonitorWiring reads FerretDB's Go source and still opened FerretDB/. It
reads .tools/FerretDB, and skips with a note when the clone is not there -
it is a separate repository, and not every checkout has cloned it.
dockerComposeBackends caught a real omission: the LDAP_GROUP_BASEDN block from
#5539 went into docker-compose.yml only, and every compose file's wekan service
must be identical - what a user reads when they edit their settings must not
depend on which backend they picked. The block is in all of them now.
The mocha failure is the one worth reading twice.
cards.dependencies.move.tests.js pinned move() issuing the inbound-dependency
cleanup itself: a multi-document update with a compound selector. That is
exactly what #6572 removed, because this helper runs in the client bundle where
Meteor allows updates only by id - it threw "Untrusted code may only updateAsync
documents by ID" on every cross-board move, before the move ran. So the test was
pinning the bug. It now asserts the contract that replaced it: move() clears the
moved card's own dependencies, and makes NO update that is not by id - not a
selector, not multi. `{ _id: x }` still counts as by id, since Meteor's rule is
"by id", not "not an object". The inbound half is the server hook, pinned by
tests/cardMoveUntrustedUpdate.test.cjs.
Verified against the tree: all four node suites' conditions hold, the four
compose files the guard compares are identical again, and the FerretDB source
the CPU guard reads is present at the new path with every pattern it asserts.
Thanks to xet7 !
An audit of the TODO Later backlog against the open issues and the current
source. Three no longer belong there.
#3113 - an outgoing webhook said who did something by DISPLAY name and had no
field for the login name. params.user comes from getActivityUserName(), which
prefers getName() because the same params feed the e-mail notification text,
where "Lauri Ojansivu commented on ..." is what a person wants to read; a webhook
consumer needs the identifier, received "Lauri Ojansivu" where it needed "xet7",
and matching users by display name is wrong the moment two people share one.
Changing what `user` means would break every consumer already reading it, which
is what left this recorded as needing a maintainer decision. It needs none: the
username travels as its OWN field. `user` is untouched, `username` is beside it
in the default WEBHOOKS_ATTRIBUTES list, and a deployment that pinned its own
list still gets exactly the fields it asked for.
#6542 - "Import finished. Users imported: 60, but only 25 are listed". The Admin
Panel People pane paginates and passes its total to the shared table page
(totalLabelKey: 'people-number'), so the 60 the importer reported is on screen
next to the 25 rows of the current page. That is what the report was about, and
it is already true in this source.
#6500 - Docker `latest` not loading in a browser: already closed upstream, so it
was only sitting in the backlog.
The rest of the backlog stays, each with its reason: they need an SMTP server, an
LDAP directory, a container, a browser to drag in, or a maintainer's decision on
an intended contract - none of which a source reading can settle.
tests/webhookUsername.test.cjs pins both halves of the webhook change: that the
username is there and set from the same user document as the display name, and
that `user` still means what it always did, including the notification text that
depends on it. Three of its seven assertions fail on the previous commit.
Thanks to xet7 !
Fixes#3113,
Fixes#6542.
wekan/FerretDB is a separate git repository that WeKan's test runs need: the
conformance run builds it from source, and "Run all FerretDB tests" runs its own
suites. It was cloned as a subdirectory of the repo root, which is why
.gitignore and .meteorignore carried an entry per companion repo - nine of them,
each one a chance for a clone to reach a commit or a Meteor rebuild. They live
in .tools/ now, one directory both files already exclude.
build.sh gains ensure_tool_repo: it returns the path to .tools/<name>, cloning
wekan/<name> if it is not there - SSH first, since a maintainer pushes, HTTPS
after, so everyone else still gets a working clone. Its messages go to stderr,
because the path is what it prints. The directory comes from the script's own
location rather than the caller's cwd, so a clone cannot land in whatever
directory somebody happened to be in.
EVERYTHING's FerretDB stage calls it rather than assuming stage 3 already
cloned - a whole-run must not depend on the order of its own stages -
db-conformance.sh builds from .tools/FerretDB and makes .tools before cloning,
and build.bat does the same on Windows: it clones into .tools\FerretDB with the
same SSH-then-HTTPS fallback instead of printing instructions and stopping, and
says so plainly when git itself is missing.
CLAUDE.md's directory list describes the new layout, including that a companion
repo is cloned on demand, so a fresh checkout needs no manual setup.
tests/toolsDirectoryRepos.test.cjs pins both halves: that nothing still reaches
for the old path and both scripts clone, and that a repo INSIDE .tools still
finds its way back out - FerretDB's own build.sh used to reach WeKan's log
directory by counting ../, which lands one level short from .tools; it searches
for the checkout now (fixed in the FerretDB repo, same commit message).
Thanks to xet7 !
#6430's remaining flicker and #5707's invitation email both need something this
environment does not have - a browser to drag in, and a real SMTP server - so
they are recorded with the reason and what was already established, rather than
guessed at.
Thanks to xet7 !
#5251 asked for the last change date of a list, to build an offline Android
client that syncs only what moved. Neither half existed: GET
/api/boards/:boardId/lists returned {_id, title} and no dates at all, and while
the single-list endpoint returns the whole document - modifiedAt included - that
date answers the wrong question. It moves when the LIST document changes (title,
sort, archived); a card being added, edited or archived does not touch it, and
those are the changes the client is asking about.
The list endpoint now reports both:
modifiedAt - the list document itself
cardsModifiedAt - the newest change among the cards in it, null when none
One query for the board's cards and a reduction in memory, not a query per list -
a query per list is what made this expensive enough to ask about. Archived cards
are included on purpose: archiving is one of the changes named in the issue.
The reduction is models/lib/listActivityDates.js, a pure helper, so it is
testable without Meteor and so the handler stays readable. It reads
dateLastActivity as well as modifiedAt and takes whichever is newer, because
boards written by older WeKan carry only the former; a card with no usable date
is skipped rather than counted as now or as zero; and a list whose cards carry no
date is ABSENT from the result, so the endpoint reports null rather than an
invented time - a client polling on a wrong date either never syncs or syncs
forever.
tests/listActivityDates.test.cjs exercises the helper directly: newest wins, per
list, legacy field, string and numeric dates, an undated card cannot drag the
answer backwards, and a negative case feeding it nulls, strings, numbers, a card
with no listId and an Invalid Date - none of which may throw, since the handler
passes whatever the database holds. It also pins the endpoint's shape: both
fields, one cards query, only the three fields it reduces over, and no
`archived: false` on that query.
Thanks to mimZD and xet7 !
Fixes#5251,
#5539: WeKan could not authenticate LDAP users whose groups sit in a different
ou than the users themselves.
Both group searches - getUserGroups, which feeds the login restriction, admin
status sync, group->role sync and org/team sync, and isUserInGroup - searched
this.options.BaseDN. That is the USER base. A directory that keeps ou=groups
beside ou=people, which is a common layout and the reporter's, has no groups
under it, so every group search came back empty; with LDAP_GROUP_FILTER_ENABLE
on, isUserInGroup concluded "not a member" and refused the login. Nothing in the
package could say where the groups were - there was no setting for it.
LDAP_GROUP_BASEDN says where. Unset, or set to a blank string, it falls back to
BaseDN, so a directory that keeps users and groups in one subtree behaves exactly
as it did; a present-but-empty env var is one somebody meant to fill in, not a
search base, and searching "" would silently search the directory root.
The three USER searches - searchUsers, getUserById, getUserByUsername - keep
BaseDN. Pointing those at a group subtree would break login for everyone, so the
test pins which searches moved and which did not, in both directions.
Documented beside the settings it belongs with, in docs/Login/LDAP.md and
docker-compose.yml: a setting nobody can find is one that does not exist.
tests/ldapGroupBaseDn.test.cjs pins all of it, including the fallback and the
documentation. Six of its nine assertions fail on the previous commit; the three
that pass there are the user searches, which is the point of asserting them.
Not verified against a directory - this sandbox has none. The defect is read from
the source: two group searches, one user base, no way to say otherwise.
Thanks to leandro-cyberproject and xet7 !
Fixes#5539,
The screenshots in #6465 (comment 5187985815, images only, each with the fault
circled):
"Checkbox is misplaced" - Admin Panel people table. The select-all box and the
"all users" it labels were two loose inline nodes in a centred table heading: the
box is replaced content with its own baseline, and at the width that column
happens to have, it landed on the word. They are one <label for> now, an
inline-flex row with a gap that cannot collapse - which also makes the word click
the box.
"This checkbox is crazy" - Member settings. The rescue-card-description row
carried a `b ` spacer and `.left`, which is float: inline-start. A float
inside a flex container is ignored and the spacer became a stray flex item, so
the box drifted up beside the "Card settings" heading instead of sitting with its
own text. It is now the same shape every other checkbox row in that file uses:
.flex anchor, .materialCheckBox, span.
"(2/5) <-- move this up here" and "Make this same height as the lanes left and
right" - one cause, not two. The WIP counter is already inside the h2 right after
the title; the title is a `+viewer`, and .viewer is display: block with a 22px
min-height, so it pushed everything after it onto a second line AND reserved a
band under it, which is what made that list's header taller than its neighbours'.
Inline in the heading, the counter stays where the markup already puts it. Same
treatment the quick-access header and the table view already give their viewers.
"Please move the button down. This is too close ... panic ;-)" - the backup
schedule's Save sat directly under the 1..28 day buttons, close enough to hit
while aiming for a date. The gap goes on the form-group that FOLLOWS the day
grid, so it applies where that grid is and nowhere else.
"The alignment is out of place" - the attachment move button. This one is
normalisation rather than a measured fix: the row is align-items: flex-end, so a
margin of the button's own offsets it from the controls it acts on; that margin
is zeroed and the button aligns with the controls explicitly. Whether that is the
whole of what was circled needs a browser, and the test says so.
tests/uiSpacingReports.test.cjs pins each cause, including the premise behind the
WIP fix (.viewer really is a 22px block). Six of its nine assertions fail on the
previous commit; the three that pass there are the premises, which is the point
of stating them separately.
Not verified in a browser: this sandbox has none. Each fix is read off the markup
and CSS against what the screenshots show.
Thanks to Alishara and xet7 !
#5174: an OIDC login against a provider that rejected the scopes failed with
"Error in OAuth Server: Cannot read property 'ocs' of null", which says nothing
about the refusal that caused it.
getTokenContent() returns NULL for a token it cannot parse, and the ADFS/B2C
branch assigns that straight into userinfo. The next line was the Nextcloud hack,
`if (userinfo.ocs)`, so the first thing to touch the failed response was a
property read on null. Every claim read after it had the same problem - that line
was only first by accident of ordering, which is why the fix is not one null
check but an order: the provider's answer is validated once, as a whole, before
anything reads a field off it.
Checked, in this order, each naming what failed:
* the token response is an object at all;
* it carries an access_token or an id_token - a 200 with neither is the
provider answering with a complaint, so the error lists the fields that DID
come back (keys only: the values are secrets, and JSON.stringify of a token
response in a log is how refresh tokens leak);
* userinfo is a non-null object, saying WHICH path produced nothing (claims
expected in the access token, or the userinfo endpoint) and pointing at
OAUTH2_REQUEST_PERMISSIONS, which is what was actually wrong in #5174;
* the ocs and metadata hacks unwrap to something - `ocs` present with no
`ocs.data` used to set userinfo to undefined and fail on the next line;
* B2C's userinfo["emails"][0] is an array before it is indexed: a tenant that
does not release the claim made that undefined[0];
* expires_in parses to a finite number - parseInt(undefined) is NaN, and NaN
propagated into the account's expiry silently. Falls back to the OAuth2
default hour.
tests/oidcNullUserinfo.test.cjs pins the order rather than the individual checks:
it asserts each guard sits BEFORE the read it protects, since an edit that reads
a claim earlier would restore the original bug without touching a check. It also
pins that the no-token error names keys and never stringifies the response. All
eight assertions fail on the previous commit.
Not reproduced against a real provider - this sandbox has none. The null path is
read from the source: getTokenContent returns null for a falsy token, and the
ADFS/B2C branch passes its result to the line that threw.
Thanks to Esther125 and xet7 !
Fixes#5174,
Reported by email with a screenshot: the "Add card" link and the "Add" button
are too big, and things should be sized in relation to each other the way an h1
is bigger than an h2.
The measurements agreed. A list heading was 14px, while a minicard title and the
"Add card" link both set no size at all and inherited the document's 16px, and
the composer's Add button was a 50px-tall slab. So the column was labelled in
fine print, the affordance for making a card was as loud as the cards
themselves, and the biggest thing on screen while typing was a button.
The scale is now heading 16 > card title 14 >= add-card link 13, each stating
its own size instead of inheriting, and the Add button is a 34px control rather
than a slab. Mobile keeps its own larger sizes - the .mobile-view rules with
!important, and the @media blocks - because a phone is read at arm's length.
tests/listTypeScale.test.cjs pins the ORDER rather than the numbers, since that
is what "in relation to each other" means, plus that each of the three states a
size of its own: an inherited size is exactly how the link and the card title
both landed on 16px, level with each other and above their heading. It reads the
base scale only, skipping @media blocks, and takes the LAST rule for a selector -
.list-header .list-header-name has two rules, and reading the first one finds the
one that sets no size at all. Verified against the previous commit: heading 14,
card title and add-card link unset, button 50px - it fails on all four counts.
Not verified in a browser: this sandbox has none. The sizes are read from the
source, and the relative order is what the guard holds.
Thanks to xet7 !
#6572: every cross-board move failed immediately with "Not permitted. Untrusted
code may only updateAsync documents by ID. [403]", whether or not the card had
any dependencies, and before the move itself ran - so the card stayed put.
models/cards.js is isomorphic, so its helpers run in the client bundle, and
client code calls card.move() directly (list.js, swimlanes.js, minicard.js,
globalSearch.js, sidebarFilters.js). Meteor lets untrusted code update only BY ID
- a bare id or an { _id: ... } selector. The cross-board branch of move() cleaned
up inbound "Red Strings" (#3392) with a compound selector and multi: true, which
is rejected on the client every time, including when it would have matched
nothing. addDependency, setDependencyProps and removeDependency in the same file
each carry a comment saying updates must be by _id only; this was the one place
that did not follow it.
The card's own dependencies are still cleared by the move (that rides along in
the by-id update). The inbound half - the links pointing AT the card from the
board it left - is now a Cards.after.update hook in server/models/cards.js, where
a selector is allowed, and being server-side it also covers the REST API and
import paths that never called the helper at all. It pulls both stored shapes:
{ cardId, ... } objects, and the bare id strings older data still holds, which
normalizeDependencies hides on read.
The issue also reports that the REST workaround corrupts the card, and it does.
A PUT of boardId/listId/swimlaneId naming the DESTINATION board is not a board
move - isBoardMove needs newBoardId, newSwimlaneId and newListId - so that branch
never ran, while the same-board swimlane and list branches did: the card kept its
old boardId and got the other board's listId and swimlaneId written onto it,
belonging to a list and a swimlane on a board it was not on, showing on neither,
undone only by a hand-written database update. Those two branches now verify the
target belongs to the board in the URL and otherwise refuse with 400 naming the
parameters to use, and they are skipped during a board move - they would rewrite
listId before the isBoardMove update, whose selector pins the card's original
listId, so that update would match nothing and silently do nothing: the same
broken card by another route.
tests/cardMoveUntrustedUpdate.test.cjs pins both halves: every Cards update in
the isomorphic model is by _id and none is multi-document (it reads the whole
call, because multi is the third argument and a check that stopped at the first
one could never fail), the inbound cleanup is server-side and keyed on a real
board change, and the REST branches are board-checked and skipped during a move.
Verified against the previous commit: the model guard reports the compound
selector and the multi update, and 6 of the 8 REST assertions fail.
Thanks to jullbo and xet7 !
Fixes#6572,
The EVERYTHING run's WeKan stage failed on one node suite:
dbConformanceWiring, "build.bat: playwright-all must be logged". It is a real
gap, and splitting the whole-suite browser job into three uncovered it rather
than caused it.
`call :onelog playwright-all` existed in exactly one place: inside the combined
three-project browser line of the sequential all-tests flow, which is gone now
that each browser is its own job with its own log. Where it did exist it never
worked - the call sat inside the `cmd /c` string of a STARTED child process,
which has no build.bat labels to call, so %ONELOG% was empty and Tee-Object was
handed an empty path.
Meanwhile the option the name was supposed to cover, Tests -> 11 "Playwright ALL
browsers", wrote no log at all: one `playwright test --project=chromium
--project=firefox --project=webkit` call straight to the terminal, nothing left
to read afterwards. That is the exact thing the guard is about, and build.sh's
same option has always written one log per browser.
So the option now runs the three browsers one at a time - unchanged, and still
sequential because three at once against one dev server exhausts RAM on smaller
machines - each through the same :onelog helper as every other Tests option, and
each with its own --output so Playwright does not clear another browser's traces
at startup. The guard drops `playwright-all`, which named an implementation that
is gone and was broken, and gains what it was reaching for: that the ALL-browsers
option logs, and that it covers all three.
Verified: every build.bat label reference resolves, all seven menus still print
exactly what they dispatch, the build.sh menu entries all still match a case arm,
and the whole-suite per-browser jobs are untouched. Mocha ran in this run for the
first time since it was fixed - 518 passing - and the other stages were green:
320 node suites with this one failure, 249/243/243 in the three browsers, the
conformance run and all of FerretDB's own tests.
Thanks to xet7 !
Renaming the menu entry broke it. choose() shows the SHORT labels and sets $opt
to the FULL DESCRIPTION of the one picked, and the dispatcher hundreds of lines
below matches that description as a case arm - so the description is an
identifier written twice, and the rename in the previous commit changed only one
of them. With no arm matching and no catch-all, the case fell through, the
`for _once` loop ended and the script EXITED: choosing Tests -> 1 printed nothing
and ran nothing.
The arm now carries the same string as the menu entry, so EVERYTHING runs its
four stages again. Two guards so it cannot come back:
* tests/buildScriptParity.test.cjs checks every one of the 25 choose() entries
against the case arms, and fails on a description that matches none. It fails
on the previous commit's build.sh.
* the dispatcher has a *) arm that says which option has no handler and that
nothing was run, so if one ever does get past the test, the person in front
of the menu is told rather than dropped back to the shell.
build.bat was checked for the same thing and cannot fail this way: its menus
dispatch on the NUMBER typed, not on a sentence, and its EVERYTHING hands the run
to releases/run-everything.sh rather than reimplementing it. Verified anyway,
both directions: every printed menu number has an if-dispatch in all seven menus,
and every goto/call target resolves to a label. That is now pinned too.
Thanks to xet7 !
Also repoints six entries at the commits that exist on this branch. The board
export and mocha entries were written against a commit that was amended after
they were filled in, and the four snap entries against one that was amended the
same way, so each of them linked a commit the amend had orphaned. A CHANGELOG
entry cannot carry the hash of the commit it is in; it goes in its own commit
afterwards, linking the code commit.
Thanks to xet7 !
#6573: picking up a card made every list on the board expand horizontally to fill
the window, and dropping it snapped them back, which makes landing a card in the
intended list a guess. Two correct changes met. A list's custom width is an
inline --list-width custom property, and what turns it into a width is a rule in
list.css whose selector needs an ancestor: .js-swimlane, .dragscroll, or a
swimlane-<id> id. In lists view the container is
.swimlane.list-group.js-lists.dragscroll - no js-swimlane class, no such id - so
.dragscroll was the only one of the three that matched, and every list's width
there hung on that one class. #6558 then taught a card drag to stop the board
panning under the same pointer, and it does that by REMOVING the dragscroll class
for the duration of the drag. So the drag deleted the class the width rule
matched on: flex: none and the width declarations switched off and the lists
re-flowed, for exactly as long as the drag lasted. It also explains the
workaround in the report - dragging one list's edge first sets that list's width
through the resize path, so that column stopped jumping while the others did not.
A layout rule may not hang on a class that an interaction removes. .js-lists is
on the container in both views and nothing takes it off, so the width rules,
their mobile-mode counterpart and the resize rules name it now.
tests/listWidthDuringDrag.test.cjs pins that every width rule still matches in
lists view with dragscroll gone - it fails on the previous CSS - and pins the
premise that suspending the pan really does remove that class.
build.sh -> Tests -> EVERYTHING is what a release is tested with, so a check that
is in the Tests menu and in no whole-run is a check that runs when somebody
remembers it. The floating-promises guard was that: menu entry 12, in no run. It
is the first of four stages now - seconds, so an unawaited permission check is
reported before an hour of browsers - and its return code is in the verdict like
the others. What runs there is checks only: the menu entry may install ripgrep
and the @typescript-eslint packages and write the rule into .eslintrc.json, which
is a person setting the guard up, while EVERYTHING runs unattended and must
modify nothing - a run that rewrites .eslintrc.json is no longer testing the
commit it started from. The two checks are one shared function using grep rather
than ripgrep, so they also work where nothing may be installed.
build.bat ran the three browsers as one Playwright invocation into one
wekan-alltests-browsers.log, where neither "which browser failed" nor "what did
WebKit print" was answerable afterwards, and CLAUDE.md's "check the newest test
logs" names the per-browser files. It starts chromium, firefox and webkit as
three jobs with a log, a status and a summary row each now, with a per-browser
--output because Playwright clears its output directory at startup. EVERYTHING is
not reimplemented there: Windows hands the run to releases/run-everything.sh,
which calls build.sh --run-everything, so the new stage arrives on both platforms
at once. The parity guard pins all of it, including that the shared checks
install nothing.
Verified without node or meteor, which this sandbox has neither of: the extracted
checks were run for real against the tree (clean) and against fixtures with an
unawaited auth call, a missing rule and no .eslintrc.json at all (all three fail
as they should); the new and changed guards were ported assertion-for-assertion
to Python and run against the same files, including that the #6573 guard fails on
the pre-fix CSS; build.sh passes bash -n and every build.bat call now resolves to
a label.
Thanks to yulqen and xet7 !
Fixes#6573,
The newest test run had two failures.
tests/changelogFormat.test.cjs failed on "the binaries table follows the
summary": the Upcoming section written after v10.71 had lost the binaries table
that every release section carries. It is restored from what v10.71 shipped, and
two group lines that had wrapped onto a second line are one line again, which is
what the grouping guard requires.
The mocha stage did not run at all. client/lib/tests/boardTriggersClass.tests.js
reads boardTriggers.jade and boardTriggers.js off disk with fs and path, which
worked only while node-polyfill-webpack-plugin's browser shims were in the client
bundle; the @meteorjs/rspack 2.1.0 update dropped that plugin and the client
build stopped with "Cannot find module 'path' for matched aliased key 'path'".
That is not one suite failing - the bundle does not build, so every mocha suite
is skipped and the stage reports a crash where its results should be. The suite
was on the wrong side rather than wrong: it now lives in server/lib/tests, and
tests/clientTestsNoNodeBuiltins.test.cjs is the mirror of the existing guard that
keeps browser-only packages out of the server bundle.
Issue #6274, "export includes only comments from current year", and its fix in
PR #6275 were then checked against the current source. The fix is intact and
survived the streaming-export rewrite that came after it: both exporters select
comments by cardId and activities by boardId OR cardId. The follow-up its
reporter left on that PR - "the export is now missing the lists part" - is not
reproducible: result.lists has been written by the JSON exporter continuously
since the CSV/TSV export was added, both JSON writers emit the same fourteen
sections, and the flat formats carry each list's name on the card's own row. So
no export code changed; what was missing was the guard, and
tests/exportBoardSections.test.cjs pins the section list, that the two JSON
writers agree on it, that no exporter selects comments by board again, and the
two smaller fixes from that PR.
Not run here: this sandbox has no node, meteor or any other JS runtime, so the
new and changed guards were verified by porting them assertion-for-assertion to
Python and running that against the same files - changelogFormat 16/16, the
export and client-bundle guards clean. The mocha suites behind the fixed build
have not executed yet; the next run is what shows them.
Thanks to Tuphal, KhaoulaMaleh and xet7 !
Remove the 'commit only, do not push' guidance from both the maintainer-mode
intro and General practices; the maintainer decides when to push, directly on
the branch (no PR, no branches).
When a Launchpad remote build ends as 'Stopped' with no .snap, the job scans
the build log to tell a real credential failure from a build cancelled mid-run
(an OOM in the Meteor npm install, a build-farm reset). The scan pattern was
'unauthoriz|401|403', and a bare 401/403 matches any three digits in a large
build log - a package size, a hash, an 'attempt 4/6' line - so it fired on
almost every Stopped build and told the maintainer to re-create credentials
that were working: the build had reached 'Building:', which needs valid
credentials. The pattern now matches those codes only in an HTTP-error context
(HTTP Error 401, 403 Forbidden) or an explicit phrase (invalid credentials,
not logged in, bad credentials), so the credential hint appears only for a real
authorization failure.
releases/release-all.sh and releases/version.sh read a command's output
into an array with `mapfile`. `mapfile` (a.k.a. `readarray`) is a bash 4+
builtin, and macOS still ships bash 3.2, so `./releases/release-all.sh`
failed on a Mac with `mapfile: command not found` and could not trigger a
release from there. `brew install mapfile` finds nothing because mapfile
is a shell builtin, not a program.
Each `mapfile -t VAR < <(cmd)` is replaced with the portable
`VAR=(); while IFS= read -r line; do VAR+=("$line"); done < <(cmd)`, which
builds the same array on bash 3.2 and on the bash 5 the Ubuntu release
runner uses. Converted: release-all.sh's RELEASED version list, and
version.sh's three reads - the Node.js files, the MongoDB files, and the
two newest CHANGELOG release lines.
Thanks to xet7 !
Every place that downloaded bsondump, mongodump, mongoexport, mongofiles,
mongoimport, mongorestore, mongostat and mongotop from wekan/mongo-tools now
downloads them from wekan/mongo-tools-patches: the amd64 base bundle, the
per-arch overwrite in the Linux bundles and in repack-bundle-for-arch.sh, the
Windows and macOS bundle jobs, check-arch-binaries.sh, require-binaries.sh,
test-download-urls.sh, the Dockerfile, both snapcraft files, the Flatpak and
AppImage workflows, the Sandstorm build-deps note and the CPU-platforms docs.
wekan/mongo-tools was a fork of a large Go project that changed none of its
source - its six commits were all the build workflow. wekan/mongo-tools-patches
keeps that build and drops the fork: it clones the newest upstream
mongodb/mongo-tools release, applies the patches in dist/ (there are none yet,
which is the honest state of it), and publishes the same <tool>-<arch>[.exe]
assets with a .sha256sum beside each - the same model wekan/node-patches
replaced the wekan/node fork with.
Nothing else changes: the asset names, the per-tool tolerance for an
architecture that has no binary, and the checksum verification are what they
were, because the build script came across unchanged.
The new checkout is excluded from git and from Meteor's scan the same way
node-patches and the old mongo-tools clone are.
Thanks to xet7 !
WeKan's bundle .zip, Docker image and snap now resolve their Node.js from
three sources in order - https://nodejs.org/dist/ , then
https://unofficial-builds.nodejs.org/download/release/ , then the
wekan/node-patches releases - instead of only from the retired wekan/node
fork. A platform none of the three publishes a Node.js for is NOT BUILT that
release rather than failing it, and returns by itself on the first run after
one appears. Sandstorm is amd64 only and untouched.
releases/resolve-node-source.sh is the one place that order and the
platform-name mapping live; the bundle jobs, the extra-architecture preflight
and the Dockerfile all ask it, so the image and the .zip of one CPU cannot be
built on Node.js from different places. The snap takes its node out of the
bundle, so it follows without a change of its own.
Thanks to xet7 !
The win32 and mac-x64 preflights checked .../releases/download/${NODE_VERSION}/…
with NODE_VERSION=24 (the bare MAJOR), which 404s - the fork tags by full version
(v24.19.0) - so both jobs ALWAYS skipped. They now resolve the newest v24.x fork
tag carrying the asset via a shared helper, releases/resolve-fork-node-tag.sh
(authenticated with the workflow GITHUB_TOKEN, so the GitHub API is not
rate-limited); the win32 preflight hands the resolved node_full to the rebuild.
And the win32 native-module rebuild is completed. npm_config_arch=ia32 alone was
not enough: an ia32 addon must LINK against an ia32 node.lib, and nodejs.org
dropped 32-bit Windows in Node 23, so node-gyp cannot fetch win-x86/node.lib. The
rebuild now assembles a nodedir node-gyp CAN use - node headers (arch-independent,
from nodejs.org) plus the fork's own node-win32.lib (now published beside
node-win32.exe) at the two paths node-gyp looks in - and points node-gyp at it
with npm_config_nodedir, so bcrypt cross-builds to ia32 against the fork's Node.
(The inline python that resolved the tag broke YAML - a multi-line heredoc cannot
be indented into a `run: |` block - which is why it is a helper script, reused by
both preflights and mirroring embed-verified-node.sh / check-arch-binaries.sh.)
Thanks to xet7 !
Every extra arch is built by running the fork's target-CPU node UNDER QEMU to
rebuild the native modules, and qemu-user does not run every Node.js binary
perfectly. ppc64le crashed at node startup deserializing its V8 snapshot:
# Check failed: IsFreeSpaceOrFiller(filler).
... v8::Isolate::Initialize ...
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
install-node-for-arch.sh: line 144: npm install ... Error 133
so the ppc64le leg failed. With ppc64le (and riscv64) still marked REQUIRED, one
such emulated-CPU failure failed the whole build-extra-arches matrix job.
They join s390x/i386/armhf/armv7/loong64 as best-effort (optional: true): a leg
that cannot run this release SKIPS with a warning instead of failing, so the
matrix never fails on one exotic CPU, the docker job (which now builds only the
bundles that landed) is never dragged down, and the release ships whatever built.
amd64 and arm64 (native, not in this matrix) remain the required core. ppc64le
returns the release it runs cleanly again - its qemu/snapshot crash is a
node-fork/emulation issue to chase separately, not something this bundle build can
fix inline.
Thanks to xet7 !
Three separate native-bundle failures in one release run:
* mac-arm64 failed the major->tag resolution. embed-verified-node.sh and
check-arch-binaries.sh call api.github.com to find the fork's newest v24.x tag,
but no step passed a token, so the call was UNauthenticated - 60 requests/hour
per IP, shared across runners - and 403-rate-limited intermittently. That is why
amd64 (which ran first) resolved fine while mac-arm64 (later) did not. A
workflow-level GITHUB_TOKEN: ${{ github.token }} authenticates every such call
(5000/hour), fixing the native jobs and the extra-arch preflight alike.
* win64 failed because the fork published node-win64.exe WITHOUT its
node-win64.exe.sha256sum, and the embed helper 404'd on the sidecar. The
checksum is a belt-and-suspenders check on top of an already-authenticated HTTPS
download from the fork, so a MISSING one is now a warning and the binary ships
UNVERIFIED (a checksum that is present and does NOT match is still fatal). This
matches how check-arch-binaries.sh already treats a missing fork checksum.
* win32 failed at setup-node: "Unable to find Node version '24' for platform win32
and architecture x86" - there is NO 32-bit Windows Node 24 (the reason the fork
exists). It now runs the runner's x64 Node to DRIVE node-gyp and cross-builds
the native modules (bcrypt) to ia32 via npm_config_arch=ia32; the shipped
node.exe is still the fork's 32-bit node-win32.exe. tests/releaseBundleCoverage
is updated for the ia32 cross-build.
Thanks to xet7 !
The docker job `needs: build-extra-arches`, a matrix. When any leg failed - a
single exotic CPU like ppc64le - the whole matrix job was "failed", and a job
whose `needs` dependency failed is SKIPPED. So one failed extra-arch skipped the
ENTIRE multi-arch image, even though amd64/arm64 and the other arches were fine.
Two changes make the image resilient:
* The job now runs on `always() && needs.release.result == 'success'`, so a
partially-failed build-extra-arches no longer skips it. It still lists
build-extra-arches in `needs`, so it waits for the successful legs to upload
their bundles first.
* A new "Decide which platforms" step probes which wekan-<version>-<arch>.zip
bundles actually landed on the release. amd64 and arm64 are required (no image
without them, and the release would have failed already); the exotic arches
(ppc64le, s390x, riscv64, 386, arm/v7) are included only if their bundle is
present, and a missing one is a ::warning that drops just that platform. The
decided set drives the wait loop, buildx --platform "${PLATFORMS}" and the
push-verify want="${WANT}" from one place, so they always agree.
The result: a failed or best-effort-skipped exotic arch drops only itself from
the image and returns the next release that builds it; the image is never skipped
and never fails because of one CPU. tests/releaseDockerPlatforms.test.cjs and the
docker cross-check in tests/releaseSnapArches.test.cjs are updated for the
decided-set design (required amd64/arm64, optional exotics, loong64 excluded).
Thanks to xet7 !
build-amd64 (and the other native jobs) call
embed-verified-node.sh .build/bundle/node node-x64 "$NODE_VERSION"
but $NODE_VERSION is the pinned MAJOR, '24', while the wekan/node fork tags its
releases by full version, v24.19.0. So the helper built the URL
https://github.com/wekan/node/releases/download/24/node-x64
which 404s, and the amd64 bundle failed at the Node embed step.
embed-verified-node.sh now resolves a bare major to the newest fork tag v<major>.x
that actually carries the asset (the same GitHub-API walk check-arch-binaries.sh
uses), and takes a full tag (with or without the leading v) as given. If no
v<major>.x release has the asset it stops with a message naming the fork asset to
build, rather than 404-ing on a bad URL.
Note: this fixes the URL; a build still needs the fork to HAVE published the
asset. As of now the fork's v24.19.0 carries only node-mac-x64/node-win32.exe/
node-win64.exe - its node-x64/node-arm64/node-mac-arm64 and the Linux arches were
dropped when the "release all missing" run replaced the assets, so those bundles
cannot build until the fork republishes them (a wekan/node-side fix).
Thanks to xet7 !
The wekan/node fork builds Node.js for 13 platforms and WeKan takes its Node.js
only from the fork, so every one of those platforms should have a WeKan .zip
bundle. Twelve did; 32-bit Windows (win32) and Intel macOS (mac-x64) did not -
the fork builds node-win32.exe and node-mac-x64 (nodejs.org has neither a 32-bit
Windows nor, going forward, a place WeKan will take Intel macOS from), but there
was no job to turn them into bundles. This adds both.
build-win32 mirrors build-win64 on a windows runner, with two differences: it
installs a 32-bit (x86) Node via setup-node so the native modules it rebuilds
(bcrypt) are ia32, matching the fork's 32-bit node.exe the bundle ships, and it
takes ferretdb-win32.exe. build-mac-x64 mirrors build-mac-arm64 on a macos-13
Intel runner, taking node-mac-x64 and ferretdb-mac-amd64.
Both are BEST-EFFORT: a preflight step checks whether the fork has published the
platform's node binary for this version and, if not, SKIPS the job with a warning
instead of a red failure - the fork builds these on its own schedule, and the
bundle appears the run after the fork publishes the binary. Every build step is
gated on that skip. release-notes waits for both so their provenance rows land in
the table. tests/releaseBundleCoverage.test.cjs pins that all six native fork
assets and all seven extra-arch legs map to a bundle; the cpu-exec and snap-arch
guards learn about the two new non-Linux bundles and the armv7 leg.
Thanks to xet7 !
The wekan/node fork builds a generic ARMv7 Node.js (node-armv7) as well as
Debian's hard-float one (node-armhf); each is a real fork platform, so each gets
its own WeKan .zip bundle. This adds an armv7 leg to build-extra-arches: it runs
in the same linux/arm/v7 emulated container as armhf, takes its Node.js from the
fork's node-armv7, and shares FerretDB's armhf binary (FerretDB has no distinct
armv7). It is best-effort (optional), like the other 32-bit ARM/x86 bundles - if
the fork's node-armv7 is ever absent for this major it skips rather than failing
the matrix job. The result is wekan-<version>-armv7.zip alongside the armhf one.
tests/releaseArchSkipAndBaseAttach.test.cjs pins armv7 as a best-effort matrix
entry.
Thanks to xet7 !
WeKan now takes its Node.js from the wekan/node fork for EVERY platform and from
nowhere else - the .zip bundles, the emulated cross-builds and the multi-arch
Docker image alike. The reason is control: the fork is Node built from source, so
a Node bug can be PATCHED and rebuilt, which cannot be done with nodejs.org's or
unofficial-builds' opaque binaries, and one source means a set of artifacts is
never half built on one Node.js and half on another depending on the CPU. The
fork already covers the CPUs the other two do not build at all (32-bit x86/ARM,
loong64, ...), so it is the only source that fits every platform.
check-arch-binaries.sh no longer walks nodejs.org -> unofficial-builds -> fork;
it lists the fork's OWN releases for this major, newest first, and takes the
newest that carries node-<arch>, verifying it against that release's
node-<arch>.sha256sum. install-node-for-arch.sh drops the official/unofficial
tarball branch and always installs the fork's bare node binary (grafting npm -
arch-independent JavaScript - from the official amd64 tarball, a build-time tool,
not the shipped node). The Dockerfile maps every TARGETARCH to a fork asset
(node-x64/arm64/ppc64le/s390x/riscv64/i386/armhf) and installs it the same way.
s390x becomes best-effort (optional) like i386/armhf/loong64: the fork has not
published node-s390x for this major yet, so the preflight SKIPS it - a warning,
exit 0 - instead of failing the whole matrix job and skipping docker with it, and
it returns on its own the release after the fork publishes node-s390x. ppc64le
and riscv64 stay required - the fork builds them reliably.
tests/releaseArchSkipAndBaseAttach.test.cjs pins the fork-only sourcing (no
official/unofficial fallback for the node binary) and the s390x skip.
Thanks to xet7 !
The docker job built and pushed the multi-arch image for all seven platforms
correctly; the step AFTER it, which inspects each registry's manifest to prove
every platform actually arrived, then failed the run over a manifest that was
right.
buildx builds linux/arm/v7, but a registry records that manifest as architecture
"arm" with variant "v7" in a separate field. The verify step's imagetools
--format printed only `{{.Platform.OS}}/{{.Platform.Architecture}}`, so the entry
read back as bare "linux/arm", and the check for "linux/arm/v7" in want= never
matched it - "wekanteam/wekan:v10.67 has no linux/arm/v7 in its manifest (it has:
... linux/arm ...)". The image was complete; the check was blind to the variant.
The --format now appends `/{{.Platform.Variant}}` when a variant is present, so
32-bit ARM reads back as linux/arm/v7, and a trailing /v8 is normalised away so
arm64 (which a registry may record as arm64/v8) still matches want=, which names
it the way everyone writes it, linux/arm64. tests/releaseDockerPlatforms.test.cjs
pins the variant-aware format and the /v8 normalisation so an OS/arch-only format
cannot come back.
Thanks to xet7 !
WeKan takes its Node.js from the wekan/node fork for EVERY platform now, not
only the arches nobody else builds. The reason is control: the fork is Node
built from source, so a Node bug can be patched and rebuilt - which cannot be
done with nodejs.org's opaque binaries - and one source means a set of bundles
is never half built on one Node.js and half on another. The fork also already
covers the arches nodejs.org and unofficial-builds do not build at all (32-bit
x86/ARM, loong64, win32), so it is the only source that fits every platform.
The four native bundles (amd64, arm64, win64, mac-arm64) embedded a verified
nodejs.org tarball; embed-verified-node.sh now downloads the fork's bare
node-<asset> binary (node-x64 / node-arm64 / node-win64.exe / node-mac-arm64)
and verifies it against the node-<asset>.sha256sum the fork publishes beside it.
That is all a bundle needs - it ships the node binary and runs `node main.js`;
the BUILD still uses the runner's own node+npm, so no npm is grafted here (the
Docker image and the emulated cross-builds, which run npm, graft it separately).
Provenance records source wekan/node and the fork's SHA256.
tests/releaseNodeVerified.test.cjs pins the fork source for all four.
The extra-arch bundles, the Docker image and a new win32 bundle move to the fork
too, in following commits.
Adds two Docker platforms that were shipping as .zip bundles only.
Base image: ubuntu:26.04 -> debian:trixie. Ubuntu publishes no linux/386
image (which is why 386 could never build); Debian does, and debian:trixie
carries every arch this image targets - amd64, arm64, 386, arm/v7, ppc64le,
riscv64, s390x - so one base covers them all, and it is the same base the
per-arch .zip bundles already build in. (The Dockerfile installs no MongoDB
server - every arch defaults to the bundle's FerretDB - so nothing here is
Ubuntu-specific; sha checks switched from `shasum` to `sha256sum`, which is
coreutils and always present.)
Node.js: nodejs.org and unofficial-builds ship no Node 24 for 32-bit x86 or
ARM, but the wekan/node fork does - as a BARE node binary (node-i386 /
node-armhf) plus a .sha256sum, not a tarball. A new `fork` branch in the arch
case downloads that binary, verifies it against its .sha256sum, and grafts npm
+ npx from the official amd64 tarball (npm is arch-independent JavaScript that
runs on the fork's node). Debian's 32-bit ARM port is armhf (ARMv7 VFPv3-D16),
which is what linux/arm/v7 runs, so node-armhf is the match.
linux/386 and linux/arm/v7 go back into the buildx --platform list and the
want= verify list. linux/loong64 stays out: no Docker base publishes it and the
registries do not agree on its manifest yet. tests/releaseDockerPlatforms.test.cjs
now checks the debian base, that 386/arm/v7 are in and loong64 out, and that
every built platform has a matching branch in the Dockerfile arch case.
NOT built here (no buildx/emulation) - confirm on CI. Depends on the fork having
published node-i386 / node-armhf and the bundle having wekan-<v>-{i386,armhf}.zip
for the release.
With linux/386 gone, the multi-arch build got past the base image and then
failed inside the Dockerfile RUN on linux/arm/v7:
+ echo Unsupported architecture: arm
+ exit 1
Docker's TARGETARCH for linux/arm/v7 is `arm`, and the Dockerfile's arch case
handles only amd64/arm64/ppc64le/s390x/riscv64 - it deliberately has no `arm`
branch, because it installs Node.js from nodejs.org / unofficial-builds and
NEITHER ships a Node 24 for armv7l (the Dockerfile comment says so). But
linux/arm/v7 was still in the buildx --platform list, so the RUN hit the
"Unsupported architecture" guard and the whole build failed.
linux/arm/v7 is removed from --platform and from the want= verify list, joining
linux/386 and linux/loong64: all three ship as .zip bundles (armhf's Node comes
from the wekan/node fork there) but not as Docker images, because the image
sources its Node from nodejs.org/unofficial only. tests/releaseDockerPlatforms.test.cjs
now pins arm/v7 out of both lists too.
With loong64 no longer skipping build-extra-arches, the docker job ran again
for the first time in a while and failed at the base image:
#2 ERROR: no match for platform in manifest: not found
ubuntu:26.04: failed to resolve source metadata ... no match for platform
The image is FROM ubuntu:26.04, and Ubuntu publishes no i386 image, so
`docker buildx build --platform ...,linux/386,...` cannot resolve the base for
that one platform and the whole multi-arch build stops - the workflow's own
bundle-build comment already notes `docker run --platform linux/386
ubuntu:26.04` answers "no matching manifest".
linux/386 is removed from the build's --platform list and from the want= list
that verifies the pushed manifest, exactly as linux/loong64 already was: i386
ships as a .zip bundle (built on debian:trixie, which has 386) but not as a
Docker image. tests/releaseDockerPlatforms.test.cjs pins that 386 and loong64
are out of both lists, that the two lists match, and that the base is
ubuntu:26.04.
Group the Upcoming entries by area, per CLAUDE.md - a subsection with more
than one entry is grouped, not loose: "Extra-architecture bundles" (loong64)
and "The Launchpad snap builds" (the flatten and the licence-hint fix). The
In short now accounts for the third entry in a closing clause.
The Launchpad project xet7-craft-remote-build is set to MIT / X/Expat, but the
snap-launchpad failure hint printed "check its Licence, 'None specified' ... set
the licence to MIT" on EVERY failure - so an s390x build that Launchpad stopped
for another reason read as a licence problem that was already fixed, and the
time went to re-checking a correct setting.
The hint now says the licence should already be MIT (re-set it only if the page
shows "None specified") and, for the real remaining case, explains that a
"Stopped" build with a BUILDING (not FAILED) log that ends mid-step is Launchpad
cancelling the build as it runs - typically an OOM in the memory-heavy Meteor
npm install, or a transient build-farm reset, both of which the three retries
already cover. The large-history push that also broke these builds is fixed
separately by the repo flatten (previous commit).
The ppc64el (and before it v10.55 riscv64) snap-launchpad build failed with
"Git operation failed with: Could not push 'HEAD' to git.launchpad.net/...
snapcraft-wekan-<hash>", ~4-5 minutes into the push, on every one of the three
attempts. snapcraft remote-build pushes the project's git repository to
Launchpad and builds it there; it rejects a SHALLOW clone (which is why the
checkout is fetch-depth: 0), but it does not need the history, and WeKan's full
history is large enough that the push times out or is refused mid-upload.
After the full checkout, the repo is now re-initialised as ONE commit of the
tagged tree: git rev-parse --is-shallow-repository is still false, so
remote-build accepts it, but the push carries the source tree (tens of MB)
instead of the whole history (hundreds). The snap version comes from
snapcraft.yaml (verified in the next step), not git-describe, so dropping the
history changes nothing about what is built. tests/releaseSnapLaunchpadFlatten.test.cjs
pins the flatten, its order, and that the checkout stays full-depth.
The docker job needs build-extra-arches, and GitHub skips a job whose needed
job failed. build-extra-arches is a matrix, and its loong64 leg hard-failed:
no debian/ubuntu image publishes linux/loong64 (node-loong64 and
ferretdb-loong64 exist, the container does not), so the preflight stopped it.
One failed matrix leg makes the whole build-extra-arches job "failure", which
SKIPPED docker - and through docker the charts, ucs and nextcloud jobs that
need it. That is what left docker skipped in run #209.
loong64 is now optional: true, like i386 and armhf, and check-arch-binaries.sh
skips a best-effort arch whose BASE IMAGE is missing - not only one whose
Node.js is missing - with a warning and exit 0 emitting skip=true, gated the
same way every other best-effort skip is. So the matrix job succeeds and docker
runs; loong64 stays visible as a skip and returns to a real build the day a
linux/loong64 base image is published.
The release job in v10.63 and v10.64 shipped with no amd64/arm64 bundle, and
every downstream snap/docker/AppImage job 404'd on wekan-<version>-amd64.zip.
The cause was not softprops (v10.63's guess) but the checkout: the job
downloaded the bundles into the workspace and THEN ran actions/checkout for the
provenance script. The workspace is not a git repo at that point, so checkout's
first act is "Deleting the contents of '<workspace>'" to make room for a fresh
clone - and it does this even with `clean: false`, which only skips the
`git clean` in an already-checked-out repo. The just-downloaded
wekan-<version>-{amd64,arm64}.zip were deleted before the attach step, which
then failed with "wekan-<version>-amd64.zip is missing or empty".
The checkout now runs FIRST, into the empty workspace, and the bundles are
downloaded on top of the checked-out tree, where nothing removes them.
tests/releaseBundlesSurviveCheckout.test.cjs now pins the ORDER (checkout
before the bundle download) rather than clean: false, which was never enough.
Thanks to xet7 !
Opening an admin report by its address - /admin/problems/files typed,
bookmarked or refreshed - drew the column headers, "No results" and a
"1 / 1" pager over data that was plainly there, while the count method
reported five. 78b2f9ebc fixed one half of this (re-subscribe once the
login lands) but the report still came up empty, because the deeper cause
was untouched.
The onCreated autorun opens the pane and subscribes when problemsOpenPane
or the logged-in user changes. It called openReportPane()/loadReport()
directly in its reactive body, so it became reactive on cfg.count -
loadReport reads it through pageInfo - and loadReport's own count method
then did cfg.count.set(...). That re-ran the autorun, and a Meteor.subscribe
made inside an autorun is AUTO-CANCELLED when the autorun re-runs; the
re-run took the "same user, same pane" branch, did not re-subscribe, and
left the report with no subscription at all - "attachments in minimongo: 0".
Reached from the menu it worked, because switchMenu opens the pane from an
EVENT, not a computation, so that subscribe was never auto-managed; only
the URL path, which runs inside the autorun, hit it.
The autorun now reads only paneId and userId reactively and runs its body
inside Tracker.nonreactive, so cfg.count.set no longer re-runs it and the
subscribe is not auto-cancelled. The subscription's lifetime is managed by
loadReport (stops the previous) and a new onDestroyed (stops the last)
instead of the autorun. tests/adminReportsSubscriptionLifetime.test.cjs
pins the nonreactive body and the onDestroyed cleanup.
Thanks to xet7 !
Repoint the Upcoming section's commit links after the version-bump rebase
moved the two code commits to new hashes:
081d50b45 -> e802d52eed and
17d7493d6 -> 55463f685a .
Two release-build failures from the v10.63 run (logs in ../log/wekan3):
1. The release shipped NO amd64/arm64 bundle, so every snap job (native,
wekan-ondra, wekan-gantt-gpl) 404'd on wekan-10.63-amd64.zip. The base
bundles were the only ones attached by the central `release` job with
softprops `files:`, which does not fail on an unmatched file - so a run
that produced no zip created a release with none and reported success,
and softprops never listed the .sha256sum either. Every other bundle
self-attaches with `gh release upload --clobber`, loud on a missing file
and verified from the release side. The release job now attaches amd64
and arm64 the same way - failing the release if a base bundle is missing
instead of 404'ing ten downstream jobs - and checksums the exact bytes it
attaches so the base bundles get a .sha256sum like the rest.
2. build-extra-arches failed on i386 and armhf: Node has no linux-x86 build
at all, and no source builds Node 24 for armv7l, so there is nothing to
build a bundle against. They are now marked best-effort (optional: true);
when its Node.js is absent everywhere, check-arch-binaries.sh emits
skip=true (a warning, exit 0) and the build steps are gated on it, so the
arch is skipped rather than failing the run. It returns on its own the
first release after wekan/node publishes node-i386 / node-armhf. A
required arch whose Node.js is missing is still fatal.
tests/releaseArchSkipAndBaseAttach.test.cjs pins both; the base-attach guard
in tests/releaseBundlesSurviveCheckout.test.cjs is updated to the new path.
Thanks to xet7 !
The four native bundles (amd64, arm64, win64, mac-arm64) shipped Node.js
with `cp $(command -v node)` - the runner's node. It has no published
checksum, so the release provenance table could only say "no checksum
published" and nobody could tell WHICH Node.js build a platform carried -
the exact thing needed when a Node.js CVE lands. Worse, build-arm64 has
no setup-node, so ubuntu-24.04-arm's DEFAULT Node 22 went into the arm64
bundle instead of the pinned Node 24, silently.
Each native bundle now downloads the pinned Node.js for its OS+CPU from
nodejs.org and verifies it against SHASUMS256.txt
(releases/embed-verified-node.sh), and verifies FerretDB against the
.sha256sum wekan/FerretDB now publishes beside every binary. Provenance
records nodejs.org + the exact version + the verified SHA256; win64 and
mac-arm64 now upload provenance too, so every platform is traceable. The
emulated arches already did this via install-node-for-arch.sh.
tests/releaseNodeVerified.test.cjs pins that no native bundle goes back
to the runner's node or an unverified download.
Thanks to xet7 !
releases/expected-assets.sh looks for WeKan-<v>-<arch>.AppImage.sha256sum and
WeKan-<v>-<arch>.flatpak.sha256sum (asset name + .sha256sum, the same convention
the wekan-<v>-<arch>.zip.sha256sum bundles use). But the builds wrote
WeKan-<v>-<arch>.sha256sum - extension DROPPED - so "what the release is missing"
never found the checksum and rebuilt the AppImage and Flatpak on every run even
when they were already published. The checksum (and md5sum) now keep the
.AppImage / .flatpak extension, matching what the check expects.
This is the root cause of the snap / docker / AppImage 404s on
wekan-<version>-amd64.zip. The `release` job downloads the per-arch bundles to
the workspace root, then checks the repo out (for the provenance script) BEFORE
creating the GitHub Release. actions/checkout defaults to clean: true, whose
`git clean -ffdx` deleted those untracked zips - so the "Create GitHub Release"
step's `files: wekan-<version>-{amd64,arm64}.zip` matched nothing. softprops does
not fail on unmatched files, so the release was created (job "success") WITH NO
BUNDLES, and every downstream job that downloads a bundle 404'd. The checkout now
sets clean: false, so the bundles survive and are attached.
Also: the snapcraft `wekan` part downloaded the bundle with a single wget that
treated a 404 as fatal, so it also broke on the brief CDN lag right after an
upload. It now retries (--tries/--retry-on-http-error), like the curl downloads
elsewhere in the release.
tests/releaseBundlesSurviveCheckout.test.cjs pins that a checkout after the
bundle download keeps clean: false; it fails on the pre-fix workflow.
The snap i386 platform was removed because core24 cannot build it; this guard
still pinned i386 as a snap platform and a Launchpad arch. Updated to expect the
six buildable snap platforms (amd64, arm64, armhf, ppc64el, riscv64, s390x) and
to treat i386 like loong64 - an arch that has a wekan-<arch>.zip BUNDLE but is
deliberately not a snap - with the reason recorded in the test.
core24 has no i386 port, so `base: core24` cannot build an i386 snap (removed in
the previous commit). Debian still ships i386 and is glibc, so - unlike an
Alpine/musl base - WeKan's existing binaries run unchanged. Since the WeKan snap
only assembles the prebuilt wekan-<arch>.zip (and wekan-i386.zip already exists),
the only missing piece for an i386 snap is an i386-capable base.
snap-base-debian/ adds `wekan-base-debian13` (type: base), a trimmed Debian
trixie rootfs, starting with i386 - which builds NATIVELY on an amd64 runner (no
qemu, no Launchpad). It is isolated from the working core24 snapcraft.yaml so it
can never break the mainstream builds.
This is a documented SCAFFOLD, not a tested artefact: a custom base snap is
advanced snapcraft and needs a real `snapcraft pack` + local install + a WeKan
snap running on top before it is wired into CI or sent for the (manual) store
review. README.md carries the full plan, the local test loop, the publish/ACL
steps, and the known pitfalls.
The v10.60 release job succeeded (the release-notes shell-injection fix landed),
but four of the per-platform build jobs failed, each for its own reason:
- build-win64: the "Check the binaries" step ran `set -euo pipefail` under the
Windows default shell (PowerShell), which answered "A parameter cannot be found
that matches parameter name 'euo'". It is a bash script; it now says
`shell: bash`.
- build-mac-arm64: the zip step ran `sha256sum`, which does not exist on macOS
(that is the GNU coreutils name), so the job died with exit 127. Use
`shasum -a 256`, the BSD/macOS spelling, which writes the same format.
- build-extra-arches: the job downloaded wekan-<version>-amd64.zip but never
unpacked it, so the container mounted an EMPTY /bundle and the native-module
rebuild died with "ENOENT ... /bundle/programs/server/package.json" (exit 254).
Added the unzip the arm64/win64/mac-arm64 jobs already do.
- snap-native / snap-launchpad: snapcraft.yaml declared an i386 platform, but
core24 (Ubuntu 24.04) has no i386 port, so snapcraft rejected it with "trying
to build snap in one of ['i386'], but none of these build architectures are
supported" - a PARSE error that failed EVERY snap build, not only i386's.
Removed the i386 platform and its snap-launchpad matrix entry; i386 users are
served by the .deb and AppImage, and an i386 snap is not buildable on a modern
base.
loong64 still reports its documented "debian:trixie has no linux/loong64 image"
gap (there is no loong64 userland to rebuild in), which is intentional and left
visible.
These jobs do not build WeKan from source — they download the prebuilt release
zip (wekan-<version>-<arch>.zip) that release-all.yml publishes, and fail hard
if it is missing. So they failed whenever they ran before the release was
complete: dockerimage.yml / docker-publish.yml on a push or a tag pushed early
in the release, and AppImage.yml when release-all-missing asked it to wrap a
version whose base bundle was not published (`gh release download` → "no assets
to download"). The v10.59 release itself had failed (the release-notes shell
injection, fixed separately), so every one of these downstream jobs 404'd.
Each now checks whether the release asset it needs is published and SKIPS with a
notice (a green run) when it is not, instead of failing:
- dockerimage.yml / docker-publish.yml gate the image build on the pinned
version's amd64 zip being on the release;
- AppImage.yml flips its per-arch BUILD_THIS off when that arch's bundle is
absent, and its publish job treats "no AppImage, and no base bundle either" as
nothing-to-do rather than an error.
The real images/AppImages are still built by release-all.yml's own jobs once the
release is up; these standalone/gap-filling runs simply stop failing in the
meantime.
The release and release-notes jobs built the GitHub Release body with
`printf '%s\n' "${{ needs.prepare.outputs.changelog }}"`. Interpolated inline,
the CHANGELOG becomes part of the shell source before bash parses it, so every
backtick in it runs as a command. The v10.59 notes are full of `code` spans, so
the release job failed with "Incorrect: command not found",
"loginFailureDecision.js: Permission denied", "POST: command not found" and
published no release. The changelog now reaches both steps through the
environment (env: CHANGELOG), and the scripts use "$CHANGELOG", where the shell
treats it as data and never parses its backticks, $( ) or quotes.
tests/releaseNotesNoShellInjection.test.cjs pins that outputs.changelog is only
ever consumed as an env: assignment, never inline in a run: script; it fails on
both pre-fix printf lines.
Thanks to xet7.
The binary pre-check `bash releases/require-binaries.sh`, wired into the build
jobs, needs the repo on disk, but three jobs did not have it there:
- build-arm64 and build-mac-arm64 download a prebuilt bundle artifact and never
checked the repo out at all, so the "Check the binaries ..." step died with
exit 127 ("releases/require-binaries.sh: No such file or directory") before a
bundle was ever assembled. Each now checks the tag out first, before
download-artifact drops the bundle into the same workspace.
- build-win64 checks the repo out into src/ (for start-wekan.bat and
snapcraft.yaml) but called the script at the workspace root. It now calls
src/releases/require-binaries.sh, the same src/ path its start-wekan.bat copy
already uses.
tests/releaseBuildJobsCheckout.test.cjs pins, for every build job that runs
require-binaries.sh, that the job checks the repo out where the call looks for it
(root vs src/) and that a root checkout precedes download-artifact so it cannot
wipe the downloaded bundle. It fails on all three pre-fix breakages.
Thanks to xet7.
GHSA-2g94-9x3m-hv37. Two verified weaknesses on the login path chained into
account takeover, and both are fixed here.
1. The bundled wekan-accounts-lockout brute-force protection was completely
inert. Its two Accounts.validateLoginAttempt hooks decided whether an attempt
failed by comparing the error's reason string ('Incorrect password' /
'User not found'), but Meteor's accounts-base ships ambiguousErrorMessages
defaulting to true, so _handleError rewrites every credential failure to
"Something went wrong. Please check your credentials." before those hooks run.
The literals never matched, both hooks returned early, the failure counter
was never incremented, and no account ever locked. The hooks now decide from
the attempt's structural fields (new loginFailureDecision.js): any genuine
password failure counts, while the benign 'no-2fa-code' step (password already
correct, second factor still to come) never counts, so 2FA users are not
locked out of their own sign-in.
2. The login path leaked which accounts exist by timing: a real user runs bcrypt
(~50 ms) while a missing one returns in ~2 ms. A dummy bcrypt comparison
against a fixed cost-10 hash (loginTimingDefense.js) equalises the missing-user
path on the DDP login method (loginTimingNormalization.js, a handler that runs
ahead of the built-in one and never authenticates) and on the REST endpoint.
The REST POST /users/login twin also enumerated by message (a distinct
"...not found." string) and never ran the lockout hooks at all. It now fails
missing-user and wrong-password identically, runs the timing equaliser, and
throttles failed attempts per client address (loginAttemptThrottle.js), keyed
safely behind HTTP_FORWARDED_COUNT, resetting on success.
Tests: loginFailureDecision, loginTimingDefense, loginAttemptThrottle and
loginBruteForceEnumerationWiring (four new plain-Node suites).
Thanks to NinjaGPT and xet7 !
Fixes GHSA-2g94-9x3m-hv37.
`uses: ./.github/workflows/X.yml` fails at STARTUP - taking the calling
workflow down with it, so nothing runs and there is no job log to read - when
X.yml does not exist, has no `workflow_call` trigger, or is handed a `with:`
key it never declared. That is the same class of failure as the job-level
`if:` reading matrix, and just as invisible: the YAML is valid, and only
GitHub's loader objects.
It is worth pinning now because release-all-missing.yml calls AppImage.yml
and Flatpak.yml here, TSC's calls five workflows, and the `only` input they
all take was added by hand to each of them. One typo in a `with:` key would
stop the whole run with "error parsing called workflow".
Parsed by indentation rather than with js-yaml, which is not a dependency of
this repository. These files are written in a fixed shape, and the two things
this needs - which workflows a job calls with which `with:` keys, and which
inputs a workflow declares under workflow_call - are read from it directly.
Verified against all three shapes by breaking each in turn:
passes 'onlyy' which AppImage.yml does not declare
calls missing Nope.yml
AppImage.yml has no workflow_call
and checked across every repository first - TSC, wekan, both variants, node,
FerretDB, mongo-tools and gitea - where all reusable-workflow calls already
match.
Thanks to xet7 !
The `only` filter I added to the build workflows was written as a job-level
condition:
if: ${{ inputs.only == '' || contains(fromJSON(inputs.only), matrix.arch) }}
GitHub refuses to load a workflow that does this:
Invalid workflow file
(Line: 109, Col: 9): Unrecognized named-value: 'matrix'
`matrix` is available to a job's runs-on, env, name, container, services,
continue-on-error, timeout-minutes, strategy and steps - but NOT to
`jobs.<id>.if`, which is evaluated before the matrix is expanded. It looks
entirely reasonable, which is why it was written in five workflows in one
sitting.
It is worse than a job that does not run: a workflow that will not load takes
every workflow that CALLS it with it, so TSC's release-all-missing.yml failed
at startup with "error parsing called workflow" and built nothing at all.
The decision moves to the job's `env:`, which CAN see matrix, and every step
asks `if: ${{ env.BUILD_THIS == 'true' }}`. Steps that already had a
condition keep it, ANDed inside parentheses - matrix.emulated,
matrix.mode == 'windows' and the rest are unchanged.
Fixed in AppImage.yml and Flatpak.yml here, and in the same commit's worth of
changes in TSC (Deb, AppImage, Flatpak, Windows, Mac), wekan/node,
wekan-ondra and wekan-gantt-gpl. Twelve files.
tests/workflowExpressions.test.cjs is the guard, and it exists because a YAML
parser is perfectly happy with every one of these: the file is valid YAML and
only GitHub's expression evaluator rejects it, when the workflow is
dispatched. It pins that no job-level `if:` reads matrix or steps, that every
${{ }} is closed, and that a workflow declaring an `only` input actually
consults it - a filter that is declared and ignored would quietly build
everything, which is the failure that looks like success.
Verified by putting the bad line back: the guard fails with
"job-level if: cannot see matrix" and names AppImage.yml:107.
The closed-brace check counts differently than it first did, because three
real lines broke it: these workflows run docker with Go templates
(--format '{{range .Manifest.Manifests}}...'), which are full of `}}` that
close nothing of GitHub's. It strips complete expressions and looks for a
leftover opener instead of counting braces.
Thanks to xet7 !
release-all.yml is one run that bumps the version, tags, builds every
platform, and publishes Docker images, snaps, the website and the charts. It
is the right thing for MAKING a release and the wrong thing for FINISHING
one. When the v10.57 run ended with all six extra architectures missing -
four on a shell-quoting bug, two on a base image that is not built for their
CPU - there was no way to get those six except to run the whole thing again,
version bump and all.
This finishes a release that already exists. It never bumps a version, never
tags, and never touches Docker, snap, the website or the charts.
What makes it possible: only build-amd64 runs Meteor. Every other bundle
WeKan ships is that same bundle with its native modules rebuilt, its Node.js
swapped and its database binaries replaced. So this downloads the PUBLISHED
wekan-<v>-amd64.zip - verifying its checksum, since it is the bundle every
other architecture is cut from - and repacks it with
releases/repack-bundle-for-arch.sh, the same script release-all.yml's
build-extra-arches runs. A bundle added to a release months later is
therefore built exactly like the ones already on it.
It builds the six extra architectures and calls AppImage.yml and
Flatpak.yml, which are reusable workflows now and take the same `only`
filter.
It does NOT claim to build everything, and says which: amd64 is the Meteor
build, arm64/win64/mac-arm64 each need their own kind of runner and their own
steps, and the Sandstorm .spk is signed. When one of those is missing the run
names it and points at release-all.yml, as a warning rather than a failure.
What a complete release looks like is releases/expected-assets.sh, in one
place, with the kind of each asset saying which build makes it. Present means
the .sha256sum is there too - a bundle whose checksum upload failed is
half-published - except the .spk, which is signed rather than checksummed.
Verified against the real v10.57 release: every one of its five assets
matches a name this predicts, with nothing left unaccounted for. Three
states, through the plan's own logic:
v10.57 as published 6 extra + 4 AppImage/Flatpak to build; amd64, arm64,
win64 and mac-arm64 reported as needing
release-all.yml (they predate the checksums, which is
noted in the script)
only the 6 extra extra=[all six], appimage=[], flatpak=[], nothing
arches missing manual - the case this exists for
complete release everything empty, nothing built
Thanks to xet7 !
Opening a report BY ITS ADDRESS - /admin/problems/files typed, bookmarked or
refreshed - drew the column headers, "No results" and a "1 / 1" pager over
data that was plainly there. Reached by clicking the menu entry it worked,
so this only ever happened to the URL.
A full page load resumes the login from localStorage ASYNCHRONOUSLY, and the
route sets `problemsOpenPane` before that lands. The subscription was
therefore made with no user; the publication's isAdmin check answered
`this.ready()` with no rows; and nothing re-subscribed, because the autorun
that opens the pane did not depend on the user. The count METHOD, called
later from the same page, happily reported five - which is what made this
look like a publication bug rather than a timing one.
The autorun depends on Meteor.userId() now. openReportPane() returns early
when the pane is already open, so re-running it after the login would do
nothing at all - hence the second branch, which re-subscribes the report
that is already open now that there is a user to subscribe as.
Found by the e2e test's own diagnosis, added in the previous run for exactly
this purpose: "attachments in minimongo: 0; report_pages index: no
report-files index doc" - neither half arrived, which of the three
possibilities it lists is the one meaning the publication returned early or
never ran.
ALSO, a release-build bug of my own from earlier today:
build-extra-arches had no actions/checkout. It calls
releases/check-arch-binaries.sh and releases/record-provenance.sh and mounts
$(pwd)/releases into the container - none of which exist without one, so
every one of the six extra architectures would have stopped at "No such file
or directory". The checkout goes before the artifact download, because
actions/checkout cleans the workspace and would remove the bundle.
And releases/repack-bundle-for-arch.sh: the amd64 bundle turned into one
architecture's zip, lifted out of that job so it is one script rather than
one job's inline steps. Only build-amd64 runs Meteor; arm64, win64,
mac-arm64 and the six extra architectures are all this same bundle with its
native modules rebuilt, its Node.js swapped and its database binaries
replaced. That is what lets a release be completed one architecture at a
time without rebuilding the rest, and it had better be the same script or a
bundle added later would differ from the ones beside it.
Thanks to xet7 !
On a phone the left menu was drawn 260px wide inside a 157.5px grid track
and lay OVER the board icons. The grid itself was right: 42% of a 375px
phone is 157.5, plus the 8px gap puts the board column at x=165.5, which is
exactly where the boards start. The menu simply did not fit in its track.
260px is --wekan-left-menu-width, the DESKTOP width the drag-grip sets -
leftMenu.js does not even offer the grip below 800px. The menu carried it on
a phone anyway, because the phone rules never said otherwise and the
`max-width: 100%` on the base rule does not do what its comment claimed. A
percentage width on a grid item does not resolve against the track, so it
capped nothing. That is not a browser quirk: Chromium, Firefox and WebKit
all drew the same 260px.
`width: auto` in the phone rules instead. A grid item with an auto width
stretches to its grid area (justify-self defaults to stretch), so it fills
the track exactly with no percentage to resolve. The base rule keeps its
max-width, which is still right where this menu is not a grid item, and its
comment now says what it does rather than what it was hoped to do.
Measured, not guessed: decoding the failing test's screenshot pixel by pixel
shows the menu background #f7f7f7 running from x=3 to x=255 with the blue
board tiles painted on top of it from x=170, and the page background #dedede
only from x=260.
Also: when the Files report draws its headers and then "No results", the
test now says which half is missing. A row needs the page rows AND the
report_pages index that names them; the server count it already checks
proves only that the query matches. Rows but no index, index but no rows,
and neither are three different bugs that all show up as "element(s) not
found". That report is still failing - the server counts 5 and the pane
renders none, with every static link between them verified correct - so the
next run should name the layer instead of another read-through.
Thanks to xet7 !
Seven of the DnsBleed mocha tests failed with "Timeout of 2000ms exceeded" -
every one of the ALLOW cases, while every block case passed, which is what
hid it.
The stub was at fault, not fetchSafe. It faked http.IncomingMessage with a
bare EventEmitter that emitted 'data' and 'end' from a process.nextTick,
into the void if nothing was listening yet. No real response does that: an
IncomingMessage is a PAUSED Readable that buffers its body until a listener
attaches or it is resumed, so reading late cannot lose data.
That only started to matter when fetchSafe was split into resolving the
response and then reading it, which the redirect handling needs - it has to
see the status before deciding whether to read a body at all. The nextTick
queue drains BEFORE promise microtasks, so the fake had already fired 'end'
by the time the awaited continuation attached its listeners.
Verified rather than assumed, both halves:
- against a real server: a request whose 'data' listener is attached two
nextTicks, a setImmediate and 20ms after the response callback still
receives the whole body.
- against the real fetchSafe, driven by each stub in turn: the old
EventEmitter stub times out after 2s; the Readable-backed one returns
status=200, the body, the pinned IP 93.184.216.34 and Host
example.com.
The security assertions still hold through the new stub, checked the same
way: a 302 with the default maxRedirects:0 is refused, a host resolving to
127.0.0.1 is refused with ZERO requests sent, a followed redirect pins each
hop to its own resolved IP, the abandoned hop reports destroyed=true, and
Authorization and Cookie are dropped on the cross-origin hop.
destroy()/destroyed are now the stream's own rather than a hand-rolled flag,
so "fetchSafe abandoned this body" is asserted against real stream
behaviour.
Thanks to xet7 !
wekan/gitea, forked from go-gitea/gitea, is cloned to gitea/ here: a whole
Go + web application, 1,401 directories, 6,209 files, 384 MB. Nothing in
WeKan imports it.
Left out of .meteorignore it would have gone straight back into the build
scan - about a fifth again of everything Meteor legitimately walks in this
repository, and that scan is what ran the build out of memory. Left out of
.gitignore it would fill git status.
The guard added for exactly this caught it: with the entry missing from
.meteorignore, `every git repository cloned in here is excluded from BOTH
files` fails with
cloned repositories Meteor would still walk - add them to .meteorignore
actual: [ 'gitea' ]
It is named in the explicit list as well as found by the walk, because the
walk can only check a clone that is present - a checkout without gitea/ must
still not lose the entry.
Thanks to xet7 !
Excluding /_build/ and /_build-local-test/ in .meteorignore was wrong and
broke the build, with an error that does not mention .meteorignore at all:
error: Could not find mainModule for 'os' architecture:
_build/main-prod/server-meteor.js
Check the "meteor" section of your package.json file?
They look exactly like build output that should be ignored - they are
gitignored, and they are the first two entries of the 296 KB pattern list
that the heap snapshot turned up. They are not leftovers. rspack compiles
the app INTO _build/main-prod/ (and _build/test/ for a test run), and Meteor
then reads server-meteor.js and client-meteor.js from there as the
application's main modules: package.json names client/main.js and
server/main.js, and the rspack integration repoints mainModule at its own
output. Ignoring them hides the files Meteor is about to be handed.
They are 3 directories each, so there was nothing to win by excluding them
and a build to lose. The rest of the excludes - the Node.js fork checkout,
mongo-tools, TSC, the TSC website and the two variant WeKan checkouts - are
where the 5,860 directories were, and they stay.
The guard now asserts the OPPOSITE for these two, so the mistake cannot be
made again by anyone reading .gitignore and concluding the obvious thing.
The general "gitignored at the top level must be in .meteorignore" rule
gains them as documented exceptions: .gitignore happens to write them
unanchored today, so that rule skipped them by luck rather than by design,
and normalising .gitignore would have turned the guard itself into the thing
that breaks the build.
Thanks to xet7 !
The guard added with the .meteorignore fix derived its list FROM .gitignore,
so it only caught a clone that had got half way: one added to NEITHER file
was invisible to it. That is the state every one of these arrived in, so it
is the state worth failing on.
The check walks the tree looking for a directory with a .git of its own -
existsSync, because a submodule's .git is a file, not a directory - rather
than comparing against a list, so a clone nobody thought to name is caught
too. Anything it finds must be ignored by git (asked of `git check-ignore`,
not of a hand-parsed .gitignore) and, when it is a top-level directory,
listed in .meteorignore. It does not descend into a repository it has
already found: that repository's own submodules ride along with it.
A directory with a .git of its own is another project. It is not WeKan's
source and it is not WeKan's history, so it belongs in .gitignore to keep
`git status` readable and in .meteorignore to keep the build from walking
it.
Verified by planting a directory with a .git in it: the guard fails and
names it.
Thanks to xet7 !
`meteor build` ran out of JavaScript heap, and raising --max-old-space-size
never helped because the ceiling was not the variable.
A heap snapshot taken as the build died says what it was: of a 4.1 GB heap,
980 MB was 14,267,543 IgnoreRule objects, 667 MB sliced strings, 308 MB
concatenated strings and 274 MB in 945 copies of one 296 KB pattern list -
about 2.5 GB of ignore machinery, and only 945 directories in.
Meteor builds one ignore matcher per directory it descends into, each
carrying the whole accumulated pattern list. There were 6,867 directories
under the app; roughly 1,000 of them were WeKan. The rest were repositories
cloned in beside it - the Node.js fork checkout (4,132 directories, 45,527
files, 2.3 GB), mongo-tools, TSC, the TSC website, two more WeKan checkouts
- plus Meteor's own _build/ and _build-local-test/ output, which it was
scanning as source to produce. All of them were in .gitignore, which Meteor
does not read; it reads .meteorignore, which listed only .tools/, FerretDB/
and tests/. So the cost was very nearly seven times what the snapshot
caught.
The two variant checkouts were the worst of them: wekan-ondra and
wekan-gantt-gpl contain client/, server/ and models/, and Meteor loads
server/ and client/ eagerly - a second and third copy of the whole app
pulled into the build.
Excluding all of it takes the scan back to WeKan itself.
Also: build.sh exited 0 while printing "ERROR: the WeKan build failed".
build_wekan returns 1, the menu called it bare and threw that away, so
anything driving it non-interactively saw a green run and a missing bundle.
tests/meteorignoreScanScope.test.cjs pins the excludes, that they are
anchored to the repo root rather than matching a directory of that name at
any depth, and - for the next clone dropped in here - fails on any new
top-level directory that .gitignore excludes while .meteorignore does not,
which is exactly how each of these arrived.
Thanks to xet7 !
The capped snapshot worked - 6 GB written at a 4096 MB heap - and
releases/analyse-heapsnapshot.py (added here) says what is in it. Of 4,120 MB:
980 MB 14,267,543 x object IgnoreRule
667 MB 21,869,662 x sliced string
308 MB 10,105,340 x concatenated string
274 MB 945 x string "_build/test/** _build/main-dev/** node_modules/** .babelrc ..."
237 MB millions x string "t(?=$|\/$)", "s(?=$|\/$)", "e(?=$|\/$)" ...
Around 2.5 GB of the 4.1 GB heap is one thing: ignore-rule machinery. The
regexes are the `ignore` npm package's own rule compilation, IgnoreRule is its
rule class, and the 274 MB string is the pattern list it is compiling.
The arithmetic says what is happening. 274 MB across 945 copies is 296 KB per
copy - a pattern list of about 15,000 entries - and 14,267,543 rules across 945
constructions is 15,097 rules each. So a ~15,000-pattern ignore list is being
compiled from scratch 945 times, and the sliced and concatenated strings are the
paths it is built from. The repo has 3,030 tracked files and 104 top-level
entries, so 15,000 patterns is not "one per file": the list is accumulating
across those rebuilds.
That is the memory. It is not the minifier, not the heap ceiling, and not
anything in WeKan's own code - it is build tooling recompiling a growing ignore
list once per unit of work.
WHAT I COULD NOT DETERMINE HERE: which component does it. `ignore` is not a
WeKan dependency except through eslint, which does not run during a build, and
~/.meteor is not visible from this sandbox - so the caller is inside meteor-tool
or @meteorjs/rspack and needs a look from a shell that can read it:
grep -rl IgnoreRule ~/.meteor/packages/meteor-tool/*/mt-os.linux.*/dev_bundle/lib/node_modules/
releases/analyse-heapsnapshot.py is kept rather than left in /tmp, because this
will be wanted again. It streams, so it answers on a machine that cannot open
the file in DevTools, and it explains in its header why it reports self size
rather than retained size.
Two bugs in my own reporting, found by reading the output it produced:
* the failure said "allowed 15542 MB and reached 4280.0 MB" - it quoted the
COMPUTED limit while the snapshot mode had capped the build at 4096. It
quotes what the build was actually given now.
* it told you to run WEKAN_BUILD_HEAP_SNAPSHOT=1 even when that is what you
had just run. When a snapshot was requested it now points at the file and
the command that reads it.
Heap.*.heapsnapshot is gitignored: Node writes it into the repo root because
that is the build's working directory, and it is as large as the heap.
300 node suites pass, 0 failed.
The first heap-snapshot run was killed by the kernel - "Päätetty" - and left a
0-byte Heap.20260803.220733.2327163.0.001.heapsnapshot behind. The build log
ends mid-rspack with no GC dump at all, because the process never got to fail
its own way.
Writing a snapshot costs memory ON TOP of the heap being dumped. Asking a
15.5 GB heap to write a 15.5 GB snapshot, on a 30 GB machine with 12 GB already
in use, does not fit - the OOM killer arrives before the file does. So the flag
as written could not do the one thing it existed for.
WEKAN_BUILD_HEAP_SNAPSHOT=1 now caps the heap at 4096 MB rather than using the
computed limit. The build fails sooner, which is the point: a snapshot is not
more useful for being bigger. What is wanted is WHAT is retaining memory, and
whatever grows to 15 GB is already the largest thing on the heap at 4 GB - it
just gets there sooner and writes a file that fits in RAM and on disk.
WEKAN_BUILD_HEAP_SNAPSHOT_MB overrides it if 4096 turns out to be too early to
be representative.
The message says all of this, including that the build WILL fail and that a
full-size snapshot was already tried and killed, so nobody repeats it.
300 node suites pass, 0 failed.
The fourth run died the same way - 15526.3 MB of 15542 - and produced no more
information than the third, because the heap snapshot is opt-in and nothing told
anyone it existed. The flag was added in the last commit and the failure path
was not updated to mention it, which makes it a flag nobody will use.
The error now names the exact command:
WEKAN_BUILD_HEAP_SNAPSHOT=1 ./build.sh
and says what it produces, where, and how to read it.
It also says plainly what NOT to try, because the obvious move is wrong and has
now been wrong twice: the limit has already been raised once, 8192 to 15542, and
the build used the extra; removing the second JS minifier moved the peak by 6 MB.
Both of those are cheap to try again and neither will work, so the message says
so rather than leaving the next person to repeat them.
And the diagnosis is appended to the build log, not only printed. The point of
that log is that "check the newest test logs" answers the question - a diagnosis
that lives only in terminal scrollback is one the next reader does not have, and
the last four runs are exactly the case: the log ends on a V8 stack trace and
the explanation was somewhere above it on a terminal since closed.
Verified by rendering the message against the real log of the run that prompted
it: it reads back 15526.3 MB of 15542.
300 node suites pass, 0 failed.
The theory was that rspack minifies for production itself and standard-minifier-js
was running Meteor's minifier over that same output a second time, in exactly
the phase where `meteor build` runs out of memory. The run settles it:
with the minifier peak 15526.6 MB died after both rspack compiles
without it peak 15520.4 MB died after both rspack compiles
Six megabytes apart, which is noise, and it died in the same place. The minifier
was not the consumer, so it goes back. An unverified change to the release
artifact that demonstrably fixes nothing does not belong in the tree - and
because the build never completes, there was no way to confirm the resulting
bundle was still correctly minified either. Both .meteor/packages and
.meteor/versions are restored exactly as they were, byte for byte.
Three guesses is enough. build.sh takes WEKAN_BUILD_HEAP_SNAPSHOT=1 now, which
adds Node's --heapsnapshot-near-heap-limit=1 to the build so it writes a heap
snapshot just before it would die, rather than only dying. Off by default,
because the snapshot is about as large as the heap limit; when it is on the
build prints where the file lands and how to read it - Chrome DevTools, Memory,
Load, sorted by retained size.
That turns the next run into evidence instead of a fourth theory. Whatever is
retaining 15 GB in Meteor's bundle-writing phase will be at the top of that
list.
300 node suites pass, 0 failed.
Two builds died in the same place - after both rspack compiles report done, in
the phase where Meteor writes the production bundle - the second with twice the
heap of the first:
=> Compiled Rspack client app: done
=> Compiled Rspack server app: done
<--- Last few GCs ---> 8146 MB of 8192, then 15526 MB of 15542
So it was not a ceiling set too low. rspack is the bundler here and it minifies
for production itself - the asset-size warnings a build prints are about
rspack's own minified output, 4.797 MiB of client-rspack.js and its chunks.
standard-minifier-js then ran Meteor's minifier plugin over that same output a
second time, in exactly the phase that runs out of memory.
.meteor/packages says so in a comment rather than leaving the removal to look
like an accident, including what to check first if this turns out to be wrong: a
bundle that is broken rather than merely unminified twice means put it back.
The stale pin is dropped from .meteor/versions so the two files agree;
minifier-js stays, because it is a library other packages depend on rather than
the plugin that was running.
Four guards failed on this and on the last few commits, and all four were
pinning something that deliberately changed. Each keeps its assertion and gains
the reason:
changelogFormat - three Upcoming summaries of mine had no commit link,
which every summary in a release must have, and the
section was not grouped by area. That one was a real
defect in the CHANGELOG, not in the guard: the entries
are linked and grouped now, under "The extra-
architecture bundles", "Which Node.js a bundle carries"
and "Running the tests locally".
buildScriptParity - looked for `rm -rf .build` in the first 400 characters
of build_wekan. That window was an accident of how long
the comment above it happened to be, and it broke when
build_wekan gained an explanation of where its log
goes. It searches the whole function. It also needed
the five release-workflow helpers exempted from "every
script is a menu entry": they are called by a build job
with its matrix and environment, and would have nothing
to do on a developer's machine.
cpuExecWiring - looked for the qemu handling inline in release-all.yml.
It moved into releases/install-node-for-arch.sh, which
is the fix for the apostrophe-in-a-single-quoted-string
bug, so the guard looks there and also pins that the
workflow runs the file.
dbConformanceWiring - pinned ../log literally in three places. The root is
WEKAN_LOG_ROOT now, because ../log is not writable in a
Flatpak sandbox; what is pinned is that the same
question is asked and that WEKAN_LOGDIR still wins.
300 node suites pass, 0 failed.
NOT verified: the build itself - Meteor is not installable in this sandbox, so
whether dropping the minifier gets past the OOM is the next run's answer, and
whether the resulting bundle is correct is the thing to look at if it does.
The build failed again, and the log now says why on its own - but its last word
was a V8 stack trace, which reads as a crash rather than as the resource limit
it is. Running out of heap and failing to compile look identical at the level
build_wekan reports at, and they have nothing in common.
When the build log contains "JavaScript heap out of memory", the error now says
so, with the limit the build was given and the peak it actually reached, pulled
out of the last Mark-Compact line:
The build ran out of JavaScript heap. It was allowed 15542 MB and reached
15526.6 MB.
and points at the last line before the GC dump, which is the stage it got to.
It also says what NOT to do. Raising the number again is the obvious move and is
wrong once the figure is already large: this build used 15.5 GB, and the run
before it died the same way with half as much, so the ceiling is not what is
short. That belongs in the message rather than in somebody's memory.
Verified against the real log of the run that prompted it: the extraction finds
15526.6 MB from the final Mark-Compact line, and the sentence renders.
The build log added last commit earned its keep on the first run: the WeKan
stage failed again, and this time ../log/<datetime>/wekan-build.log says why,
on its last lines.
FATAL ERROR: Ineffective mark-compacts near heap limit
Allocation failed - JavaScript heap out of memory
at 8146 MB of an 8192 MB limit, on a machine with 30 GiB of RAM. The build had
not run out of memory. It had run out of the ceiling this script gave it -
--max-old-space-size=8192, hard-coded at the top with a comment saying to lower
it if your machine has less RAM, which is only half the problem: a constant is
simultaneously too small on a large machine and too large on a small one, and
nobody edits it until a build dies.
It is half of total RAM now, clamped to [4096, 16384]:
8 GiB -> 4096 (the floor - a small machine is not handed something unusable)
16 GiB -> 8192 (exactly the old constant, so nothing changes there)
30 GiB -> 15542 (this machine, nearly double what just failed)
64 GiB -> 16384 (the ceiling - past this, a heap that big means something is
wrong rather than something is big)
Half is the share that leaves the rest of the machine usable while a build runs.
Total RAM comes from /proc/meminfo, or hw.memsize on macOS, and falls back to
assuming 16 GiB if neither answers. The chosen size is printed at startup so the
log says what the build was given, and exporting TOOL_NODE_FLAGS or NODE_OPTIONS
yourself still wins.
Computed unconditionally rather than only when neither variable is set, which
was the first version of this and was wrong: with only ONE of them exported, the
other would have been handed a bare "--max-old-space-size=".
The dev server on :3000 had the same 8192 written into its command line and now
uses the same figure, so the two cannot drift.
Verified by running the block with /proc/meminfo stubbed at 8, 16, 30 and 64
GiB, giving the four values above; and with TOOL_NODE_FLAGS exported alone, which
keeps the exported value and still gives NODE_OPTIONS a real one.
Every log build.sh writes goes into a log/<datetime>/ directory, and the root of
those was hard-coded to ../log - one level up from the repo. That is the right
default and stays the default: a test run then does not appear in git status,
and the docs and the release process read it there.
But the parent of the repo is not always there to write into. A Flatpak sandbox
shares only the repository directory, so `..` is missing or read-only and
`mkdir -p ../log` fails - after which every redirection in the script either
failed outright or quietly dropped its log into the repo root. That is the worst
of both: the run looks like it logged something, and git status fills up with
stray files that are not part of the tree.
WEKAN_LOG_ROOT is resolved once at startup and used everywhere the path was
built by hand: ../log when the parent is writable, ./log inside the repo when it
is not, and whatever you set if you set it. The shape is log/<datetime>/ either
way, so nothing that reads these logs has to know which happened, and the chosen
path is printed when a run starts - including a line saying why, when it is the
fallback.
Everywhere means everywhere: the whole-run directory, one_log for the individual
test options, the Playwright per-browser runs, the EVERYTHING orchestrator, and
the wekan-log.log the whole session is teed into. releases/db-conformance.sh
makes the same choice when it is run on its own rather than under build.sh, and
the thirteen menu entries that told the reader "logs in ../log/<datetime>/" now
say "log/<datetime>/" - those strings are also the case labels the menu
dispatches on, so both copies had to move together.
/log/ is gitignored, for the case it lands inside the repo.
Verified both branches by running the resolver in a temporary tree: with a
writable parent it chooses ../log and creates it; with the parent chmod'ed
read-only it prints the note, chooses ./log inside the repo, creates that, and
does NOT create ../log. build.sh, db-conformance.sh and run-everything.sh all
pass bash -n.
The newest test run ended
FAIL WeKan tests (sequential)
PASS Database conformance (all databases for this CPU)
PASS FerretDB tests (unit, vet, integration)
and ../log/2026-08-03_19-32-26/ held twelve conformance and FerretDB logs and
NOTHING about WeKan. Not one line about why WeKan never got as far as running a
test. The build writes to the terminal only, so the one question that run raised
was the one question its logs could not answer - and "check the newest test
logs" is how these runs are meant to be read.
What can be said from the tree it left: node_modules is 654 MB, so
`meteor npm install` finished; .meteor/local is 43 MB where a completed build is
gigabytes, and .build does not exist at all, so `meteor build .build --directory`
started and died partway. Why, nothing recorded. Meteor is not installable in
the sandbox this is being fixed from, so it cannot be reproduced here either.
build_wekan tees into wekan-build.log in the run's own log directory now, and
prints the path before it starts. An interactive build still scrolls past
exactly as it did.
Two more things found while in there.
build_wekan did not check whether the build worked. `meteor build` failing left
the function returning success, and the caller learned about it only afterwards
by noticing .build/bundle was missing - which is how this failure was reported,
one level away from the thing that failed. It checks the exit status and the
bundle, and says which log to read.
run_all_tests minted its own ../log/<datetime>/ even when a larger run had
already set WEKAN_LOGDIR. That is exactly the split-across-two-directories the
per-run directory exists to prevent; it landed in the same second as the outer
one this time, so nothing showed, and on a slower machine half a run's logs
would have gone somewhere else. It uses the outer directory when there is one
and exports its own when there is not, so every job of a run agrees on it
instead of each calling date() again.
Verified: build.sh passes bash -n, and the tee construct was exercised on its
own - a failing command inside the group produces exit 1 from the function, the
ERROR path, and a complete log file, rather than tee's own zero.
Two things a WeKan release did not say, and now does.
WHAT IT SHIPS. Each bundle zip now has a wekan-<version>-<arch>.zip.sha256sum
beside it on the release, so a download can be checked. The bundles were the one
thing in this chain with no checksum at all - the binaries inside them are
verified where their sources publish one, and the zip carrying them was not.
WHERE ITS BINARIES CAME FROM. A bundle is assembled out of a Node.js, a
FerretDB and the MongoDB tools, and WHICH source serves each varies per release
and per CPU: nodejs.org builds some architectures, unofficial-builds others, the
wekan/node fork the ones neither of them does, and not all of them publish a
checksum. None of that was visible anywhere except a build log that expires, so
"where did the node in the arm64 bundle come from, and was it checked" had no
answer.
Each build job records a row per binary - bundle, binary, source, version,
whether it was checked, the SHA256 - and the release notes open with the table.
A row saying "no checksum published" is not a failed check but a source that
publishes nothing to check against, and the table says so, because those are the
ones worth fixing at the source rather than mistaking for failures.
The table is written twice, and that is deliberate. The release is CREATED
before win64, mac-arm64 and the extra architectures are built - those jobs need
a release to upload their bundles to - so the table it is created with can only
cover amd64 and arm64. A new release-notes job runs after all of them and
rewrites the notes with every bundle in. It is always(), so a platform that
failed does not cost the release the table for the platforms that succeeded.
FerretDB is now verified too, where it can be: wekan/FerretDB publishes a
.sha256sum beside each binary as of the commit in that repository alongside
this one, and the extra-arches job checks the download against it. An older
release without one is recorded as unverified rather than failing the build -
the binary IS available, which is the test that matters.
Nothing new fails a build. A missing checksum is a warning, a missing MongoDB
tool is a warning; only a binary that does not exist at all stops the run, which
is what it did before.
Verified: every script parses under bash -n; release-all.yml is valid YAML with
its nineteen jobs and the new one wired to all five build jobs; and the table
renders correctly from real rows - three of them, two sources, one with a
checksum and one without - producing the markdown checked by eye.
Replaces the fork-first entry, which this supersedes: the order is official,
then unofficial, then the fork, by how verifiable each build is - and the
checksum is now actually checked, with a retry before it is fatal.
Thanks to xet7 !
The three sources do not offer the same assurances, and this was checked rather
than assumed:
nodejs.org SHASUMS256.txt, and SHASUMS256.txt.sig / .asc signed with
the Node.js release keys
unofficial-builds SHASUMS256.txt, no signature
wekan/node fork neither, until the commit in that repo alongside this one
So the order goes back to official, then unofficial, then the fork - descending
verifiability, with the fork as the backstop for what the other two do not
build. A binary somebody else signed is worth more than one this project built,
and the fork's own fixes are build-configuration fixes upstream's builds do not
need: they are what makes the CPUs upstream does NOT build compile at all.
Preferring a source because it publishes a checksum and then not checking it
would be preferring it for nothing, so the checksum is now looked up in the
preflight - from the source's own SHASUMS256.txt, or from the fork's per-binary
.sha256sum - and the download step refuses a file that does not match it.
A mismatch is retried before it is fatal. The overwhelmingly likely cause is a
truncated or corrupted transfer, a CDN edge that served a partial file or a
connection cut mid-stream, and that is fixed by asking again. What retrying must
not do is give up quietly: after three attempts the build stops, because at that
point the file being served is not the file that was published.
Where no checksum exists the log says so in as many words, rather than leaving
the reader to assume a check was made. FerretDB and the MongoDB tools are in
that position today - neither wekan/FerretDB nor wekan/mongo-tools publishes
checksums for its release binaries, which is the next gap to close.
Verified by exercising download_and_verify directly: a matching checksum
returns 0, a missing one returns 0 with the file named as unverified, and a
mismatching one retries three times and exits 1. And by resolving the real
checksums for every architecture against the live releases - s390x and ppc64le
from nodejs.org, riscv64 and loong64 from unofficial-builds - then downloading
the riscv64 tarball and confirming its hash matches the published one.
The fork is not "the CPUs nobody else builds" any more - it builds all thirteen
platforms WeKan ships a bundle for, and it carries fixes upstream does not: the
ICU genccode architecture name, the x86 /SAFESEH opt-out, the zlib SSE2 and NEON
flags, the V8 template disambiguator. Those are build-configuration fixes that
any platform benefits from, and a set of bundles should not be half built on one
Node.js and half on another depending on which CPU it is for.
So the probe order is fork, then nodejs.org, then unofficial-builds - the last
two now being fallbacks for the case the fork has not published a version yet,
rather than the other way round.
The rest of the rule is unchanged and still matters: the newest Node.js that
exists FOR THIS CPU, walking versions from newest down and asking all three
sources at each one. Preferring the fork does not mean pinning to whatever the
fork last built.
Checked against the live releases, which show the transition in progress - the
fork has v24.18.1 for the architectures it already built and has not yet run for
v24.19.0:
i386 v24.18.1 fork
loong64 v24.18.1 fork was coming from unofficial-builds before this
s390x v24.19.0 official fork has not built v24.19.0 yet
ppc64le v24.19.0 official likewise
riscv64 v24.18.1 unofficial likewise
armhf - none still nothing anywhere
Once node.yml has run for v24.19.0 with its new matrix, every one of these
resolves to the fork; until then the fallback chain keeps the bundles building
instead of blocking on it.
Splits the version-fallback out of the binary-check entry, because it is its own
change and its own reason: the fallback now applies to all three sources rather
than only the fork, which is what makes riscv64 build again.
Thanks to xet7 !
The version fallback added with the preflight check was only wired to the
wekan/node fork. nodejs.org and unofficial-builds were still pinned to the exact
newest release, so a CPU that HAD a perfectly good build, one patch version
back, was reported as having none at all.
riscv64 was exactly that. unofficial-builds publishes riscv64 up to v24.18.1 and
has not got to v24.19.0; the check looked only at v24.19.0, found 404s, and
stopped the job saying "no Node.js for riscv64 exists anywhere" - while
node-v24.18.1-linux-riscv64.tar.xz was sitting there.
The rule is now "the newest Node.js that exists for this CPU". It walks the 24.x
releases from newest down and asks all three sources at each one - official,
then unofficial, then the fork - and the first hit wins, which is by
construction the newest build that exists anywhere for that architecture. Those
are the same thing on amd64 and arm64 and regularly are not anywhere else:
nodejs.org builds a handful of architectures, unofficial-builds adds a few, the
fork builds the rest, each on its own schedule, so the further a CPU is off the
beaten path the further behind its newest build tends to be.
When the answer is behind the newest, the log says which version it got, from
where, which version it wanted, and what to build to bring it in line. It is a
warning, not an error: the alternative is no bundle at all for that CPU.
The walk stops after 12 releases. A CPU whose newest build is a dozen releases
old is not slightly behind, it is unmaintained, and saying so is more use than
quietly shipping something from last year.
Re-ran the check against the live releases for all six architectures:
s390x v24.19.0 official newest
ppc64le v24.19.0 official newest
riscv64 v24.18.1 unofficial was failing before this change
i386 v24.18.1 fork
loong64 v24.18.1 unofficial the fork has it too; unofficial is tried first
armhf - none exit 1, naming node-armhf
and checked armhf by hand across six releases back to v24.10.0 at all three
sources, to be sure "nothing anywhere" is the truth about armhf and not a bug in
the walk. It is: every one is a 404.
Four of the six now come out newer or working where they did not before, and the
one that still fails fails for a real reason.
The six extra-architecture jobs that all failed in the v10.57 run, grouped under
the area they belong to: the shell quoting bug that emptied the CPU name out of
the Node.js URL, the base image that is not built for i386 or loong64, and the
checks that now run before any of it and name the missing file.
Thanks to xet7 !
Every one of the six extra-architecture jobs failed in the v10.57 run, and none
of the six failures was about WeKan.
FOUR OF THEM - ppc64le, riscv64, s390x, armhf - died on the same 404, at a URL
with no architecture in it at all:
curl: (22) The requested URL returned error: 404
No Node.js for at official (https://nodejs.org/dist/v24.18.1/node-v24.18.1-linux-.tar.xz)
The container script was passed as `bash -c '...'` and contained apostrophes, in
comments like "# Where this CPU\'s Node.js comes from". A single-quoted shell
string cannot hold an apostrophe - \' does not escape it, it ENDS the string -
so the script was chopped into words at the first one, and ${NODE_ARCH} landed
in a region the RUNNER's shell expanded rather than the container's. The runner
has no NODE_ARCH, so it expanded to nothing. Reproduced here before changing
anything: that construct really does deliver only the fragment up to the
apostrophe and leave the rest as separate arguments.
The script is a file now, releases/install-node-for-arch.sh, mounted into the
container. A file has no quoting layer to get wrong, and `bash -n` can check it.
THE OTHER TWO - i386 and loong64 - died earlier still, on
docker: no matching manifest for linux/386 in the manifest list entries
ubuntu:26.04 publishes amd64, arm/v7, arm64, ppc64le, riscv64 and s390x. Not
386. Not loong64. The base image is named per architecture in the matrix now and
is debian:trixie, which publishes 386 as well - checked against the registry
rather than assumed.
loong64 still cannot be built, and that is now said rather than discovered: no
image on Docker Hub publishes linux/loong64 at any tag, so there is no loong64
userland to rebuild the native modules in. node-loong64 and ferretdb-loong64
both exist; the container does not. It stays in the matrix so it stays visible.
AND UNDERNEATH BOTH: nothing checked that the binaries these bundles are
assembled from had been published at all. A bundle takes FerretDB from
wekan/FerretDB, the MongoDB tools from wekan/mongo-tools, and on the CPUs nobody
else builds for, Node.js from wekan/node - and any of those can be absent
because a build has not finished. releases/check-arch-binaries.sh now runs
before anything is built and checks the base image, the Node.js, FerretDB and
the tools; releases/require-binaries.sh does the same for the amd64, arm64,
win64 and mac-arm64 bundles. Each missing file gets a line naming it and the
repository that should publish it, and the job stops there. The MongoDB tools
stay a warning: FerretDB is the database and the launcher does not need them.
It also handles wekan/node running behind. The fork builds the architectures
nobody else does, one release at a time, so the newest Node.js is regularly a
version it has not reached - today nodejs.org is at v24.19.0 and the fork at
v24.18.1. Asking for the exact newest version would fail for exactly the CPUs
the fork exists to serve, so the check falls back to the fork's newest release
that HAS that CPU and says out loud that the bundle is a patch version behind.
Verified by running the check against the real releases, for all six:
s390x Node.js v24.19.0, official exit 0
ppc64le Node.js v24.19.0, official exit 0
i386 Node.js v24.18.1, wekan/node exit 0
loong64 Node.js v24.18.1, wekan/node exit 0
armhf nothing anywhere exit 1, naming node-armhf
riscv64 nothing anywhere exit 1, naming node-riscv64
armhf and riscv64 are the two the fork has not finished; the log now says which
file to publish instead of a bare 404. i386 and loong64 resolve because
node-i386 and node-loong64 were added to the fork's v24.18.1 release.
NOT verified: the builds themselves, which need the runners. What was checked:
that release-all.yml is still valid YAML and every job has its check step; that
the three new scripts pass `bash -n`; that the quoting bug reproduces and the
file form does not; that debian:trixie really publishes linux/386 and
ubuntu:26.04 really does not, from the Docker registry; and the six preflight
results above, run against the live releases.
Two more ways to install WeKan, and neither of them rebuilds it.
release-all.yml already produces a bundle that runs offline with nothing
installed: the Meteor server, the bundled Node.js the release was built
against, the wekan/FerretDB v1 fork with its embedded pure-Go SQLite backend,
the wekan/mongo-tools binaries, the cpu-exec/qemu-user shim from #6458 and
start-wekan.sh to bring them up. That bundle is already relocatable and already
self-contained - it is the offline zip people download today. So both workflows
take wekan-<version>-<arch>.zip off the release and wrap it, which means the
AppImage and the Flatpak are byte-for-byte the same server, Node and FerretDB
as the zip beside them, rather than second and third builds that could drift
from it and from each other.
For the person installing, both mean the same thing: one file, no MongoDB to
install, no Node to install, no database server to run. FerretDB v1 keeps
everything in SQLite files.
AppImage.yml wraps the bundle in an AppDir with WeKan's own icon and an AppRun
that hands over to start-wekan.sh, so every variable that launcher documents -
WRITABLE_PATH, PORT, ROOT_URL, MONGO_URL, WEKAN_DB - still works. It defaults
WRITABLE_PATH to ~/.local/share/wekan, because an AppImage is read-only and may
be sitting on a USB stick, so the data cannot live beside it. After packing it
STARTS the AppImage and waits for WeKan to answer on its port before uploading
anything: an AppImage that packs is not an AppImage that runs, and a broken
bundle should be caught here rather than by whoever downloads it.
Flatpak.yml uses `flatpak build` rather than flatpak-builder, because the
bundle is the build and there is nothing to compile. Its sandbox gets
--share=network and --persist=.wekan and nothing else: WeKan is a server
reached in a browser, so it needs the network and a place for its data, not
X11, audio or the user's files. It produces both a single-file bundle per
architecture and a multi-architecture repository - the bundle is what you
install by hand, the repository is what makes `flatpak update` work - and the
repository is static files, so a website can serve it with no server to run.
The Flatpak repository is unsigned. Signing needs a GPG key, which is a secret
rather than something a workflow can invent, so the README written into the
repository sets out the four steps to sign it when a key exists: make the key,
put the private half in GPG_PRIVATE_KEY, add --gpg-sign to the export and the
update-repo, and publish the public half beside the .flatpakrepo.
Both cover x86_64 and aarch64, which is where the two constraints meet: AppImage
and the freedesktop runtime have those architectures, and WeKan publishes
amd64 and arm64 Linux bundles. Each builds on a runner of its own CPU, because
appimagetool packs for the architecture it runs on. If a bundle for another
architecture appears on a release, adding a matrix line wraps it the same way.
NOT verified: neither workflow has been run - that needs the runners. What was
checked: that both are valid YAML and their matrices resolve; that the icon
they use exists in public/; that the four files they assert on
(bundle/main.js, bundle/node, bundle/ferretdb, bundle/start-wekan.sh) are what
release-all.yml actually puts in the bundle; and that the newest release really
does carry wekan-10.57-amd64.zip and wekan-10.57-arm64.zip under those names.
CLAUDE.md sets the shape of a `<details>` block precisely - `<details>` and
`</details>` each on their own line, the whole `<summary>` on ONE line, a blank
line under it, the body, a blank line, the close - and three blocks were missing
the blank line before `</details>`: the Version block in `# Platforms`, the
`Carried to a future release.` block at the top of `# TODO Later`, and one entry
in v10.55.
They render either way, which is why they survived; the rule is there so every
block looks the same in the file, and a block that does not is the one somebody
copies next.
Also rewrapped the one line in the `# TODO Later` intro that had grown to 152
characters, against the 80 the file is wrapped at. It carries no link, so
nothing stopped it being wrapped.
Thanks to xet7 !
The TSC website (Secretchronicles/secretchronicles.github.io), cloned inside
this repo to be worked on beside the game itself. Like the others it is a whole
git repository of its own, so git would not commit it into this one, but it
showed up as untracked noise in every status.
Thanks to xet7 !
git@github.com:Secretchronicles/TSC, cloned inside this repo to be worked on.
It is a whole git repository of its own, so git would not commit it into this
one, but it showed up as untracked noise in every status.
Listed beside the other local-only working copies - node, FerretDB, sandstorm,
mongo-tools, mongosh and the two wekan variants - with the same one-line note
saying what it is a clone of.
Thanks to xet7 !
Two reported bypasses of the SSRF guard, so the section now leads with the
CRITICAL SECURITY ISSUES header and the documentation reorganisation becomes
"and reorganises the documentation:". Both entries are grouped under "The SSRF
guard - what it checks, and what it was deciding from", because that is the one
thing both reports found from two directions.
The "In short" paragraph is rewritten around them: what each bypass was, in one
clause each, then the documentation work accounted for in the closing sentence.
Also records the Sandstorm bridge guard reading the page at its new path, which
the docs reorganisation left pointing at a directory.
Thanks to RandomGenerator, tonghuaroot and xet7 !
Two separately reported bypasses of the same defence, fixed together because
they are the same mistake in the two halves of it: the guard decided from
something it did not control.
FollowBleed (GHSA-j9p2-jm73-p549, reported by RandomGenerator against v10.53) -
the live Trello import validated the attachment URL with validateAttachmentUrl(),
which is the fix that closed LiveBleed / CVE-2026-30844, and then downloaded it
with the platform fetch(), which FOLLOWS REDIRECTS. So the guard only ever saw
the request, and the target gets to answer:
1. the attacker puts http://<public-host>/attachment.txt on a Trello card
2. validateAttachmentUrl() resolves it, sees a public IP, allows it
3. that host answers 302 Location: http://127.0.0.1:18080/secret
4. fetch() follows, and the loopback body is stored as the imported
attachment, readable back through WeKan
Non-blind SSRF against loopback services, internal admin panels, cloud metadata
and anything else reachable from the container - the exact thing the validation
was added to stop, reached through the response instead of the request.
A guard on the URL alone cannot hold, so fetchSafe() now guards EVERY HOP.
`maxRedirects` (default 0) is how many redirects a caller is willing to follow:
0 keeps the old behaviour of refusing any 3xx outright, which is right for
outgoing webhooks and avatar downloads because a legitimate one never redirects.
A caller that must follow one passes a small number, and each hop goes through
the same protocol allowlist, blocked-range check and DNS pinning as the original
URL before a packet is sent to it. Credentials are dropped on a cross-origin
redirect, so following Trello's 302 to S3 cannot hand the API key and token to
whoever the redirect names.
All three live-import sinks - downloadAttachmentBase64, inlineBoardBackground,
inlineMemberAvatars - download through it. Refusing every redirect was not an
option: Trello's own attachment endpoint answers with a 302 to a signed S3 URL,
so that would have meant importing no attachments at all.
The offline importers had the same hole and were not in the report. They handed
the validated URL to Attachments.loadAsync(), and Meteor-Files downloads with
the platform fetch() too, so a pasted Trello or WeKan board export reached
127.0.0.1 by exactly the same 302. models/lib/importAttachmentDownload.js
validates, downloads through fetchSafe with every hop checked, and hands back
the bytes, which are stored with the writeAsync() both importers already use for
an attachment that arrived inline.
TransitBleed (GHSA-c5xr-mg26-vq5w, reported by tonghuaroot) - isIpBlocked() in
models/lib/attachmentUrlValidation.js is the one block-list behind BOTH the
input-time validator and the delivery-time guard, and its IPv6 half classified
an address by its spelling: startsWith('::ffff:'), startsWith('2001:db8'), and
the first hextet parsed out of the string. IPv6 has several standard ways to
write "this packet goes to an IPv4 address" and none of them looks like
`::ffff:`:
2002:a9fe:a9fe:: 6to4 (RFC 3056) -> 169.254.169.254
64:ff9b::c0a8:101 NAT64 (RFC 6052) -> 192.168.1.1
2001:0:... Teredo (RFC 4380) -> complement of the low 32 bits
0:0:0:0:0:ffff:7f00:1 IPv4-mapped, spelled out -> 127.0.0.1
On a host with a 6to4 relay or a NAT64 gateway, which is ordinary in cloud and
Kubernetes networks, the packet arrives at that IPv4 address. So
http://[2002:a9fe:a9fe::]/latest/meta-data/ read cloud metadata straight through
the guard whose whole job was to stop it, and even a plain IPv4-mapped address
written out in full missed the check.
The address is EXPANDED to its 16 bytes once and every check reads those bytes,
so notation cannot change the answer, and every transition form has its embedded
IPv4 extracted and re-checked with the IPv4 rules - 6to4, NAT64 (well-known and
RFC 8215 local-use prefixes), Teredo through both its server and its obfuscated
client address, IPv4-mapped, IPv4-translated, IPv4-compatible and ISATAP under
any routing prefix, not only the link-local one. The deprecated fec0::/10
site-local range is blocked too. A transition address wrapping a PUBLIC IPv4 is
still allowed, because a guard that blocks everything gets switched off.
Tests. tests/followbleed.test.cjs replays the reported attack against a stubbed
transport - a public host that 302s to 127.0.0.1 - and asserts the second hop is
never sent, then covers redirects to a hostname resolving to a private IP, to
metadata, to a non-http scheme, relative Location, the chain limit, credential
stripping across origins, 303/307 method handling, and that a legitimate
public-to-public redirect is still followed with each hop pinned. It also pins
the sinks: the only bare fetch() left in the live import is the hardcoded
api.trello.com call, and neither offline importer uses loadAsync any more.
tests/transitbleed.test.cjs checks every transition form in both directions.
Both are in the plain-node suite; the guard's own dnsbleed suite gained the same
cases. 300 node suites pass.
Thanks to RandomGenerator and tonghuaroot for the coordinated disclosures, and
xet7 !
The docs reorganisation (f628a698) turned
`docs/Platforms/FOSS/Container/Sandstorm` from a page into a directory, and
this test reads that page at run time to pin what it documents. So it did not
merely go stale - `fs.readFileSync` on a directory throws EISDIR and the suite
died before its assertions ran.
It reads the directory's landing page, `README.md`, which is where the
migration-bridge documentation ended up. Both assertions are unchanged and both
pass.
Thanks to xet7 !
Two entries for the two commits since the last changelog update, and the bug
subsection is grouped by area now that it holds three: the snap, and All Boards.
Grouping meant rewording two summaries - an entry under a group must not repeat
the group's own name, and both began with it.
The In short paragraph follows: it named two of the three fixes and now names
all of them.
The counts entry goes under All Boards with the left-menu one; the remote-build
diagnostics are release tooling rather than a bug in WeKan itself, so they get
their own subsection after the fixes, as CLAUDE.md orders them.
Thanks to xet7 !
Starred, Home, Templates and Archive have labels of four different lengths, and
on a phone the count chip sat immediately after its label - so the four numbers
landed at four different x positions and the column of counts read as ragged
rather than as a column at all.
That packing was deliberate (#6523): the number beside the text rather than
across a gap, on the grounds that a landscape phone's menu is wide enough for
the gap to look like a mistake. Reversed here, because the alignment is what a
reader is actually using - the counts are compared with each other down the
column, and four x positions is what stops that.
The row keeps the space-between and the flex: 1 label the base rule gives it, at
every width, so every count sits at the end of its own row and they line up. The
phone override is gone rather than re-tuned; there is no width at which the
ragged version was wanted.
Guarded both ways in mobileAllBoardsFit.test.cjs: the row must spread its two
children apart and the label must take the slack, AND no narrower width may take
either back - a phone override is exactly how they came to be ragged.
Thanks to xet7 !
The v10.55 riscv64 leg failed three times in sixteen minutes, and the whole of
what it printed was:
Git operation failed with: Could not push 'HEAD' to
git.launchpad.net/.../+git/snapcraft-wekan-<hash>
with refspec 'HEAD:refs/heads/main'
This is a different failure from the other two arches. It is not the staging bug
- that happens minutes into a build, on the builder. Here the build never
started: remote-build uploads the source to a Launchpad git repository first,
and the upload is what failed. ppc64el and s390x pushed fine in their own runs,
with the same credentials.
Why it is still unconfirmed: snapcraft swallows git's own error, writes it to
its execution log, names that log's path in the output, and nobody reads it. So
"rejected", "timeout", "auth" and "too big" all look identical from the job log
- which is why three runs have not narrowed it down.
Two changes, both about being able to tell next time:
The failed-attempt handler prints snapcraft's own execution log, not only the
Launchpad build log. The Launchpad one does not exist when the build never
started, which is exactly this case.
And the retry clears ~/.cache/snapcraft/remote-build before waiting. snapcraft
keeps a local clone of the Launchpad repository there, and a retry that reuses a
half-pushed one repeats the same failure - three identical attempts sixteen
minutes apart is what that looks like.
The leading suspect is recorded in ../log/snap/TODO.txt rather than guessed at
here: remote-build pushes HEAD:refs/heads/main with no force, WeKan's history
was rewritten between v10.54 and v10.55 by the release rebase, and a `main` left
behind by the previous run is then no ancestor of today's HEAD. If the log the
job now prints says "rejected", deleting that scratch repository is the fix, and
the longer-term answer is for the workflow to delete it or to use a fresh one
per run.
Thanks to xet7 !
The three commits since v10.55, each linking the commit it describes: the
platform expansion as a new feature, and the snap that could not finish staging
on any FerretDB-only architecture and the left menu lying over the boards on a
phone as bug fixes.
One style fix with it: the dependency bullets in v10.55 wrote their link text as
[update] where v10.54 and everything before it write [Update].
The hashes were checked rather than assumed - every commit link in the new
section resolves AND is an ancestor of HEAD, which is the property that matters
after a rebase: a hash that still exists locally but has left the branch is a
404 the moment it is pushed. The rest of the file was checked the same way and
needed nothing.
Left alone: hash LENGTH. The two newest releases happen to use 9-character
prefixes, which is what a sample of them says, but the file as a whole is 2811
forty-character hashes against 399 short ones - so the newest entries are the
outliers, not the rule, and normalising the file to match a sample of itself
would have rewritten every release ever published.
Thanks to xet7 !
Every non-amd64, non-arm64 platform already used FerretDB v1 - MongoDB ships no
server for any of them - but only three of them were built, because only three
had a Node.js runtime anyone published. wekan/node now builds the rest, so the
gap is gone and the release follows FerretDB's list.
New bundles: i386, armhf and loong64, beside the ppc64le, s390x and riscv64
already there. They go into the snap (i386 and armhf; loong64 is not a snap
architecture) and into the multi-arch image (linux/386 and linux/arm/v7;
buildx and the three registries do not agree on loong64 yet).
WHERE THE NODE.JS COMES FROM is now resolved at build time rather than declared:
nodejs.org, then unofficial-builds, then the wekan/node fork, in that order, and
the log says which one served. The first two ship a tarball; the fork ships the
bare binary it built, because that is the only part missing - so when the fork
serves, npm comes from the official amd64 tarball of the same version. npm is
JavaScript and runs on whatever node executes it, so an npm built for one CPU
drives a node built for another.
THREE VOCABULARIES meet in this matrix and they disagree: Node says x86 and
armv7l where Debian, snap and FerretDB say i386 and armhf, and snap says ppc64el
where everyone else says ppc64le. Each row now names all three - arch, node_arch
and ferretdb_arch - because a row that named one of them would download another
CPU's binary and nothing would notice until somebody ran it.
The MongoDB Database Tools are per-tool tolerant now: wekan/mongo-tools does not
publish every arch, and a missing mongodump is a missing convenience rather than
a broken bundle - FerretDB is the database. It removes the inherited amd64 one
instead of shipping it, because a tool for the wrong CPU is worse than no tool.
armel is the one FerretDB target left out, and deliberately: V8 has not
supported ARMv5 for many years, so there is no runtime to put in the bundle and
the fork cannot build one either.
A new guard reads the four lists that have to agree - the bundle matrix, the
snap platforms block and its arch mapping, the snap-launchpad matrix and the
Docker platform list - and checks every snap arch has a bundle behind it, every
bundle row names all three vocabularies, and buildx builds exactly the platforms
whose push is then verified. Two older guards pinned the five-platform snap list
and now pin the seven.
Written up in docs/Design/Autoupdate/Platforms.md.
Not verified by a real release run: no workflow here can be executed, and the
first run is what will say whether the loongarch64 cross toolchain is available
on the runner and whether each platform's Node.js resolves where expected.
Thanks to xet7 !
The s390x snap died in the STAGE step of both its Launchpad builds, right after
"Staging mongodb":
/build/snapcraft-wekan-<id>/stage/bin: Is a directory
IsADirectoryError: filename: '/build/.../stage/bin'
The mongodb part's stage-packages unpack an Ubuntu 24.04 merged-/usr layout,
which puts everything under usr/ and leaves `bin` in the part as a SYMLINK to
usr/bin. On amd64 and arm64 the part's build then downloads MongoDB and copies
its binaries into $SNAPCRAFT_PART_INSTALL/bin, which replaces that symlink with
a real directory. On s390x, ppc64el and riscv64 MongoDB ships no server, so the
build exits early - "No MongoDB server for ...; FerretDB-only arch" - and the
symlink survives.
mongodb is staged LAST of the parts that carry a bin/, so stage/bin is already a
real directory by then, from wekan, caddy and helpers. Copying a symlink onto an
existing directory is the IsADirectoryError, and it fails the whole snap rather
than that one part.
An override-stage turns a `bin` SYMLINK into an empty real directory before
staging, then stages normally. It tests for a symlink specifically, so the
arches where mongod really is there are untouched; it removes before mkdir,
because mkdir -p FOLLOWS a symlink and would change nothing; and an empty real
directory merges into stage/bin without changing anything else.
ppc64el is the same FerretDB-only branch and would hit this too - its own logs
never got that far, because snapcraft's monitor loop died fetching the
in-progress build log from launchpad.net with "[Errno 101] Network is
unreachable" while the build itself was still compiling, and each retry then
submitted a NEW build instead of recovering the running one. That half is
infrastructure, not this file; it is written up with the rest in
../log/snap/TODO.txt.
riscv64 takes the same branch, so this covers it as well.
Not verified against a real Launchpad builder: the fix is read off the failure,
and the s390x leg has to be re-run to confirm it now reaches "Snapped".
Thanks to xet7 !
Spec 43 (All Boards on a phone) still failed in all three browsers with the same
numbers as before: the menu 260px wide over a 157px column, lying across the
boards.
max-width: 100% was not enough, and that is the part worth knowing: a grid
item's default min-width is `auto`, which is its content's intrinsic minimum,
and a MINIMUM BEATS A MAXIMUM. The cap did nothing until the item was allowed to
shrink to it. `min-width: 0` is the same pair the right-hand column beside it
has carried all along, for the same reason and with the same comment. Nothing
inside the menu needs the intrinsic width held open - the workspace name already
ellipses through its own min-width: 0.
Two guards followed the format rather than the other way round. Both were
written against a release with forty entries and rejected v10.55 for being four
dependabot bullets and nothing else: CLAUDE.md keeps a dependency batch as plain
bullets, so a release can legitimately have no <details> at all, and padding one
bump into a block whose body repeats its summary would be the noise that rule
exists to prevent. They count entries OR bullets now.
The empty Files report (spec 41) is NOT fixed - it is made legible. The helper
that fills that table caught every exception and returned [] in silence, which
renders exactly like "there is nothing to show": headers, "No results", and
nothing anywhere recording that it threw. It logs now. The publication says one
line when it matches nothing, whatever DEBUG is set to, because a publication
answering with nothing and a publication never running look identical from the
outside - which is why three runs have not told us which this is.
And node/ - a 2.2G clone of the Node.js 24.x fork the runtime is built from -
joins the other local-only clones in .gitignore, rooted like they are.
Thanks to xet7 !
Four dependabot updates have landed since the release, and none of them is in
the shipped bundle: the two halves of typescript-eslint, sinon, and the
docker/login-action step that signs in to the container registries when a
release image is published. They are a plain bullet each, with the package, the
version pair, one line on what it is, its pull request and the commit that
brought it in - the shape CLAUDE.md prescribes for a dependency batch.
`abdcf8134` needs no entry of its own: it reworded a summary inside the v10.54
section, which is already released.
Two guards had to follow. Both were written against a release with forty entries
and failed this one for being small:
* "the Upcoming section has at least one ENTRY" - a release whose whole
content is a dependency batch has none, because a batch is bullets, and
padding a bump into a <details> whose body repeats its summary would be
noise added to satisfy a test. It asks for at least one change now, entry or
bullet.
* "at least ten entries are grouped" - a fixed count fails a small release for
being small. It is a ratio now: most of what is there is grouped, which is
what the rule is about, and the loose-entry limit beside it is the other
half of the same check. Verified it still catches six ungrouped entries.
Thanks to xet7 !
A workspace held boards and, in the data, other workspaces - but a drag could
only ever say one thing about them, and the fold was not there at all.
WHERE IN A ROW it is dropped is now what the drop MEANS:
the top quarter - it becomes that row's previous sibling
the bottom quarter - it becomes that row's next sibling
the middle half - it becomes that row's LAST CHILD, a sub-workspace
The middle is the biggest target on purpose: reordering can also be reached by
aiming at the neighbouring row's far edge, but nesting has only this one. Coming
back up is a drop like any other - a child dragged onto a root row's edge is a
root again - because nesting has to be undoable or a workspace put one level too
deep is stuck there.
THE PLACEHOLDER IS A SLOT, NOT A LINE. While the pointer is over a row an empty
slot a row high opens above it, below it, or - for "into this one" - INDENTED
underneath it, which is exactly where the workspace will appear. A line between
two rows is a target that has to be aimed at; a slot is a place to drop into.
The slot is a pseudo-element of the row, so the rows below shift down and the
row being aimed at stays where the pointer put it.
A workspace may not be dropped into itself or into its own descendant: the
subtree would be cut off from the root, taking every workspace under it. It is
refused by NOT calling preventDefault(), which is how HTML5 drag and drop says
no, so the cursor refuses while the workspace is still in the air rather than
the drop landing and quietly doing nothing.
AND THE DROP THAT DID NOTHING. With the handles off the drag starts on an
ANCHOR, and a browser puts that anchor's own text into text/plain. The drop read
text/plain first and took the workspace for a BOARD, so it assigned nothing and
the row snapped back - which is why the same drop worked with handles on, where
the drag starts from a span that carries no text. The drag clearData()s before
setting its own type, and the drop decides on the workspace id FIRST.
A CARET FOLDS a workspace's own workspaces away, at the start of the row -
before the drag handle, so the carets of a tree line up whatever the handles
toggle says. It is the control a list has on a board and the one the left menu
itself has, down to the two words in its tooltip, and it answers Enter and Space
because a tree that only opens with a mouse is a tree half the readers cannot
open. A workspace with nothing under it keeps a spacer of the same width, so a
row does not shift sideways the moment it gains its first child.
Open is the default and only the FOLDED ones are stored: a missing key is an
open workspace, so fifty workspaces with two folded is two keys. Remembered in
the same three layers as the rest of this menu - a Session value, then
profile.collapsedWorkspaces, then a cookie for a reader who is not signed in.
The server method takes the id into a DOTTED FIELD PATH and the tree is written
by the client, so the id is checked against ^[A-Za-z0-9_-]{1,64}$ first: one
carrying a `.` or a `$` would address a different field.
The depth is UNLIMITED because nothing counts it: the template draws itself for
a workspace's children, each level indenting by one caret's width with a logical
property, so a right-to-left tree indents from the right by itself.
What a drag does to the tree is a pure module with its own tests -
dropPosition() and moveWorkspace(), the guards included - so the rules can be
proved without a browser, and the page is pinned to calling them rather than
re-deriving them.
Thanks to xet7 !
Member Settings / Change Password renders +atForm(state='changePwd') from
useraccounts, and its submit button carries that package's own classes - a
button.at-btn with no .primary of ours on it. So it fell back to the plain grey
button rule, while the Save button one entry above it in the same menu was
painted with the theme accent. Two buttons, one menu, two looks.
It is named in the SAME rules as .primary rather than given a copy of them, so
the accent and the hover and active states keep one home. Scoped to a popup,
because the login page styles that form its own way and is not what this is
about.
The guard in themeAccents.test.cjs pinned `button.primary {` with the background
on the next line, so adding a selector to that list read as the rule having lost
its colour. It looks for the RULE a primary button gets, whatever else shares
its selector list.
Thanks to xet7 !
The count was there, at the right of the ⋯ menu where it belongs, and it was
invisible.
The accent fills `.js-select-space` - the icon and the name - and NOT the whole
row: the menu button and the count sit after it, on the panel's own light grey.
A rule gave the count a white pill with white text "for contrast against the
filled row", but the count is not on the filled row, so it was white on light
grey. The selected workspace was the one row whose board count could not be
read, and it is the row you have just asked which boards are in.
The rule is gone rather than re-tinted: there is no accent behind the count to
contrast with, so it keeps the same grey pill every other row has.
While here, the count and the menu button are `flex: 0 0 auto` on the desktop
rules too. The name's anchor is `flex: 1`, so without it a long workspace name
shrinks its two neighbours instead of ellipsing itself - which pushes the count
off the row that is supposed to be showing it. The phone rules had said this
already; the desktop ones had not.
The guard in archivePage.test.cjs pinned the white pill as the correct answer,
which is how this survived. It pins the opposite now, and says why.
Thanks to xet7 !
With the handles turned off the drag source was the workspace's ICON alone, and
in practice reordering only worked with the handles on, from the handle.
Two reasons, and the second is why it did nothing rather than being merely
awkward:
* a 16px glyph is a target that has to be aimed at, and the name beside it is
the part of the row a reader is actually pointing at;
* the anchor is not opted out of the page-level dragscroll, which takes the
mousedown, so the drag never begins - and a drag that never begins is
exactly what "reordering does not work" looks like.
The whole icon-and-name anchor is the drag source now, with `nodragscroll` on it
like the handle has, and `user-select: none` while it is the drag source: the
name is TEXT, and a press-and-move over selectable text starts a SELECTION,
which the browser then owns instead of starting an element drag. The handle
never needed that because a glyph in a span is not text anybody selects.
Clicking that same anchor still opens the workspace - a click and a drag are two
gestures on one element, as they are on a board tile with handles off - and the
cursor stays `pointer` rather than becoming `grab`, because opening it is what a
reader does with the row nearly every time.
Still NOT the whole row: it also holds the ⋯ menu and the board count, and a
drag started on those is a drag of something else. draggable lives on the handle
or on the anchor, and the dragstart handler stays on the row, which works
because the event bubbles up from whichever child started it.
Thanks to xet7 !
The panel is fixed at top: 48px - a guess at the height of ONE header bar. The
first header bar wraps to a second and a third row, and the user avatar is the
item that wraps last: on a window where it did, the panel covered the row the
avatar was on, and the avatar - which is inside a z-index: 1000 bar - painted
straight over the panel's own header, beside the X that closes it.
It starts at --wekan-header-height now, which is what the header MEASURES itself
to be, kept current by a ResizeObserver because a bar re-wrapping is not a window
resize. The panel's own fixed header - the row the X is in - follows the same
number, and so does the height it may take: the 100vh - 28px - 36px it had was
the same guess written as a subtraction in two pieces.
That variable is what everything else laid out against the viewport already uses
- the phone sidebar, the All Boards layout and its sidebar - so this is the panel
joining them rather than a new mechanism.
Thanks to xet7 !
The workspace rows in the All Boards left menu drew a ✥ handle whatever the
"Show desktop drag handles" toggle in the first header bar said, and the handle
was decoration: the whole ROW carried draggable="true", so the drag started
anywhere on it. A row that is draggable as a whole starts a drag on the way to a
click, and a workspace row is a row you click - it is how a workspace is opened.
The handle follows the toggle now, through the same
isTouchScreenOrShowDesktopDragHandles helper the board tiles beside it use, so
the two cannot drift apart. With handles ON the handle is drawn and it is the
only place a workspace drag may start. With handles OFF there is no handle and
the workspace's own ICON is what reorders it - the icon rather than the row, so
the name beside it stays a plain click target.
draggable lives on the handle or on the icon, never on the row. The dragstart
handler stays on the row, which works because dragstart bubbles up from
whichever child started it, so the reordering itself is untouched. The grab
cursor follows the same `draggable` attribute - `[draggable="true"]` in the
selector - rather than a second class, so there is one answer to "is this the
drag source right now" instead of two that can disagree.
Thanks to xet7 !
Member Settings / Archive sent the reader to /archive - the full-width page -
and Boards in Archive is a SECTION of All Boards now: a row in its left menu,
drawn beside it like Starred and Remaining. The page is the thing that section
replaced. Landing on it meant the same list of boards with no menu beside it, no
way across to another section without going back first, and the menu row that
says "Archive" was not the row you had arrived at. A menu entry should land you
on the same Archive the menu itself offers.
All FOUR entry points are the same line in a different menu - the board menu,
the member menu, the board sidebar and the All Boards sidebar - so all four go
to /allboards/archive now, built with allBoardsPath(SECTION_ARCHIVE, []) rather
than by spelling the path out in four places that can drift apart. The member
menu also closes itself behind the click, like every other entry in it that
navigates.
/archive is still a route and still renders, so a bookmark from before does not
break; nothing in the UI points at it any more.
The guard pinned FlowRouter.go('archive') in all four files. The behaviour
deliberately changed, so the guard follows it and says why - and it now checks
that the helper really produces /allboards/archive rather than trusting the
call.
Thanks to xet7 !
The Lists/Table dropdown in the first header bar opened a bare list of two
links, while the board's Swimlanes/Lists dropdown - which asks the same question
about the same kind of page - opens with "Board View" above it. A popup with no
title renders no header background and no heading, so the two looked like two
different kinds of control.
It is titled now, and titled with the BOARD's own key. The convention is
<popupName>-title, which would mean an allBoardsViewPopup-title saying the same
two words a second time - and a new key starts as English in all 142 language
files, so most languages would have shown English for a phrase they have
translated for years. Popup.open's titleKey option exists for exactly this.
The guard in allBoardsPage.test.cjs that reads the menu's event map read the
first 160 characters after it, and the comment explaining this handler pushed
the handler past that. It reads the map to its closing line now: a comment is
not a reason for a guard to fail.
Thanks to xet7 !
The house at the start of the first header bar sat further in on a wide window
than on a narrow one, and on none of them on the line the left menu's rows below
it start on.
Its inset is a SUM, and two of the terms were added at some widths only:
* #header carried side padding of its own - 8px below 800px, 16px between 768
and 1024, none between 1024 and 1920, 8px above 1920. Four widths, four
different insets. It has none now, at any width: the inset of this bar is
the bar's own gutter, once. The gutter is on the BAR rather than on its
first item because the bar wraps, and padding applies to every row it wraps
onto while a margin on the first item would indent the first row only.
* .allBoards is the SAME element as .home-icon - span.home-icon.allBoards - so
its side padding lands between the icon's margin and the link, and it was
15px on a desktop against 6px on a phone. It carries padding-block only now.
That 15px was also the gap to the logo beside it; the gap is the 4 + 4 of
the two margins, like every other pair of neighbours in this bar.
And the link's own start padding is the same 6px in every rule, phone rules
included: at 8px, and at 12px on a small phone, a bigger tap target was growing
at the START, which is the inset, rather than at the end.
So the house is at 12 (the bar's gutter) + 4 (the icon's margin) + 6 (the link's
padding) = 22px at every width - the same 22px the left menu's rows are indented
by (4px of margin plus 18px of padding), so the two are one line down the page.
The existing guard added up the three terms it knew about and got 22, and passed
while the house still moved, because the two terms above were not in its sum.
The new one pins the other side of it: no rule, at any width, may add a side
inset of its own.
Thanks to xet7 !
The grip on the left menu's inner edge got its tooltip this release, so
drag-to-resize-left-menu was English in all 142 languages. It is translated
directly now - no external translation service, API or key - from each
language's OWN existing strings: its drag-to-resize-sidebar sentence gives the
pattern and the verb, and its own words for "left" and "menu" replace the
sidebar, so the two controls read as the pair they are.
Applied through fill-translations.mjs, which writes ONLY into placeholders, so a
human translation cannot be overwritten by this; verify-human-preference.mjs
still passes. Filled strings stay local and are not pushed to Transifex.
Klingon, Volapuk, Venda and Tamazight are the least certain: those files hold
another language's text in some neighbouring keys, so their own sidebar
sentence, not the file's other rows, is what each was built from.
Thanks to xet7 !
Spec 08's "notification indicator appears after being mentioned" waited for
`header, #header` to be visible. The first header bar was rebuilt this release
and there is no <header> element and no #header id any more: the bar is
#header-quick-access[role=navigation], which is what specs 18 and 19 already
address it by. The locator matched nothing, so the test asserted that a
non-existent element was visible and failed in all three browsers.
The guard is what changed, not the app - the bar was deliberately rebuilt - so
it now names the bar that is there, and says so in the test for the next reader.
It also asserts the BELL inside that bar, which is what the test is about: the
count beside it arrives asynchronously, so asserting the count would be timing
rather than behaviour, but a notification the user cannot see the bell for is
not a notification.
Thanks to xet7 !
The menu's inner edge - the right one while reading left to right, the left one
under a right-to-left language - now carries a grip, and dragging it changes the
width. It is the same control the right board sidebar has on its own inner edge:
the same 6px strip, the same col-resize cursor, the same nodragscroll so a drag
resizes the menu instead of panning the page behind it, and the same sign flip
on the delta so the widening drag mirrors under RTL rather than needing a second
rule kept in step.
ONE number, on <html>. The width is a CSS custom property,
--wekan-left-menu-width, and everything that needs it reads that: the Admin
Panel's menu, the All Boards one - whose grid track is auto, so the track
follows the menu - and the grip itself, which sits at calc(width - 3px) from the
row's inline start. An inline width on one element could not have done that: the
menu is a different element in a different template on each page.
The default is the number in the stylesheet, and a breakpoint that wants a
different default overrides the VARIABLE, never the menu's width - a rule naming
.side-menu would beat a dragged width, which arrives as an inline property on
<html>, at exactly that one screen size. For the same reason the client REMOVES
the property when nobody has dragged it rather than writing the default into it.
The Admin Panel menu's own width was min(250px, 32vw), which only ever resolved
to 250px above the 800px breakpoint; it is the shared 260px now, because the two
pages draw one menu and a menu has one width.
The grip is positioned against the row/grid around the menu, not inside it: the
menu is its own scroll area, and a handle within it would scroll away with the
entries. Being absolutely positioned it is neither a flex item nor a grid item,
so it adds no column and no gap - which is why the shared menu template can
carry it as a second root and every Admin Panel pane gets it without naming it.
Clamped to 160px..min(600px, window - 240px), with no drag on a phone, where the
menu is full width above the content, and none while it is folded, where there
is no edge to drag. The All Boards menu also takes max-width:100% now, because
the phone rules cap its track at 210px and a fixed width ran out past it.
Remembered in the same three layers as the fold: a Session value first, then
profile.leftMenuWidth, then the wekan-left-menu-width COOKIE when nobody is
signed in - the same cookie mechanism the fold uses rather than the localStorage
the right sidebar's width uses, so one reader's menu is not remembered in two
different places. Saved once, when the drag ends; while dragging, the property
is written directly so the edge follows the pointer without a database write per
pixel. The server method clamps again and refuses NaN, which passes
check(width, Number) and would otherwise store a width no page could recover
from.
Thanks to xet7 !
Folded, the menu was a narrow strip with the caret alone in it. A strip is still
a column: it holds width, it keeps the page from starting at the window edge,
and a caret alone in it is a target that has to be aimed at.
Folded now means gone - no column and no strip - and the way back is the PANE
TITLE beside it: the caret moves to the inline start of the heading, and the
caret and the title are ONE target, so clicking anywhere on it brings the menu
back. Nothing is lost by drawing nothing, because the way back is the largest
thing on the page rather than the narrowest. The heading is drawn even for a
pane with no title of its own - paneTitle() returns {} when no entry is active -
so a folded menu can never be a menu you have lost.
One caret template still, included in both places on both pages, so they cannot
drift. Beside a title it is handed the pane's text as paneTitleKey / paneLabel
rather than the titleKey / label paneTitle() itself uses, so the caret at the
top of the menu, which inherits whatever context the menu sits in, can never
pick a title up by accident. It is an anchor with no href, so it carries
role="button", tabindex="0" and a keydown handler for Enter and Space: without
them the menu could be folded with a mouse and only with a mouse. Its tooltip
and aria-label are one string from a helper that names the pane as well beside a
title, because an aria-label REPLACES the text inside the element and the bare
word would have silenced the heading.
Which element takes the collapsed class differs by page, and that is the point.
The Admin Panel marks its menu: it is a flex row, and a hidden flex item closes
the row up by itself. All Boards marks the GRID, because display:none takes an
element out of a grid but the TRACK it was placed in remains - hiding only the
menu would have left the boards in the auto column with an empty 1fr one beside
them. The grid drops to one column and hides the menu in the same rule, with
!important, because the phone rules set both tracks with an !important of their
own and a phone would otherwise be the one screen still holding an empty column
open.
Thanks to xet7 !
The caret that folds the left menu away - on All Boards and in the Admin Panel -
rendered, pointed down, and did nothing at all when clicked.
Its template draws the caret; the click that folds the menu and the
isLeftMenuCollapsed helper that says whether it is folded live in
client/components/settings/leftMenu.js, and nothing imported that file.
package.json sets meteor.mainModule, so the client is NOT eagerly loaded: a file
nobody imports is not in the bundle at all. The click handler was never
registered, so the caret was a dead control - and an unregistered Blaze helper
is undefined, so the panel never took the collapsed class either, which is why
even the caret itself never turned to point right. The same thing had happened
to adminReports.css, which is why the Admin Panel reports lost their styling.
One import fixes it. The new guard is what stops it happening a third time:
tests/clientBundleImports.test.cjs walks the import graph from client/main.js
and pins that every file under client/components which REGISTERS something with
Blaze - a template's events, helpers or lifecycle, a global helper, a
BlazeComponent - is reachable from the entry point, and that every stylesheet
and template beside them is too. A file that only exports helpers is left alone:
whoever uses it pulls it in. It carries the negative case as well, checking that
removing this very import is reported rather than shrugged off.
Thanks to xet7 !
At the top of both left menus - All Boards and the Admin Panel - there is now a
caret that folds the menu away, and the same caret brings it back. It is the
control a list has on a board: pointing down while the thing is open and right
once it is folded, with the same two words in its tooltip, so there is nothing
new to learn.
Folded, the menu is a strip holding only its caret and the page beside it takes
the width back. Folded rather than hidden outright: a menu with no way back is
a menu you have lost. Everything but the caret goes through a :not() on the
caret rather than a list of names, so a row added later cannot be left sticking
out of a narrow strip. On All Boards the width moved from the grid track onto
the menu itself, because a fixed 260px column would hold the gap open beside a
folded menu.
One state for both pages: they draw one menu, and a reader who folds it away on
one of them has said what they want on the other. It is a Session value first,
so the fold is instant rather than waiting for a round trip, then
profile.leftMenuCollapsed on the user document, and a cookie when nobody is
signed in - a public board has this menu too - through the same cookie helpers
the public list and swimlane collapse states already use.
One caret template for both menus, so the two cannot drift into two different
carets, and the helper that reads the state is global because the panel that
takes the class is a different element in a different template on each page.
Thanks to xet7 !
The right pane began with board tiles and nothing said which list they were.
The page is five lists of boards under one name - Starred, Remaining, Home,
Templates, Archive, and a workspace - so the pane now opens with a heading
naming the one you are looking at.
It is the Admin Panel's own paneTitle template with the same .admin-pane-title
class, so the two pages have one heading at one size and colour rather than two
written twice that drift apart. Only the space below it is set here: the Admin
Panel's gap rule is scoped to its own main-body and does not reach this page.
Drawn once, above the view branch, since the board icons and the Table are two
ways of showing the same section rather than two sections.
Its words are the section's own title key - the same key the first header bar
names the page with and the same one the highlighted menu row carries - so all
three say the same thing. A workspace shows its own name instead, untranslated:
a workspace called "starred" is not the Starred section.
Thanks to xet7 !
Both left menus - All Boards and the Admin Panel - are a light grey card, and
the entry you are on is filled with the theme colour with a white label and
icon: the same treatment the selected tab gets in the bar above it. A menu is
chrome, and tinting the whole card fights the content beside it.
The panel, the labels, the hover, the dividers, the group headings and the
counts are all as they were, and every theme's own header rule names the
selected row again - including the colour slide of a clear* theme, which a
--theme-accent value cannot carry.
The guards and docs/Design/Page/Left-Menu.md describe this arrangement.
Thanks to xet7 !
The Upcoming section is thirty-eight entries, and twelve of them began with
"All Boards" while five more began with "the header bar". The area was repeated
in every summary, so the part that differs started halfway through the line and
the release read as one flat list of forty collapsed blocks.
Each subsection now names an area ONCE, as a bold line with a short description
of what the group covers, and the entries under it drop the prefix: "All Boards
- its sections, its controls, and what the page opens on." then "Home, a
section for the board that opens after login". Not a heading - a ## inside a
release breaks the version list - and the group labels are the areas of the
app, reused across subsections when an area has both a feature and a fix.
Above the first subsection there is now an "In short:" paragraph saying what
the whole release amounts to, with the notable names in bold. It is the first
thing a reader sees, and a release this size otherwise gives no way to tell
what it is about without opening forty blocks.
Every entry, every commit link and every entry body is unchanged; only the
summaries lost their prefixes and the order changed.
CLAUDE.md states both conventions, and two guards check them: that Upcoming
opens with the summary paragraph and that no summary repeats the group it sits
under. The group-line check only reads lines OUTSIDE an entry - an entry body
uses bold for emphasis, and a paragraph opening with one and ending in a full
stop would otherwise be read as a group heading.
Thanks to xet7 !
Both left menus - All Boards and the Admin Panel - were a light grey card with
one row filled in the theme colour. That made the filled row the only part of
the page answering to the theme, so a menu read as a plain grey column with a
coloured stripe in it rather than as a side of the app, next to the header bar
it sits under.
Inverted: the PANEL is the theme colour with white labels and icons, and the
row you are on is a white block cut out of it with dark text. It is also the
easier selection to find - the eye goes to whatever differs from its
surroundings, and one white row in a coloured column differs more than one
coloured row in a white one.
The menu is the colour of the first header bar above it, including the colour
SLIDE of a clear* theme, which a --theme-accent value cannot carry. Every
theme's own header rule now names both menus: before this only six of them
named the All Boards menu, so most themes coloured one menu and left the other
one plain. No theme rule may name the selected row any more - it would paint
that row the same colour as the menu behind it and leave nothing to show which
row is selected - and a guard checks that.
Hover on an unselected row is a wash of white over the theme colour rather than
solid white, which would be indistinguishable from the selected row. The
dividers, the group headings and the counts went with the rows, for the same
reason: a dark rule on a coloured panel is a rule nobody can see.
Two pairs of duplicate count rules were merged while doing this. Each had a
base rule and a colour override with the same selector, which is how a guard
came to read the wrong one.
Documented in docs/Design/Page/Left-Menu.md.
Thanks to xet7 !
The star group in the first header bar is a bookmarks menu now: caret, count,
star. It held boards only - a board could be starred and reached from the
dropdown, and every other page could not, so the one control for "keep this
where I can get at it" worked on one kind of destination and was absent on the
rest, even though those pages have had their own addresses since the All Boards
and Admin Panel URLs landed.
The star on any other page stars THAT PAGE. A bookmark is a relative URL and
the title from the browser tab: relative so it survives the site moving to
another host, and an absolute or protocol-relative URL is refused rather than
cleaned up, because the stored value goes into an href the reader clicks.
The browser tab now says where you are - "Product name - All Boards /
Remaining" - instead of only the product name, so ten open tabs of one WeKan
are no longer ten identical tabs and a bookmark of any of them is named after
the page. The path is the one the header already computes for the title's
tooltip, published through a leaf module rather than worked out twice.
In All Boards / Starred the bookmarks are tiles beside the starred boards, with
the white border the template-container tile carries, the theme's own colour
behind them, and both the title and the URL - the title says where it goes, the
address says what it is. Each tile has its own unstar button, because the star
in the header stars the page you are on.
Dragging a tile past another reorders them, and that is the order of the header
dropdown: the two are views of one array. The move matches both ends by URL
rather than by index, since the two views are rendered separately and an index
from one is a guess about the other.
The list is capped at 50, oldest dropped, because it is a dropdown.
Documented in docs/Features/Board/Starred.md.
Thanks to xet7 !
The All Boards and Admin Panel left menus indent a row by 4px of row margin
plus 18px of link padding, so a row's icon lands 22px from the window edge. The
first header bar sat flush against the edge, so its home icon started 10px in
and every button under it was a little to the left of the menu below.
The bar now carries a 12px inline gutter: 12 + 4 + 6 = 22, the same x as the
menu rows. It is on the BAR rather than on its first item because the bar
wraps - padding applies to every row it wraps onto, while a margin on the first
item would indent the first row and leave the second starting at the edge.
The number is a variable, --wekan-header-gutter, so it has one home, and the
phone overrides that set the bar's padding use it too rather than putting the
bar back against the edge at the widths where the alignment matters most.
The guard adds the three numbers up out of the three stylesheets rather than
pinning any one of them: a test that asserts "18px" passes while the alignment
is broken by a change to one of the other two. It also checks that the two left
menus indent by the same amount as each other - they are meant to look like one
kind of menu - and that no override sets the bar's inline padding to anything
but the gutter.
Thanks to xet7 !
Home no longer takes the top row of the left menu. The top row stays the one
the page opens on - Starred when anything is starred, Remaining when nothing
is - and Home sits under the two of them: after login you are already in the
Home board, so the row that names it is a place to look, not the place to
start.
Taking a board off Home is now the Android launcher's gesture. Pick the board
up in Home and a Remove bar appears above the tiles, only while the board is
actually in the air; drag the board onto it and it turns red; let go and it
asks, and the question says the board itself is not deleted. An affordance that
shows up when the gesture is possible explains itself, and a trash can sitting
permanently under somebody's boards is a button nobody dares press.
Every other target now REFUSES a board that came from Home, in dragover, by not
calling preventDefault - which is how HTML5 drag and drop says no, so the
cursor says no while the board is still in the air. That check cannot call
getData: the drag data store is protected until the drop and only the list of
types is exposed, so the fact lives in the type's name,
application/x-board-from-home, and its presence is the message.
Before this, a board dragged out of Home onto any other row cleared Home on the
way past. That made every drop a Home drop, and a board could leave Home by
accident while being filed into a workspace. One gesture, one destination.
Also repoints two Upcoming CHANGELOG links at the commits that are actually in
history: amending a commit after writing its hash into the CHANGELOG left both
pointing at objects the branch does not contain.
Thanks to xet7 !
One board can be Home: logging in opens it instead of the All Boards page.
That has always existed, set from Multi-Selection's "Set as Home board (opened
after login)", but there was nowhere that said which board it was - the setting
was write-only, and the only way to find out what you had chosen was to log
out.
Home is now a section of All Boards with a row in the left menu, a home icon
and the word Home, a count beside it, and the address /allboards/home. It is
the first row when a Home board is set - it is the board this user starts in -
and still there, further down, when none is, because the place to drop a board
onto has to exist before there is anything in it.
Drop a board on the row to make it Home. A drop replaces rather than toggling:
Home holds one board, and a drop that sometimes set and sometimes cleared would
depend on state the reader cannot see while dragging.
Home is a mark on a board, not a place boards are kept - exactly like a star.
The board stays in Remaining, or in its workspace, and appears in Home as well;
dragging it out of Home onto any other row takes it off Home and leaves it
where it lives. That is why the drag carries where it started.
The server accepts only a board the caller is a member of and that is not
archived, and clears only the board that is actually theirs. Nothing automatic
writes it; Sandstorm's auto-open still persists nothing.
Documented in docs/Features/Board/Home.md.
Thanks to xet7 !
Starred was always the section All Boards landed on. On an account that has
starred nothing that is an empty page with a full one behind it, which reads
as WeKan having lost the boards rather than as a section nobody has filled in.
Now the address that names no section opens Starred when the user has starred
boards and Remaining when they have none, and the left menu puts whichever one
that is on top, so the highlighted row is the first row. Only those two move.
The rule is defaultSection() / menuSectionOrder() in models/lib/allBoardsUrls.js
so the page and its guard read one copy of it. The router no longer answers the
question - it runs before the user document has necessarily loaded - and the
page answers it in an autorun, from the user document's own starred list rather
than from the query that counts boards, whose answer depends on the
subscription and would draw Remaining and then jump to Starred mid-load. An
address that does name a section still wins.
The four menu rows became one row drawn once per section, since an order that
depends on the user cannot be four copies of the same markup.
Thanks to xet7 !
Remaining, then Starred, Templates, and the Archive last.
The order is pinned as a decision rather than left to whichever row happens to
be written first in the markup - the guard reads the four data-types out of the
menu and compares the list, so a reorder is a deliberate edit to a test rather
than something that drifts.
The page still OPENS on Starred: moving a row is not the same as changing which
section is shown by default, and xet7 asked for the first.
Thanks to xet7 !
The Archive had a table of its own, which meant the one place you go to bring a
board back was the one place multi-selection, dragging and the tile layout did
not work. It is drawn with the same board icons every other section uses now,
and the differences are the ones that have to be different: no "Add Board" tile,
because a board cannot be created already archived, and each tile says WHEN it
was archived, which is what tells one old board from another.
Four things had to change for that.
The section's query asks for archived boards - the one section whose query is
the opposite of every other one's - and the menu filter has its own branch for
it, because a workspace assignment survives archiving and the workspace branch
would have hidden most of an archive.
The page subscribes to them, and only while that section is open. The count
beside the menu row comes from a method and says how many there are, not what
they are. The autorun is placed AFTER selectedMenu and boardSearchVar are
assigned: an autorun runs once immediately, so above them it read .get() off
undefined and threw during onCreated - which it did, and xet7 saw it.
The publication sends what a tile draws. It sent seven fields to a template that
reads twelve, which would have rendered grey, nameless tiles.
And the board publication no longer withholds an archived board. It excluded one
unless it was a template, so following a tile's link answered "board not found".
Archived is not a permission: what decides whether the document may be sent is
the membership clause beside it, and that is untouched. The isArchived argument
still governs the CONTENTS, so an archived board opens showing its live lists.
Dropping a board on Remaining brings it back - one board or a whole
multi-selection, which is the point of dragging rather than opening each board's
own menu. It restores through a new restoreBoard method gated exactly as
archiveBoard is: board admin or a global admin. The two must agree, or one of
them is the wrong way round, and the guard checks them against each other rather
than each against a copy of the rule.
Also, from the same screenshots: the home icon and the notification bell now
begin a row at the same x - 4px of margin and 6px of padding each, where the
bell carried 10px from its own stylesheet and the house 8px - and the space
after the username matches the space before the avatar, which it did not on a
page whose bar ends with the name because nothing followed it to provide the
rest.
Thanks to xet7 !
One word, like Starred, Templates and Remaining beside it, and the menu already
says what it is listing - "Boards in Archive" repeated that. It uses 'archives',
an existing key translated in the same 135 languages as the one it replaces, and
the one already used for the archive as a PLACE rather than as an action.
The SECTION title changes with it. A guard pins the two together on purpose -
the header's path names the section and the highlighted menu row names it too -
so renaming only the row would have left "All Boards / Boards in Archive" above
a row saying "Archive", and a reader would have had to work out whether those
are one place. The guard caught exactly that, which is what it is for.
The sidebar's own row keeps its longer label: it sits among Search and
Multi-Selection rather than among one-word sections, and xet7 asked about the
left menu.
One guard fix: the row was sliced out of the markup by a character count, and
the comment explaining this change pushed the label past the end of it. It
slices from the row's own list item to the divider that follows now, so a row
that gains a line does not need the number re-tuned.
Thanks to xet7 !
The workspace highlight was styled for a class that never appeared. `active` is
set by `{{#if $eq id selectedWorkspaceId}}` inside `each nodes` - but
selectedWorkspaceId is a template ARGUMENT, not a helper, and inside `each` the
data context is the NODE. So the bare lookup found nothing on the node, `$eq`
compared an id with undefined, and no workspace was ever active. Two commits ago
I gave that class the theme colour and reported it done; the colour was right
and nothing wore it.
`../selectedWorkspaceId` now, in the test AND in the recursive call - the second
matters as much, because passing the bare name handed undefined to every nested
level, so a child workspace could not have highlighted even once the top level
worked.
The username's own space is split 4px each way rather than 8px stacked after the
name, so the divider on its left no longer touches it. And the avatar's end
margin is no longer zeroed on narrow screens: that was written when the name was
hidden there, so nothing followed the avatar and the gap was waste - the name is
shown at every width now and the avatar was touching it. Second rule in this
stylesheet written for a hidden username and left behind when it stopped being
hidden, so the guard walks every rule that touches the avatar rather than
pinning this one.
And a guard of mine was silently blind. ruleWith() splits the stylesheet on
braces, and I had written a comment containing `a { color: inherit }` - a brace
inside a comment breaks that splitting for every rule after it, so the rule
being looked for was simply never seen and the guard failed against correct CSS.
It strips comments from the whole stylesheet before splitting now, which fixes
it for every comment anyone writes later rather than for this one.
Thanks to xet7 !
Four things, all in the first bar, and three of them were things going MISSING.
The rename pencil vanished on a narrow window. The rules that collapse the home
link's label were written as '.home-icon a' - and the pencil is an anchor in the
same box, so font-size: 0 reduced its icon to nothing too. The home link carries
'header-home-link' now and all 24 of those selectors name it, so a rule about
one anchor stops applying to its neighbour.
The username was collapsed below 800px. That is gone: the bar WRAPS now, so a
name that does not fit costs a row rather than an avatar shoved off the edge,
and who you are signed in as is worth that row. The class that exempted All
Boards and the Admin Panel went with it, along with its helper - with nothing
left to exempt from, it decided nothing, and a mechanism that decides nothing
still reads as one that does.
The avatar sat low. It was floated and nudged up 5px with position: relative -
a float takes an element out of the flex alignment, so it was being lined up by
hand against a row whose height changes with the buttons in it. Its parent is a
centred flex row now and both hacks are gone.
And the gap between the house icon and the page title was 12px against the 8px
every other pair of neighbours has: the icon carries a 4px end margin and the
link added 8px of its own. The link's END padding is 4px now. Its START padding
stays at 8px - that one is the link's inset from the edge of the bar, not a gap
between two things, and the guard says so rather than pinning both to one value.
Thanks to xet7 !
The divider, your avatar and name, the second divider and the sidebar hamburger
are one group now, aligned to the END of the bar - the right edge in a
left-to-right language, the LEFT edge in a right-to-left one. One
margin-inline-start: auto does both, because it is a logical property and the
mirroring is what the browser already does for the writing direction.
This is the one group that is placed rather than packed, and the exception is
the point: everything before it belongs to the PAGE and reads in source order
from the start, while these five are not about the page at all. The divider is
the seam between the two, so the bell stays on the page's side of it.
A box rather than display:contents, unlike the page's button groups. Those
dissolve so their buttons wrap one at a time; these five belong together, and an
avatar left on the first row with its hamburger on the second is worse than the
cluster moving down whole. On a row that wrapped there is no free space for the
auto margin to absorb, so it packs from the start there and fills the row.
The guard that forbids pushing anything in this bar now carries that one
exception by name, and a second guard checks the group holds those five in that
order and that the bell is outside it - so "aligned to the end" cannot quietly
become "everything after the bell", which is a different rule.
Thanks to xet7 !
It took whatever the bar passed down, because a { color: inherit }, so it did
not match Notifications and the rest sitting beside it - and it is a control of
the same bar, not a caption. It is #f2f2f2 now, the value the buttons declare,
and the guard compares the two rules rather than pinning the hex, so changing
the buttons' colour without changing this fails instead of drifting apart.
And one last auto margin is gone. #header-user-bar had margin-inline-start: auto
in layouts.css, which pushed it to the far end of the row - the behaviour
removed everywhere else two commits ago. It survived because it lives in a
different stylesheet than the others did, which is exactly why the guard now
looks for it there too.
Thanks to xet7 !
It had 16px on its left and 4px on its right. The page title's margin-inline-end
was 1rem and the logo carried no margin of its own, so the gap on one side came
entirely from its neighbour and the other side got only the phone toggle's 4px.
Both are 4px now, like every item of this bar, so the gap between any two
neighbours is 8px - the drag-handles toggle included, which was the same fault
fixed one commit ago.
The logo needed a class before it could carry a margin: it is drawn by three
different branches - a custom logo that links, a custom one that does not, and
the stock one - and none of them had one. All three carry header-logo now, so
the spacing does not depend on which is configured, and the guard counts all
three rather than trusting that the one it can see is the only one.
Thanks to xet7 !
It had 18px on its left and 8px on its right, which reads as a hole rather than
as spacing.
The phone/desktop toggle beside it carried 'margin: 0 14px' while everything
else in the bar carries 4px, so the gap to its left was 14 + 4 and the gap to
its right 4 + 4. The toggle carries 4px now, like every other item, so the gap
between any two neighbours in the bar is 8px.
Equalised by making the margins the SAME rather than by picking two numbers that
add up to the same total - the guard checks both, so a future change that
balances the sum by making the parts unequal still fails.
Thanks to xet7 !
The first row ended after the star group with half the bar empty while the
second row was full - Private, Muted, Sort Cards and the rest had all moved down
together.
They sit in one wrapper div, .board-header-controls, and a wrapper div is ONE
item to the bar: when the last button of the group did not fit, the group went
to the second row entire. That is exactly the fault .header-quick-access-end
had, one level further in - fixed there weeks of edits ago and left here because
this group is drawn by a different template.
It generates no box now, and so do the Admin Panel's four tabs. #notifications
and the divider-plus-hamburger stay boxes on purpose: the first also contains
the drawer that opens under the bell, and the second is a pair that means
nothing apart.
Both classes are named in the selector. These elements carry .board-header-btns
too, and the flex rule beside it matches them at the SAME weight - so naming
only the modifier would have left which rule applies to source order, and my
first attempt did exactly that and lost. Checked, 120 against 110, rather than
assumed.
Thanks to xet7 !
With a colour-slide theme the pager had no background at all - clearorange's
header slid and its < and > sat on nothing.
Every fill was followed by 'background-image: none'. That line was there to
defeat the global button gradient in forms.css, and it was already redundant: a
'background' SHORTHAND resets background-image by itself. Once the fill became
--theme-accent-fill, which is a linear-gradient for the six slide themes, the
redundant line stopped being harmless and started erasing the gradient the
shorthand had just set. A flat theme was unaffected, which is why this survived
being looked at.
All seven are gone, including the ones setting a plain colour: the shorthand
covers them, and leaving four of seven would be a rule a reader has to
rediscover.
The guard walks every rule in that stylesheet which fills from the theme and
fails if any of them resets background-image afterwards - the shape, rather than
the seven places it happened to be.
Thanks to xet7 !
Three things.
+ Add Board, the archive's search field and its pager all began flush against
the header, so the first tile looked cut off at the top while the highlighted
menu row beside it had a clear edge above it. The right column starts 10px down
now: the menu panel's 8px of top padding plus its rows' own 2px margin. Derived
from the menu rather than picked to look right once, and the guard checks that
arithmetic rather than the number - so changing the menu's padding without
changing this fails loudly instead of drifting apart.
The pager buttons look like the theme again. They ARE filled with it, but a
disabled one was dimmed to 0.55, and dimming a filled button is exactly what
takes the theme back out: the belize blue #2980b9 arrived on the page's grey as
rgb(122,170,202), a pale wash with no family resemblance to the header above -
and on a one-page list, where BOTH arrows are disabled, that is the whole pager.
0.85 keeps it recognisable at rgb(68,142,191) and still visibly flatter than an
enabled button, which is all the dimming is for; pointer-events: none is what
actually makes it unusable.
And a selected WORKSPACE is filled with the theme, like the selected menu row
above it. It is the same kind of selection, and it was simply left behind on the
old flat #f0f0f0 when the rows were themed - so picking a workspace looked like
nothing had been picked. Its hover is listed on the active rule for the reason
the rows' is: the white hover below sits at equal specificity and, being later
in the file, would wash the selection out as soon as the pointer crossed it.
Its count becomes a light pill, because the mid-grey that read on white
disappears on the accent.
Thanks to xet7 !
Two things, and the first makes the second possible.
Nothing in the bar is pushed to the far end or centred any more. Three rules did
it: an auto margin on the first button after the drag-handles toggle, which sent
everything from there to the right edge; an auto margin on the user menu on
phones; and an auto margin on EACH side of the bell, which centred it in
whatever space was left. Each of them puts a hole in the middle of the row, and
which items land on which side of the hole changes with the window width. The
bar packs from the start and wraps forward now - left to right in a left-to-right
language, right to left in a right-to-left one, which flexbox does by itself
because it follows the writing direction, so there is no second rule to keep in
step.
.header-quick-access-end stays display:contents. It carries no alignment now,
but that is what makes its buttons items of the BAR: as a flex box of its own it
was a single item, and the whole group dropped to the second row together.
And the button names are shown everywhere, at every width. They were dropped
when the bar ran out of room - first below a fixed 1100px, then by measuring
whether the bar had wrapped - and xet7 has now asked for them on boards too. So
the measurement decides nothing, and it is deleted rather than left inert: 111
lines of utils.js, the CSS rule it drove, and 43 lines of guard that described
it. A mechanism that no longer decides anything still reads as one that does.
The bar wraps, and a wrapped second row is a better answer than a row of
unlabelled pictures.
header-keeps-text stays, because it still has a job: the USERNAME, which the
narrow-screen rules collapse everywhere except All Boards and the Admin Panel.
Its comments say that now rather than talking about labels.
An older guard pinned the phone centring on purpose, with a paragraph on why the
bell sat midway. That decision is reversed, so the guard is rewritten to the new
rule and says what changed - and the new one checks the SHAPE: no rule that
positions something within the bar may use an auto margin or a justify-content.
A justify-content inside a button centres that button's own icon and is not
alignment of the bar's items, so the check is scoped to rules on the bar itself.
Thanks to xet7 !
"ResizeObserver loop completed with undelivered notifications", from the fit I
added: it ran inside the observer's own callback, and measuring means SHOWING
the labels and possibly hiding them again - which resizes the very element being
observed. So every notification produced a write and the write produced another
notification, and the observer never settled.
Two changes, and the first is the one that matters.
The bar is re-measured only when its WIDTH has changed. In the steady state
nothing is written at all: with the labels already hidden and still needing to
be, the old code removed the class and added it back on every single cycle.
Verified by running the real function against a bar that wraps while its labels
are shown - one write to settle, then zero, then zero, and two again only after
a genuine width change.
And the fit is scheduled for the next frame rather than called inline, so the
write is an ordinary one whose resize is delivered normally instead of being
raised from inside the callback that is handling the previous resize.
The opt-out path now shows the labels in its own branch, since it returns before
reaching the measurement. Without that a page that opts out would inherit
whatever the last measured page left on the bar - a link from a narrow board to
All Boards would land there with the names hidden - and the guard checks that
branch rather than the statement order it used to rely on.
Thanks to xet7 !
Three things.
The username stays at every width on All Boards and the Admin Panel. The
narrow-screen rules collapse it to font-size: 0 - the avatar stays, the name
stays in the DOM for screen readers - because a full name is easily 100px of a
375px bar. These two pages carry four buttons rather than a board's ten and have
the room, and the name is who you are signed in as. Every hiding selector is
answered with its own copy carrying the class: the widest of them carry
.iphone-device, which outweighs an id and a class on its own, so one short
override would have lost on exactly the narrow screens this is about - checked,
250 against 240, rather than assumed.
The class that marks those pages is renamed from header-labels-always to
header-keeps-text, and its helper to keepsText(). It keeps two kinds of text
now, and a name saying "labels" would have lied about half of what it does.
The bell is named beside its icon, from the key its own tooltip already used,
carrying the same label class as every other named button - so it appears and
vanishes with them rather than needing a rule of its own. Its stylesheet makes
it a fixed 28px SQUARE, which is right for a lone icon and clips a word, so in
this bar it sizes to its content and lays icon and name out like its neighbours.
Scoped to this bar: elsewhere the toggle is still just a bell.
And the grey above and to the left of the All Boards menu is gone. It came from
#content > .wrapper, which is margin-top: 10px and padding: 15px as well as the
width inset - the margin was the grey above, the padding the grey to the left.
My earlier override set width and margin only, so the padding survived; and it
weighed exactly as much as the rule it answered, so which applied came down to
stylesheet order. .wrapper.all-boards-wrapper carries one class more, which
settles it, and the padding is zeroed too.
Three guard mistakes of mine here, all caught by running rather than reading,
and all the same mistake: indexOf on a selector matches whichever rule comes
first, and a selector usually appears more than once - the ordinary styling, a
phone override, the rule you meant. Rather than fix each site again, this file
now has ruleWith(css, selector, declaration), which names a declaration too and
asserts it found exactly one. Its own first version failed as well, because the
regex capture runs from the previous closing brace and so carries the comment
written above a rule; it strips comments from the selector now.
Thanks to xet7 !
Meteor audits that every argument a method was given was handed to check(), and
this one returned 0 for a signed-out caller BEFORE reaching its check(). So
instead of answering 0 it threw
Did not check() all arguments during call to 'getArchivedBoardsCount'
The bug is older than the caller that found it. Its only caller used to be the
archive page, which asks after its own subscription is ready and therefore
always has a user, so the early return was never taken. All Boards now asks for
the count from onCreated - which can run before the user is established, and
which is the right time to ask, since the count is wanted as soon as the page
exists - and the latent bug became an exception on every load.
check() first, then authorise. Validating the shape of what you were given
before deciding whether the caller may have it is the right order regardless: a
malformed argument is malformed whoever sent it. It is also the order the
sibling getPublicBoardsCount already used, which made this one the odd one out.
tests/methodArgumentChecks.test.cjs scans the server methods that take arguments
and check them, and fails on any that can return before the first check() -
rather than pinning this one method, because the bug is a shape and the next
method to grow an early return would repeat it. I verified the guard by putting
the old ordering back and watching it fail, then restoring the fix.
Thanks to xet7 !
Those two carry four buttons each and have room for the words on any window
worth supporting, so the fit measurement leaves them alone. A board carries ten
controls, and is the page the measurement exists for - there it still drops the
names when the bar would wrap.
The header marks the bar `header-labels-always` from the route, and
fitHeaderLabels() returns early when it sees that class. Which page you are on
is the header's business; client/lib/utils.js knows only about boxes, and
teaching it about routes would have put the same question in two places.
It returns AFTER showing the labels, not before. A page that opts out would
otherwise inherit whatever the previous page's measurement had left on the bar -
so following a link from a narrow board to All Boards would land on All Boards
with its names hidden. The guard pins that ordering, because it is invisible
from reading the two lines in isolation.
Thanks to xet7 !
Two bugs in the measurement I added, both visible in xet7's screenshots: the
labels were hidden on a 2560px window whose bar sits comfortably on one row.
It read bar.children, and the buttons are not among them.
.header-quick-access-end is display:contents - it generates no box, so its
buttons are flex items of the BAR while being its own children in the DOM. What
bar.children returns is the four items before it plus that boxless wrapper:
everything except the things that actually wrap. flexItemsOf() descends through
a contents wrapper now, and skips what is not drawn.
And it compared offsetTop against the first item's. The bar is
align-items: center, so everything on one row shares a CENTRE line while their
tops differ by however much their heights differ - and the page title, with its
text and its rename pencil, is much taller than a bare icon. A one-row bar
therefore looked wrapped. Centres are compared now, from getBoundingClientRect
rather than offsets, because offsets are relative to whichever ancestor happens
to be positioned and these items do not all share one.
The tolerance is 6px against a second row that is a whole row away - the
shortest button is 28px - so there is room on both sides of the test.
Verified by RUNNING the real function against a simulated one-row layout (a 28px
title beside a 20px icon, sharing a centre) and a simulated two-row one, rather
than by reading it: false and true respectively, and four items found through
the contents wrapper.
The guard that pins this reads the CODE with comments stripped. Its first
version searched the whole function body for "offsetTop" - which appears in the
comment explaining what was replaced - so it failed on a correct implementation.
That is the fifth time in this file that a guard has read its own explanation.
Thanks to xet7 !
The labels were hidden below 1100px, and a width cannot answer the question. A
board carries ten controls, All Boards four, an Admin Panel page four tabs, and
the words are as long as the reader's language makes them. xet7's screenshots
show both failures at once: at 2266px the labels were shown and the bar wrapped
anyway, and at 1810px they were hidden with a whole row to spare.
fitHeaderLabels() shows the labels, asks the bar whether it wrapped - its last
item sitting lower than its first - and hides them if it did. A tolerance rather
than equality, because items of different heights sit on slightly different
offsets within one row and align-items: center moves them.
It always measures from the SHOWN state. Hiding the labels is what makes the bar
fit, so measuring after hiding would answer "it fits", show them again, and do
that once per frame forever. Removing the class before measuring costs one
reflow per resize and is the whole reason this cannot oscillate - the guard pins
that ordering, because it is the one thing here that is not obvious from
reading.
It runs from the same place that publishes --wekan-header-height, which already
has a ResizeObserver on this bar - and wrapping is exactly what that observer
exists to catch.
Also in this commit, from the same screenshots and the same session:
The pager buttons are FILLED with the theme and their arrows white, instead of
an outline on transparent that put the theme in a 1px border and left the button
a ghost beside solidly themed chrome. They read --theme-accent-fill, a new
variable, because --theme-accent is one COLOUR and a colour-slide theme's fill
is a gradient: a button reading the accent came out flat while the header above
it slid. activeFill() resolves it - a custom pair beats the theme's own slide,
the way a custom colour beats an accent - and the pressed state darkens that
fill rather than replacing it, which keeps a slide sliding.
And both left menus run from directly under the header to the bottom of the
window, flush to its left edge. The Admin Panel's row carried a top padding that
put grey above the menu; the main body carries it now, because content is not
meant to be flush against a bar. Both menus lost their border and corner on the
three flush sides: a rounded corner on a flush edge shows the grey behind it,
which is the gap being removed. All Boards' grid uses column-gap, since a gap is
between tracks and never insets the menu from the window edge.
One correction of mine: activeFill's comment claimed it answers null for an
unknown theme. accentOf answers '' and activeFill defers to it, so it answers ''
too. The comment now says so - the two functions sit side by side and a reader
should not have to remember which returns which kind of nothing.
Thanks to xet7 !
Two things, both of them mine.
Taking the left menu to the window's left edge dropped the wrapper's inset on
BOTH sides, so right-hand content ran to the edge and past it: the archive
pager's ">" was half outside the window, and #content is overflow-x: hidden, so
the half outside was cut off rather than scrollable. The padding goes on the
right COLUMN rather than back on the wrapper - the wrapper holds the menu too,
and an inset there would push the menu off the edge it is meant to sit against.
padding-inline-end, so a right-to-left layout insets the side that is actually
the far one.
And a disabled pager button was opacity 0.4. That was chosen when every theme
accent was a deep colour, where four tenths of it still reads on a light page.
The colour slides added yesterday are built on LIGHT bases - cleargreen #4bbf6b,
clearorange #e67e22 - and at 0.4 an outline in one of those on the page's own
near-white all but disappears. On a one-page list, where both arrows are
disabled, the pager looked broken rather than exhausted. 0.55 is still visibly
weaker than an enabled button beside it, which is the whole job of the rule,
without being a ghost.
The guard pins the inset as a logical property, pins that the wrapper stays
flush so the menu keeps its edge, and pins the disabled opacity between "still
readable" and "still obviously disabled" rather than to one number.
Thanks to xet7 !
clearblue was the only theme in the "clear" category. Five more join it, each a
slide from a light tint down to an existing FLAT theme's own colour, so the two
categories now cover the same colour families: cleargreen from limegreen,
clearorange from pumpkin, clearpink from moderatepink, clearpurple from
wisteria, clearred from pomegranate. A reader who picks either version of a
colour gets the colour they expected.
The rest of each palette is arithmetic on the base, and it is clearblue's OWN
arithmetic - its numbers turn out to be exact. The border under the bar is
base x 0.8, the one above it base x 0.6, the current tab base x 1.15, a selected
minicard the base mixed toward white. Derived rather than guessed, so no theme
can be half-done and a seventh slide is one line rather than a page of hexes.
Each block was generated from clearblue's with one deliberate exception: its
COMMENTS were dropped. They explain clearblue's own history - the flat bar that
looked like strongcyan, the half-white username - and copied into a green theme
those sentences are simply false. Each block carries a header saying what it is
and what it was derived from instead. Every hex clearblue names was mapped, and
the generator refused to run if one was not: an unmapped colour would have
stayed blue inside a green theme.
Board Settings, Member Settings and Admin Panel / Settings / Visibility are one
picker with a scope, grouping by THEME_CATEGORIES - so adding each theme to the
category and to ALLOWED_BOARD_COLORS puts it in all three at once, gives it the
category's two custom colours (a slide has two ends), and validates it on the
server through the same list.
And a bug of my own, from making Boards in Archive a section of All Boards:
clicking it highlighted Remaining. The workspaces-tree autorun treats anything
that is not a section as a workspace id, and a workspace missing from the tree
was deleted, so it resets to Remaining - but the section names were written out
by hand there, and `archive` was not among them. It reads ALL_BOARDS_SECTIONS
now, the same list the router and the URLs use, so a sixth section cannot go
missing from it.
Guards: every theme in "clear" must be a gradient with two DIFFERENT ends whose
solid end is the accent everything outside a board reads - a slide theme with a
flat bar is a flat theme filed in the wrong drawer, which is exactly what
clearblue's own first bar was until it was fixed. Each must paint the picker
swatch, the board canvas, and both selected menu rows. And the archive-highlight
fix is pinned including its import, because a missing import there is a
ReferenceError at runtime that no unit test would see - which is how it first
showed up.
Thanks to xet7 !
The bar showed the whole path - All Boards / Workspaces / Engineering /
Backend, Admin Panel / Settings / Version. The path is what the page IS, but it
grows: a workspace nests as deep as its tree does, and this bar is the one strip
always on screen and already short of width. It shows the root now, and the
whole path is the title's tooltip.
headerTitleFullPath() resolves it to one string, because a title attribute is
plain text and cannot hold the {{_ }} calls the visible version used. It reads
the SAME headerTitle() and the same trail the visible name does, so the two
cannot disagree about where you are, and a workspace's own name still does not
go through the translator.
The trail became a plain function rather than a helper. The first version of the
tooltip called sibling helpers through "this", which in a Blaze helper is the
DATA CONTEXT, not the helpers object - so it would have resolved to nothing at
all. Both callers use the function now, and the guard says why, because that is
a mistake worth only making once.
The headerTitleTrail helper is deleted rather than left: nothing draws the trail
inline any more, so it was a helper no template calls.
Thanks to xet7 !
The theme lived on the second header bar, and most pages no longer render one.
Three themes were wrong once it moved to the first.
clearblue is a colour SLIDE, and the slide was only ever on
'#header #header-main-bar' - the inner element of the second bar. The first bar
took the flat background-color beside it, #00aecc, which is strongcyan's colour
EXACTLY: choosing clearblue painted the header strongcyan. The slide is on
#header-quick-access now.
natural and modern each had a LATER rule repainting the first bar the near-black
shade it wore as a thin strip above the coloured main bar - #2d392b and
#333 !important. Picking Natural painted the header near-black and Modern
charcoal, whatever their own colours were. Both overrides are gone; the shared
rule provides each theme's own colour. Modern's padding and font-size went with
it: those sized the strip, and this bar sizes itself like every other theme's.
clearblue's username is full white. Half-white was right when this bar was a
secondary strip and its username and board links were background furniture; it
is the header now, and no other theme dims them.
And a slide is not a colour. Everything outside a board reads --theme-accent,
which is right for the eighteen flat themes but cannot carry a gradient - so the
All Boards left menu's selected row sat flat #00aecc beside an Admin Panel row
that slid. It is named in clearblue's own rule now, as the Admin Panel's row
always was, and its extra class makes it win over the accent rule.
tests/themeAccents.test.cjs pins every theme painting the first bar, painting it
its own colour, and NO TWO THEMES painting it the same - which is the check that
would have caught clearblue looking like strongcyan.
Two mistakes of mine here, both caught by the guard rather than by reading: the
first version of that guard anchored on a selector prefix the flat rule and the
gradient rule share, so it read the wrong rule and passed; and the first attempt
to add the tests to this file used a harness shape the file does not have, so
they silently never ran.
Recorded and NOT changed: cleanlight's accent is a mid-grey scraped from a
'#header ul li:hover' rule, because it has no plain #header rule at all. Its bar
is near-white and cannot be an accent for white text, so the grey is right by
accident. Choosing a deliberate one is a call about a colour, not a bug fix.
Thanks to xet7 !
The newest run (../log/2026-08-01_03-14-39) is the first since this work: 18
Playwright failures in every one of the three browsers, and one mocha failure.
The run before it had none. All of them are mine, and all of them are tests
describing markup I moved rather than behaviour that broke.
.js-toggle-sidebar was eight of them. The hamburger moved to the first header
bar and became .js-toggle-page-sidebar - one control that opens whichever
sidebar the page has. The page object and the one spec that named it directly
now name the new one. Its handlers in boardHeader.js and sidebar.js are DELETED
rather than left: markup for them no longer exists anywhere, so they were dead
code that reads as a working feature, and the injected CSS rule in boardBody.js
is repointed at the class that exists.
#header-main-bar was two: the RTL layout test used the second header bar as its
"the page has visible text" anchor, and the three list pages it checks no longer
render one. It anchors on the first bar's page title instead, which is where
those titles went.
The rules controls were three: they are a view of the shared page sidebar now,
so the specs open it first. The All Boards search field was one, for the same
reason. The card's copy-link button was two - it is a row of the card's actions
menu, so the page object opens the menu, and the test asserts what reached the
CLIPBOARD rather than reading an href that no longer exists.
That clipboard is RECORDED, not read back: reading it needs a clipboard-read
permission only Chromium can be granted, so a test that read it would pass on
one browser of three. WeKan copies through navigator.clipboard.writeText, so
wrapping that captures the real value everywhere - and it is a stronger check
than the old test, which accepted "no href, so click it and see that nothing
threw" and would have passed even if the button copied nothing.
Two were addresses: /templates now redirects to /allboards/templates, and the
admin spec navigated to /admin-reports and then clicked a menu row. Every Admin
Panel pane has an address of its own, so it goes straight to
/admin/problems/files - no redirect to race with the menu rendering.
The mocha failure is from the board-roles capability table:
allowIsBoardMemberCommentOnly asks that table now, and the table reads
board.members, while the test's stub offered only the old hasMember/hasReadOnly
methods - so it answered false for everyone. The stub is a members array now,
and a second case pins what the old one could not express: it is the ROLE that
decides, not membership, so isNoComments, isReadOnly and an inactive member are
each false. Every expectation was checked against the real function before
being written down.
Not verified by running: Playwright needs the app server and browsers, which
this sandbox does not have. Every edited file parses, and the 292 node suites
pass.
Thanks to xet7 !
The menu had the Admin Panel's panel and its accent, but its rows were still
laid out the old way - rounded pills, floating inside a panel that added 8px of
its own padding on top of each row's margin. Two menus wearing the same colours
and reading as two different menus.
The rows now use the same margins (2px 4px), the same block padding and
reading-direction indent (12px / 18px), and NO rounded corners, so a selected
row is a block across the menu rather than a pill inside it. The panel's own
padding goes with them: the rows carry their margin themselves, and padding on
the panel inset every row a second time.
The dividers line up with the rows rather than running past their ends, and
"Workspaces" takes the Admin Panel's group-heading treatment - smaller,
uppercase, quieter - because it names a group and is not an entry of one.
Thanks to xet7 !
The menu was styled like the Admin Panel's but did not sit like it. The Admin
Panel gets that for free: .setting-content is OUTSIDE .wrapper, absolutely
positioned at full width and height, so its menu is against the left edge and
runs to the bottom. All Boards is in normal flow inside .wrapper, which is
width: calc(100% - 28px); margin: 0 auto - so the menu floated 14px in from an
edge it is meant to look attached to, and stopped wherever its content did.
This page opts out of that inset, and takes its height from 100vh minus
--wekan-header-height - the height the header MEASURES itself to be, because the
bar wraps to a second row and is not one fixed number. A MINIMUM, not a fixed
height: a page with more boards than fit still grows past it, and grid items
stretch to the row by default, so the menu fills whichever is taller without
asking for a height of its own.
The phone rules already override .boards-layout's height through a higher
specificity selector, so the inner scroller they set up is untouched.
The guard reads the .wrapper declaration across layouts.css rather than inside
the first block it finds: .wrapper is declared more than once there, and the
first block carries only the comment explaining the sizes.
Thanks to xet7 !
Boards in Archive moved again, to under Remaining, and it no longer LEAVES this
page. It opens as a section drawn beside the left menu: selecting something from
a menu and then losing the menu is a menu that throws itself away. Its address is
/allboards/archive, the same shape as the other four sections, and the template
is the archive's own so its search and its pager come with it. The standalone
/archive page stays for a direct link, and the sidebar's row still goes there.
It carries a count like the three lists above it, asked of the SERVER rather than
counted from what the page has - All Boards does not subscribe to archived boards
at all, its query is archived:false, and the archive's publication is paginated
to 30, so counting minimongo would answer 0 on a fresh load and something
arbitrary later. getArchivedBoardsCount is the method the archive's own pager
already uses.
Boards can be dragged onto that row to archive them, from any of the four lists
or from a workspace. The left menu already accepts a drop on Remaining, so this
is the gesture already in the reader's hand; the alternative was three clicks
through Multi-Selection. It asks first, because a drop is easy to make by
accident - a board dragged to reorder that lands one row low - and it refreshes
the count afterwards, which a method call will not do on its own.
The Multi-Selection button in the header bar now shows that it is on and offers
the way off, the same pair the board's own has. It looked identical either way,
so the one control that changes what clicking a board does gave no sign it had
changed it. Its helper is registered on the template that uses it: a Blaze
template cannot see a sibling's helpers, and that failure is a hard render error.
The Sort Boards popup is titled from the key that phrase already has, which is
what gives it a header and with it a close button.
And the left menu is styled like the Admin Panel's - a panel with its own
background, border and rounded corners, a selected row in the per-user theme
accent with white text, a white hover with a shadow, and scrolling inside itself
rather than spilling past its own corner. WeKan has one kind of left menu.
One guard was rewritten rather than widened: it looked for a handler within 400
characters of its event map, which has to be re-tuned every time a comment is
added inside that map. It is scoped to the block now.
Thanks to xet7 !
The rules above and below the Workspaces section were a #e0e0e0 hairline - the
same grey as the menu's own right edge - and too faint to separate anything.
They are 2px #888 now, a grey this stylesheet already uses. A light grey needs
AREA to be seen at all, and area is what turns a divider into something that
reads as another row of the menu; a dark grey is legible as a line, so it stays
a line.
2px rather than 1: at 1px a mid-tone rule can land on a half-pixel boundary and
be drawn as two lighter rows on a fractional-scale display, which is the same
faintness this was meant to fix.
Thanks to xet7 !
It was a button in the first top header bar beside Sort, Search and
Multi-Selection. Those three act on the boards in front of you; Boards in
Archive is a PLACE you go instead, so it sits with the other places - a row of
the left menu, below the Workspaces section, drawn like Starred, Templates and
Remaining rather than as a stray link.
The Workspaces section now has a rule above and below it. The left menu is three
kinds of thing in one column - the three board lists, the workspaces tree, and
the archive - and without them the tree ran into its neighbours as if it were
more of the same list. One hairline in the same grey as the menu's own right
edge, not a default hr: that is a beveled 2px ridge and reads heavier than the
border it sits inside. The workspaces header's own top margin goes with it, or
the rule and the margin together read as a gap twice as wide as anything else in
the menu.
The click handler moved WITH the markup, into the map of the template that now
draws it. A Blaze event map only sees events inside its own template, so a
handler left behind in allBoardsHeaderButtons would never fire and the row would
silently do nothing - which is exactly what happened to this button once before.
The guard checks both halves: nothing left in the old map, and a handler in the
new one.
Two existing guards caught the move rather than being edited into agreement with
it, and each now says where the button went.
Thanks to xet7 !
Search was the same shape as Filter: it only ever OPENED, so clicking it while
the sidebar was already showing search did nothing visible and the only way back
was the sidebar's own X, somewhere else on screen from the thing you just
clicked.
The two now share one rule. models/lib/filterButton.js is
models/lib/sidebarViewButton.js, because a module named after Filter answering
for Search would be a name that lies, and one toggleSidebarView() helper applies
it - two copies of "which way does this click go" would eventually be two
answers.
The exception stays Filter's alone, and is now named as what it is rather than
assumed: with a filter ON the sidebar is the one place that says what is being
hidden from the board. Search has no such case - its results are inside the
panel and it hides nothing from the board - so it passes false and always
toggles.
The Admin Panel's four tabs carry their name beside the icon, each from the same
key its tooltip uses, and lose it below 1100px with every other label in the
bar.
Thanks to xet7 !
Sort Boards, Search, Multi-Selection and Boards in Archive each carry their
name beside the icon now, from the same translation key their tooltip uses, and
lose it below 1100px with every other label in the bar.
The board's visibility and watch buttons got theirs in the previous commit; the
changelog paragraph that lists which buttons are named has now grown twice, so
it is re-wrapped as a whole rather than patched line by line - patching it left
a ragged 20-character line in the middle.
That paragraph is also what broke tests/changelogFormat: the guard tolerates 250
over-long lines of legacy content and my edit made it 251. It was failing when I
committed the previous change, because I piped the test run through tail and the
pipe swallowed its exit code. Fixed here, and worth remembering: the suite runner
must be checked by its own output, not by a pipeline's status.
Thanks to xet7 !
Private / Public and Watching / Tracking / Muted are the state of the board you
are looking at, and a padlock or a crossed-out bell is a poor way to read it.
Both carry their name beside the icon now, and both lose it below 1100px with
every other label.
The label is the same DYNAMIC expression as the tooltip - {{_
currentBoard.permission}} and {{_ watchLevel}} - so one line of markup covers
all five values. Written out per value it would be two lists of words to keep in
step with each other and with the board.
Thanks to xet7 !
Sort Cards, Filter, Search and Show Dependencies carry their name beside the
icon now, and so does the board's Multi-Selection alongside All Boards' and the
two view menus. A tooltip is the one place a name cannot be read without
hovering.
Below 1100px every one of those labels goes and the buttons are icons again. A
label is worth several icons' width, so on a narrow window keeping them costs
more buttons off the first row than the names are worth - and the tooltip is
still there for all of them.
All of them together, not some. Half the buttons named and half not reads as a
bar that has been half finished, and WHICH half you got would depend on which
words happen to be short in your language. One rule hides the one class they all
share, so none can be left behind - which is also why the first attempt at this,
an is-optional class on four of the six, was not worth keeping.
The threshold is the window rather than a container query: what a container
query would measure is this bar, and this bar is as wide as the window by
construction.
Each label uses the SAME translation key as its own tooltip, so a button and its
tooltip cannot say different things, and a button whose name changes with its
state - Sort is on, Hide dependencies - says the state in both places. The guard
checks that pairing per button rather than only that a label exists.
Thanks to xet7 !
The bar wraps when its buttons do not fit, but everything after the
drag-handles toggle was wrapped in .header-quick-access-end, and a nested flex
box is ONE item to the bar - so the whole group moved to the second row
together. The first row ended halfway across with nothing in the rest of it
while the second row was crowded, which is the opposite of what wrapping is
for.
The group is display:contents now: its box is not generated, so its buttons are
items of the BAR and wrap one at a time. The second row takes only what did not
fit on the first.
The group stays in the markup - it is what says where the end of the bar begins
- and the auto margin moves to its first child, the item that has to push the
rest to the end. That still mirrors by itself in a right-to-left language,
because margin-inline-start is logical. On a row that wrapped there is no free
space for the margin to absorb, so those items pack from the start, which is
what fills the row instead of stranding it.
Thanks to xet7 !
The popup had no title, so it rendered as a no-title pop-over: no header, and
the close button lives in the header, leaving nothing to shut it but clicking
away.
It is titled "Starred Boards" now, from starred-boards - the key the app
ALREADY has for that phrase - through a new titleKey option on Popup.open. The
convention is <popupName>-title, which is right when a title is that popup's own
words and wrong here: adding starredBoardsPopup-title would put a second copy of
one phrase into all 147 language files, English in every one of them at first,
so most languages would show English for something they have already translated.
The convention still applies to every popup that does not pass a key.
The board's own Multi-Selection button carries its name beside the icon now. All
Boards' got its label earlier; this is a different button in a different file and
was left behind - a check-box outline says nothing about what either does.
Thanks to xet7 !
The bar drew TWO stars in a row - one on the starred-boards dropdown and one
for the board you are on - which reads as a single control somehow drawn
twice. The dropdown has no star now: it is a caret and the COUNT of starred
boards, which is what it is about, and the count is shown even at zero
because it is the button's only label and a bare caret says nothing about
what it opens.
The board's own star sits immediately beside it, and the two are wrapped in a
rounded outline of their own, shaped like the phone/desktop toggle's but
WHITE where that one is black: the toggle is a white box sitting on the bar,
so a dark border shows against it, while these buttons sit on the bar's own
colour and need a light one. Without an outline the two read as unrelated
icons that happen to be adjacent - which is what made the two stars confusing
in the first place.
The star is its own template so the bar can place it here rather than among
the board's other controls further along. A Blaze event map only sees events
inside its own template, so its helpers and its click came with its markup,
and the copies left behind in boardHeaderButtons are gone.
The two view menus and Multi-Selection carry their name beside the icon
again. I had made them icon-only earlier and xet7 asked for the words back;
that is the better call - six view glyphs are six things to learn, a
check-box outline says nothing about multi-selection, and a tooltip is the
one place a name cannot be read without hovering. The bar wraps to a second
row when it runs out of width, which is what makes the word affordable now
and did not before. Sort, Search and Boards in Archive stay icons: those
glyphs are well known. A label does not wrap mid-button - two lines inside a
one-line button is worse than the tooltip was.
Clicking Filter while the filter sidebar is already showing closes it. It
only ever opened, so a second click did nothing visible and the only way back
was the sidebar's own X, somewhere else on screen from the thing you just
clicked. Not while a filter is ON, though: the sidebar is then the one place
that says WHAT is being hidden from the board, and closing it would leave a
board showing a subset of its cards with nothing on screen to say so - so it
stays open, and the X beside the button is what clears the filter.
"Showing the filter" is open AND on that view, because a sidebar open on
Activities is not showing the filter and clicking Filter there has to switch
to it rather than close the panel.
models/lib/filterButton.js holds that rule so "which way does this click go"
is answered once, and the guard checks all four combinations without a DOM.
tests/mobileModeConsistency stopped expecting js-star-board among the board
header buttons and says where it went instead; tests/headerBars pins the
group, its light-against-the-bar outline, the labels, and the filter toggle.
Thanks to xet7 !
A card has had an address since there has been a card route. A swimlane and a
list had none: "the Backlog list of this board" could only be sent as "open
this board and scroll down". Worse, List.absoluteUrl() answered with the URL
of whichever CARD the cache returned first for that list, so the one place
that did offer a list link - listMorePopup - showed a card's address, and an
empty box for an empty list.
Both have their own now:
/b/<boardId>/<slug>/swimlane/<swimlaneId>
/b/<boardId>/<slug>/list/<listId>
FIVE segments against the card route's four, which is the whole reason the
three can coexist: a card URL cannot match these and these cannot match a
card. A guard checks all nine combinations, because losing a segment would
silently turn a link to a list into a link to a card called "list". The kind
is a word in the path rather than a query parameter - it is part of what the
address names, and a reader can see which is which. config/router.js
registers the routes from the same constants the links are built from, so the
two cannot disagree about the path.
Following one brings the thing into view. The route cannot do that: it runs
before the board has rendered, and on a board that is already open it runs
without re-creating anything, so at that moment there is nothing on screen to
scroll. It names what to reveal in a Session value and the board body reveals
it, WAITING for the element rather than assuming it - swimlanes and lists
arrive as their subscriptions do and a large board renders in more than one
pass, so a single look on the next tick finds nothing on a cold load. It
gives up after a few seconds rather than spinning: a link to a list that was
archived names an element that is never going to exist, and the board is
still the right place to have landed.
The Session value is cleared when acted on AND when given up on, so it is a
one-shot instruction about the address you followed rather than a standing
order that re-scrolls on every later render - and cleared BEFORE the scroll,
because scrollIntoView can re-enter the autorun through the reactive read.
Every other board route clears it too: without that, opening a card after a
list link would scroll the board away from the card it had just opened.
The element ids are the ones the templates already carry, held as a map and
not derived by a rule. Deriving one name from another is how
allBoardsMultiselectionSidebar happened, and this failure is silent - nothing
is found and nothing is reported - so a guard checks each id against the
markup that draws it.
All three are copied the same way, from the FIRST row of the hamburger menu,
with the link icon and the name beside it. The card carried this as an icon in
its title header named only by a tooltip, which is the one place a name cannot
be read without hovering; that button is gone, and so are its handler and the
"Copied" tooltip only it used - a handler for markup that no longer exists is
dead code that reads as a working feature.
The copy row sits ABOVE every permission check in those menus. Copying an
address is reading, not editing: somebody who may only read the board can
still tell a colleague which list they mean, while everything else in those
menus changes the board and stays guarded. It copies absoluteUrl(), because
what lands in the clipboard is pasted into a chat and a relative path is only
a link inside this page.
copy-link-to-clipboard is added to all 147 language files, in the same
position in each. 119 are really translated, each derived from that
language's OWN existing copy-strings rather than invented. The 16 that keep
the English placeholder are the ones whose existing copy-strings are already
in the wrong language - Romanian holding Italian, Esperanto holding Spanish,
Hindi holding Gujarati - where deriving from them would only spread the
error; the en_* variants are English by design.
docs/Design/Page/Header.md is written at last. Twenty-seven comments have
been pointing at it since the header restructure began and it had never
existed, so every one of them was a dead reference.
Thanks to xet7 !
Sort, Search, Multi-Selection and Boards in Archive were rows of the right
sidebar's home view, so reaching any of them meant opening a panel over the
boards first. They are icons in the FIRST top header bar now, left of the
notification bell - exactly where a board's own controls are - each named by
a tooltip, like every other button of that bar. They have now been in three
places: the page's own body, a second top header bar, and that sidebar view.
The home view was the only thing the hamburger opened, so All Boards no
longer offers one, nor the divider before it. A menu to reach what is already
one click away is a step with nothing in it. NO_HAMBURGER_ROUTES in
models/lib/pageSidebar.js is what says so, and a board is deliberately not in
it: what a board's sidebar holds - members, labels, activities, settings - is
not in the bar and has nowhere else to be opened from.
The sidebar is still reachable, and that mattered enough to guard: removing
the hamburger removes the only generic way in, so Search and Multi-Selection
opening it ARE the way in, and if their event map went the panel would become
unreachable and both features would stop existing. The home view is not dead
markup either - it is what the back arrow of the other views leads to.
Boards in Archive is drawn in two places now. A Blaze event map only sees
events inside its own template, so each copy needs its own handler; a copy
with markup and no map is a button that silently does nothing, which is
exactly what happened to that button once before. The guard checks both
copies rather than one.
Three existing guards had to change, and each says why: the page-body check
now scopes itself to the board-list markup rather than the whole file, since
the controls live in that file again; the archive guard checks both copies
instead of asserting the header must NOT handle it; and the hamburger guard
learned that a page can have a sidebar and still not be offered one.
docs/Design/Page/All-Boards.md described a second header bar that no longer
exists, so its controls section is rewritten to what is there.
Thanks to xet7 !
Sub, sub-sub, sub-sub-sub and further already worked in both places xet7
asked about - the URL is /allboards/workspaces/workspace-name/sub-name/
sub-sub-name, and the first header bar reads All Boards / Workspaces /
Workspace Name / Sub Name / Sub Sub Name - because nothing in the path
counts levels: workspaceSlugPath recurses to the node, splitWorkspacePath
splits on every slash, workspaceIdForSlugPath walks each segment, and
workspaceNamePath names each one. What was missing is a guard saying so, so
nothing later caps it silently. A cap would be invisible until somebody made
a workspace one level deeper than whoever wrote the cap imagined.
Two tests in tests/allBoardsUrls.test.cjs. The first builds a six-level tree
and follows the deepest node all the way round: the URL carries six segments,
the route splits it back into six, it resolves to the LEAF rather than to an
ancestor, and the header names all six in order - on the stub slugifier and
again on limax, which is what actually runs. It also pins the route pattern
itself, `:path*` and not `:path?`, since that is what allows the trail to be
captured whole; with `?` a sub-sub-workspace would quietly resolve to its
parent.
The second walks EVERY node of the fixture tree, ancestors included, not only
the leaves: an ancestor is a workspace you can open too, and its URL must be
its own trail rather than the prefix of one of its children's.
Thanks to xet7 !
The bar said "All Boards" on Starred, on Templates, on Remaining and inside
every workspace - it named the page and not the list you were looking at. It
shows the path now: All Boards / Starred, All Boards / Workspaces /
Engineering / Backend.
The section's words are the LEFT MENU's own key, so the title and the row
highlighted beside it always say the same thing. A workspace's words are its
NAME rather than the slug the URL carries - the slug is lowercase and
hyphenated and is not what the workspace is called - and the name is printed
as text rather than translated: it is what a person typed, and a workspace
called "starred" is not the Starred section.
A trail segment that names nothing stops the walk and the title shows what
was still real, so a stale link names the part of the path that still exists
rather than nothing at all.
The header walks the tree itself, from the URL and from
user.profile.boardWorkspacesTree, which is where the All Boards page reads it
from too. It cannot ask the page: the header is a separate Blaze instance,
and importing a page module from here once ran it before its own template was
registered, and the throw aborted every module after it.
The Admin Panel's two segments and these are ONE list now, not a helper per
segment. The two pages do not have the same number of them - the panel always
has two, a workspace has as many as its tree is deep - so a fixed set of
helpers could only ever serve whichever page was written first. Each entry is
one of the two forms a left-menu entry already has: a key for something
translated, a title for text that must not go through the translator.
Guards in tests/headerBars.test.cjs pin every section's key against the left
menu's markup and against en.i18n.json, that an unknown section titles the
default rather than nothing, the name walk including both ways it can stop
early, that the tree comes from the user document, that a workspace name is
pushed as a title and never as a key, and that a board has no path at all
because its own title is the whole name. tests/adminUrls.test.cjs follows the
panel's pane title into the same list.
Thanks to xet7 !
The summaries carry the hash in the href, so they can only be written once
the commit exists. The two header-bar fixes are the commit before, the Admin
Panel move is this one's parent.
Thanks to xet7 !
The four pages sat at the TOP level - /settings, /people, /attachments - as
if they were pages of the app rather than of the Admin Panel, and
/attachments is also the path the file server serves attachments from
(server/routes/universalFileServer.js), so the panel and the files were
claiming one address. They are under /admin now: /admin/settings/version,
/admin/people/login, /admin/problems/database, /admin/attachments/backup.
The default pane is named too. It used to be left implicit in a bare page URL
- /settings rather than /settings/version - so the address of "Settings" and
the address of "Settings showing Version" were one string. The address is
meant to say where you are, and the first pane is somewhere too. The bare
/admin/settings still resolves; it redirects to the pane's own address rather
than being a second name for it.
Every path the panel used to answer on redirects - the bare old address, the
old one with a pane in it, and /setting, /information, /translation. They are
built from the same map the URLs are, so a page cannot be given an address
without also being given its redirect, and a bookmarked
/settings/global-webhooks keeps its pane instead of landing on the top of the
panel.
The title beside the house icon names the same three things: Admin Panel /
Settings / Version. The page's words are the tab's own key and the pane's
words are the menu row's own label, so the title, the tab that is marked
active, and the row that opened the pane cannot say different things about
one place. The pane title is read from the URL rather than from the page,
because the header is a separate Blaze instance from the Admin Panel's pages
and must not import them - doing that once ran a page module before its own
template was registered, and the throw aborted every module after it. That
makes ADMIN_PANE_TITLES a second copy of the menus' labels, and a guard
checks every entry of it against the real menu entry for that pane.
The button of the page you are ON keeps the hover background, permanently and
a shade darker. The tabs had marked themselves .active all along, but the only
rule that drew it was scoped to #header-main-bar - the second bar, which those
tabs no longer live in - so the state had been computed and invisible since
they moved. Darker than the hover rather than equal to it: hovering the tab
you are already on must still look like a hover.
--wekan-header-height measured #header - the SECOND bar - from when every page
had one. Most pages have none now, so on those the variable was 0 and
everything laid out against it started at the top of the WINDOW, underneath
the first bar: the All Boards sidebar covered it. It measures both bars now,
as the BOTTOM of the lowest rather than a sum of heights, so any margin
between them counts and a bar that is absent contributes nothing without a
special case - and each bar has its own ResizeObserver, because the first one
wrapping to a second row is a resize of that element and of nothing else.
A divider after the notification bell. Everything before it belongs to the
page - its controls, its view menu, the panel's tabs; everything after
belongs to you - help, your account, the sidebar toggle. Without it the run
of icons reads as one list of unrelated things.
The URLs went through a hyphenated shape - /admin-settings-version,
/allboards-starred - before xet7 asked for the slash form instead. All
Boards is back to exactly what it was; only the Admin Panel moved.
Guards: tests/adminUrls.test.cjs pins the /admin prefix, that every pane is
named in its URL including the default, that each page records the path it
used to answer on, that the three redirect shapes exist and carry the pane
along, and that every pane title matches the real menu entry's label - both
directions, and a translation key has to be a real one. tests/headerBars
pins the divider and the darker active mark; tests/sidebarBelowHeader pins
that the height covers both bars. tests/adminOldUrlRedirect's route-body
helper now understands a route whose path is an expression, since the panel's
four take theirs from adminRoutePath(page) so the route and the links cannot
disagree.
Thanks to xet7 !
Six things, all in the one bar that is always on screen.
The bar wraps. It was one row with `overflow: hidden`, so a button that did
not fit was not drawn at all - and a button that is not drawn gives no sign
that it exists. It is `flex-wrap: wrap` now with a row gap, and every height
on it became a minimum, including the four phone rules that pinned 40px or
48px: a content box with a fixed height cannot hold two rows, so it would
have cut off exactly what the wrap was for. A phone is where the buttons run
out of room first, which makes it the last place that should hide them.
Everything after the drag-handles toggle hugs the end of the bar, from one
`margin-inline-start: auto` on a new `.header-quick-access-end` wrapper. That
is a LOGICAL property, so a right-to-left language mirrors it by itself
rather than needing a second rule kept in step with the first.
Both view menus are icons now. The board's said "Swimlanes" beside its icon
and All Boards' said "Lists"; the name is in the tooltip instead, where the
other buttons of that bar already keep theirs. `boardViewName` maps the six
views to their own keys, so the tooltip says which view is on.
The button of the page you are ON keeps the hover background, a shade darker
and permanently. The Admin Panel's tabs have marked themselves `.active` all
along, but the only rule that drew it was scoped to `#header-main-bar` - the
second bar, which those tabs no longer live in - so the state was computed
and invisible from the moment they moved. Darker than the hover rather than
equal to it: hovering the tab you are already on must still look like a
hover.
The Admin Panel says which of its four pages is open - "Admin Panel /
Settings". All four of its routes answered the same key, so the bar said the
same three words on every one of them. The second segment uses the same
translation key as the tab's tooltip, so the title and the tab that is marked
active cannot drift apart. Only the Admin Panel has one; a page whose name is
the whole answer gets no slash, and neither does a board, whose own title IS
its name.
A sidebar button is no longer drawn under the close button. `.sidebar-xmark`
is `position: absolute`, so it contributes no height and the row holding it
collapsed to its padding - on a board that row also holds the keyboard
shortcut buttons and so has a height anyway, which is why only the All Boards
and shared page sidebars showed it.
Two mistakes here were reverted rather than patched, because patching them
would have left the damage in the file. A regex rewriting `header.css`
matched inside `min-height` and produced `min-min-height`; and a slice of
`boardHeader.jade` ran backwards, deleting every template between
`boardVisibilityList` and `boardViewMenu` - that is what
`Template.boardChangeTitlePopup is undefined` and `Template
"boardVisibilityList" is set twice` were. Both files were restored from git
and redone with exact replacements.
Guards in tests/headerBars.test.cjs pin all six: that no rule on the bar
forces one row, clips, or fixes a height; that the end group is pushed with a
logical margin and never a physical one; that each view menu names its view
through a real translation key; that the active mark is darker than the hover
and survives being hovered; that the Admin Panel's second segment shares its
key with the tab; and that both sidebars reserve the close button's height.
The wrap guard reads the DECLARATIONS, not the comments - the rules that
replaced these explain themselves by naming `nowrap` and `overflow: hidden`,
and a guard that greps the whole body reads its own explanation.
Thanks to xet7 !
set-selected-unstarred ("Unstar the selected boards") and multi-selection-off
("Turn Multi-Selection off") were added with this session's All Boards work and
went into every language file as English placeholders, which is what the
translation policy does with a string untranslated everywhere. 90 languages were
filled in the first pass; these are the rest that I can write with confidence -
Welsh, Esperanto, Frisian, Valencian, Asturian, Azerbaijani, Armenian, Georgian,
Khmer, Mongolian, Tamil, Telugu, Punjabi, Gujarati, Odia, Uyghur, Uzbek, Xhosa,
Zulu, Yoruba, Breton, Occitan, Walloon, Yiddish, Wolof, Igbo, and the Chinese
variants, with their regional tags.
131 of 142 languages have both strings now.
Each is written from that language's OWN existing translations rather than from
English: the sibling key set-selected-starred is already translated in every one
of these files, and click-to-unstar and multi-selection-on gave the verb and the
noun each language actually uses for starring and for multi-selection.
Eleven are deliberately left as English placeholders - ace, ary, ja-HI, tk_TM,
tlh, ve, ve-CC, ve-PP, vl-SS, vo, zgh. I cannot write those to a standard I
would stand behind, and the policy is explicit that the English source standing
in is the honest state for a string nobody has translated. A guess dressed as a
translation is worse than a placeholder, because nothing marks it as a guess.
Applied with fill-translations.mjs --apply, which writes ONLY into keys that are
still English placeholders, so it cannot overwrite a human translation.
verify-human-preference.mjs passes 10/10, the diff touches these two keys and
nothing else, and every file still holds the same 2333 keys. Nothing is pushed
to Transifex: a filled string must never be able to masquerade as human there.
Thanks to xet7 !
Three things, as asked.
NO DUPLICATE BOARD NAME. The second bar drew the board's title in an `h1` of its
own, under the same name in the bar above it. The first bar has said it since
the first step of this work; the h1 is gone.
THE PENCIL IS BESIDE THE NAME. Renaming a board belongs next to the board's
name, not in a bar of its own, so `boardEditTitleButton` renders immediately
right of the title in the first bar. Board admins only, as before.
EVERYTHING ELSE IS AN ICON, LEFT OF THE BELL. Visibility, watch, star, sort,
the board's rule buttons, filter, search, dependencies and Multi-Selection, each
named by a tooltip and none carrying a visible label. The bar is one row shared
with the logo, the starred boards, the view menu, the bell and the user menu;
ten labelled buttons do not fit at any width.
The desktop/mobile duplication went with it. The old bar wrote the whole set out
TWICE - `unless isMiniScreen` and `if isMiniScreen` - because a row of labelled
buttons does not fit on a phone. Icons do, so one copy serves both, and the two
switches that had to be kept in step are gone rather than kept in step.
headerBarControls.jade is deleted. It held one Search button and one
Multi-Selection button, written for this bar and All Boards'; both bars are gone
now, so a template shared by nobody was indirection rather than sharing.
Every route reference goes with the bar: config/router.js names no headerBar at
all any more.
Six guards followed, and four of them existed only to measure this bar: the
title-plus-buttons row that a long board title split across two lines, the
wrapper that fixed it, the phone layout, and the hamburger that shared the first
row with the title. All of that was one problem, and the problem is gone with
the row. Each says so where it used to measure it, rather than being deleted.
Thanks to xet7 !
Two things the screenshot showed, both consequences of emptying the second bar
that I had not followed through on.
A TALL EMPTY BLUE STRIP under the first bar, on every page. `#header` is a
coloured block with a height of its own, and most pages have no second bar any
more - their title is in the bar above and their controls are in a sidebar - so
it painted an empty band wherever there was nothing to put in it. It renders
only where a page still has a header bar now.
CRAMPED BARE GLYPHS in the first bar. Every rule that styles a
`.board-header-btn` was scoped to `#header-main-bar`, which is the SECOND bar -
so the page's view menu, the starred-boards dropdown, the Admin Panel tabs and
the sidebar hamburger, all of which moved UP into the first bar, had no padding,
no height and no line-height and ran together into one another. The first bar
states the same look for its own buttons, with its own divider.
That is the same mistake as the All Boards search box, which kept matching
`.boards-path-header .board-search` after it had moved: a control that moves
between containers takes its stylesheet with it or stops being styled at all,
and nothing says so until somebody looks.
Thanks to xet7 !
The first header bar names three pages that carry a name of their own - Support
and Accessibility can be renamed by an admin, and Import names the source it is
importing from - and it asked for those names by importing each page's own
module.
The header is rendered by the layout, so it loads very early. Importing a page's
module pulls that module into the header's graph and RUNS it, before its .jade
has registered. `Template.import.onCreated` was `undefined.onCreated`: a
TypeError at module load. A module that throws aborts every module after it, so
the visible symptom was not that one page - it was "No such template:
connectionMethod" and a string of others that never got to register at all.
The three titles are in client/lib/pageTitleSources.js now, which registers no
template and touches no DOM, so it is safe to load at any point. The header asks
that; the pages use the same one rather than each keeping a copy.
A guard asserts the header imports nothing from client/components, that the
module it does import registers no template, and that neither page defines a
second copy of its own title. It reads the CODE and not the comments - the
module explains the bug by naming Template.import.onCreated, and the first
version of the guard failed on its own explanation.
Thanks to xet7 !
The first bar listed every starred board inline. That is the widest thing in the
bar, and it grows with the number of boards you star, so the bar could not stay
one row - which is what it has to be now that the page title, the view menu, the
Admin Panel tabs and the sidebar hamburger are all in it.
It is one button: a caret, then a star, laid out exactly like the view menu
beside it - caret first, then what the button is about - with the number of
starred boards on it the way a board's own star shows its count. The names are
in the popup it opens, shaped like boardChangeViewPopup because it is the same
kind of menu opened from the same kind of button: a pop-over list of links, with
a check on the board you are looking at, and something to say when none are
starred.
On a phone it is full width. Nothing here asks for that: body.mobile-mode
already makes every pop-over full screen, so using the ordinary popup was enough
- and the guard says so, rather than leaving the next reader to wonder where it
comes from.
One thing is deliberately NOT folded in: on a phone, inside a list, the bar
still shows that board's LISTS. That is a different thing from the starred
boards - it is what tells you where you are while you swipe between lists - so
it stays as it was.
Thanks to xet7 !
You asked me to check where the view dropdowns are. They were in two different
wrong places, and neither was the one that makes sense.
A view menu says what you are looking AT. That belongs beside the page's name,
in the bar that is always on screen - not in a second header bar, which is where
the board's Swimlanes / Lists / Calendar / Gantt / Table / Stats menu still was,
and not behind a panel you have to open first, which is where I had put the All
Boards Lists / Table menu one step ago. Both are in the first bar now, one or
the other by page, left of the notification bell beside the Admin Panel tabs.
Each is its own template with its own handler, because a Blaze event map only
sees events inside its own template. The board's keeps its `unless
currentBoard.isTemplatesBoard` - there is nothing to look at six ways on a
templates board - and the All Boards one still names the CURRENT view rather
than itself, the way the board header says "Swimlanes" or "Lists" and never
"Board View".
Public is deliberately not in the list of All Boards routes here: it has no
Lists/Table choice to offer.
Three guards followed the menus, and a new one pins where they are, that each is
handled where it is drawn, and that neither is left behind in the place it came
from.
Remaining: the board's own second header bar, which is now one control lighter.
Thanks to xet7 !
Fifth of the header restructure, and the answer to the question I had left open:
the panel's tabs are navigation BETWEEN its four pages rather than controls of
one, so they do not belong in a right sidebar with a page's controls. They
belong where you can always see which of the four you are on - the first header
bar, immediately left of the notification bell.
Icon only, each named by a translated tooltip, because that bar is a single row
shared with the logo, the starred boards, the notification bell and the user
menu; four labelled buttons would not fit beside them. They link by route NAME,
as they did.
The tab bar goes with them, and its four route references. "Admin Panel" is
already what the first bar says on all four routes - models/lib/pageTitles.js
has mapped them since the first step - so the panel is named once, there, rather
than by an h1 of its own.
Which routes ARE the Admin Panel is read from the one place that already lists
them, adminUrls.js, rather than spelled out again in the header.
Three guards followed. The same mistake as last time was caught by the same
guard: settingHeader.js still registered onCreated, onDestroyed and helpers on a
template that no longer existed, which throws at module load and aborts every
module after it - they are on adminPanelTabs now. The security-log guard checked
for a `.setting-header-btn.problems`, and the multitenancy guard checked that
Settings and Problems sit behind the site-admin check; both properties are
unchanged and both now read the markup where it is.
Remaining: the board's own second header bar, which is the last one with
controls in it.
Thanks to xet7 !
Fourth of the header restructure. This page had the last second header bar with
controls in it, and it now has none: the first bar names the page, and every
control is a row of the right sidebar the page already had.
Only two things actually needed moving. Sort and the Lists/Table view menu
become sidebar rows, keeping what made them worth looking at - Sort still shows
emphasis while a sort other than the custom order is on, and the view row still
names the CURRENT view rather than itself. Search and Multi-Selection did NOT
move: the sidebar's home view has offered both as rows since it was written, so
carrying the header buttons across would have listed each of them twice.
The handlers moved with their markup, because a Blaze event map only sees events
inside its own template, and the bar's helpers went with the bar.
One consequence worth naming: headerSearchButton and
headerMultiSelectionButton were written for TWO bars, and there is one left. The
board header is the only user now. They stay shared rather than being folded
back into it, because the board's bar is the next one to be emptied - but the
guards say plainly that the sharing has one side today, instead of asserting a
parity that no longer exists.
Six guards followed. The control-order test has now followed these controls
three times - `.path-right`, then the header bar, then nowhere - and says so;
the Public page's "do not print the title twice" test names the FIRST header bar
as what prints it; and the All Boards tests read the sidebar where they used to
read the bar.
Remaining: the board's own second bar, and the Admin Panel's tab bar.
Thanks to xet7 !
Third of the header restructure, and the simplest: Support, Shortcuts,
Accessibility, Broken Cards, Import and Boards in Archive had nothing in their
second header bar but the page's name, which the first bar carries now. The bar
and the route reference go with it, so the page is its content and nothing else.
Three of them do not have a FIXED name, and dropping the bar would have lost it:
an admin can rename Support and Accessibility, and Import names the source it is
importing from ("Import / Trello"). Each of the three exports its title, and the
top header bar asks for it - a custom title beats the key and is printed as
text, exactly like a board's. So the title rule is three sources in order: the
board's, then a custom one, then the key.
Shortcuts and Import also had a back arrow to All Boards. The house icon in the
first bar is that link, on every page, so it went with the bar rather than being
carried over as a second one.
The repo's own guard caught the mistake in this: support.js and accessibility.js
still registered onCreated and helpers on templates that no longer existed,
which throws at module load and aborts every module after it. The registrations
are gone; the SUBSCRIPTION each one made is not, because the top header bar
reads the same setting to name the page - it just belongs to the page's own
template now.
Two guards updated: the archive page is named by the top bar rather than by one
of its own (its title has moved three times, and each move left the previous one
to remove or the name is printed twice), and the page-sidebar guard now covers
all ten removed bars rather than the first four.
Remaining: the board's own second bar, All Boards' own, and the Admin Panel's
tab bar.
Thanks to xet7 !
Second of the header restructure. The title moved to the first bar last time;
the buttons move here, so a page is its content plus one panel rather than its
content plus a strip of buttons above it.
Four pages had controls in their second header bar: My Cards, Due Cards, Global
Search and Rules. Each group becomes a <page>Controls template, and the shared
page sidebar renders it. Their header bars are gone entirely - title moved,
controls moved, nothing left to hold - and the routes no longer name them, which
they must not: a route naming a template that does not exist renders "No such
template" in that bar.
The handlers followed their markup. A Blaze event map only sees events inside
its OWN template, so Template.dueCardsHeaderBar.events would have fired for
nothing once the buttons were somewhere else.
The sidebar itself is the board sidebar's shell again - the same classes, the
same close button, the same content area - with the two things the All Boards
one had to learn: the theme goes on a WRAPPER, because every themed sidebar rule
is a descendant selector and a class on `.sidebar` matches nothing; and it is
pinned to the viewport below the measured header height, sharing that rule with
the All Boards panel rather than restating it.
Which sidebar the hamburger opens now depends on where you are: a board's own, All
Boards' own, or this shared one. And it is only drawn where it opens something -
a page with no controls has no sidebar and no hamburger, because a panel that
opens empty is worse than no panel.
One guard needed correcting: the All Boards geometry test read a single
selector, and that rule is a selector list now.
What is still NOT done: the board's own second bar and All Boards' own, whose
controls have a sidebar to move into but have not moved yet, and the Admin
Panel's tab bar. The pages that were only a title - Support, Shortcuts,
Accessibility, Broken Cards, Import, Archive - keep their second bar for now;
they have nothing to move, only a title to drop.
Thanks to xet7 !
First of the header restructure. Three things, all in the bar that is always on
screen.
ONE COLOUR. Each theme painted the two bars two shades apart, so the header read
as two headers stacked. They are one colour now, and per theme it is stated
once: the quick-access bar joins the selector list the main bar already has,
rather than restating each hex a second time. moderndark said it its own way and
was the one theme where the two really differed (#2a2a2a against #333); it is on
the main bar's colour like the rest.
THE PAGE'S NAME, not "All Boards". The first bar said "All Boards" beside its
house icon on every page, whatever page it was - so the bar that is always
visible named a place you were not. The house is still the link home, with that
name as its tooltip; the text beside it is where you ARE, and on a board that is
the board's title. models/lib/pageTitles.js maps a route to a title key, which
is one answer to "what is this page called" in place of the thirteen `h1`s that
each answer it separately. A board title is printed as TEXT and a page title
goes through the translator: a board called "settings" is not the Admin Panel.
ONE HAMBURGER, in this bar, to the right of the username, with the divider that
came with it. It was the last item of the SECOND bar - the bar whose contents
are moving into the sidebar it opens. On a board it toggles the board's own
sidebar; on every other page the shared one.
Two guards had to be corrected, and both were wrong before this change rather
than because of it. The theme-accent guard derived each theme's accent by
matching `.board-color-X#header`, which also matches `#header-quick-access`, so
for clearblue it had recorded the quick-access shade (#2d8ce7) as the accent
instead of the main bar's (#00aecc); it matches `#header` exactly now. And the
new guard first checked that the two bars share a selector LIST, which is a
spelling rather than the property - it compares the colours they resolve to.
What is NOT in this commit: emptying each page's second header bar into a right
sidebar. That is thirteen templates and a shared page sidebar for the pages that
have none, and it is the next step.
Thanks to xet7 !
The theme class was on the `.sidebar` element itself. Every themed sidebar rule
is a DESCENDANT selector -
.board-color-belize .sidebar .sidebar-content .sidebar-btn { ... }
- so a class on that same element matches nothing at all, and the panel stayed
exactly as it was: white icons and white text on a light grey background. On a
board the class sits on a CONTAINER around the sidebar, which is what makes
those rules apply, and that is what was missing here.
.all-boards-sidebar-theme is that container. It wraps only the sidebar, so the
theme cannot bleed into the board icons behind it, and it is out of flow - the
sidebar inside is fixed - so it costs no layout. Boards in Archive, and every
other .sidebar-btn in the panel, now gets the themed background with its white
icon and text on top of it, and the list rows get the themed hover.
The guard passed on the broken version, which is why it shipped: it asked
whether the theme class was somewhere in the file, not whether it was on an
ancestor of the sidebar. It now asserts both halves - that the sidebar element
does NOT carry it, and that a wrapper containing the sidebar does. Verified it
fails on the markup as it was.
Thanks to xet7 !
It was Modal.open('archivedBoards'), from three different menus, so the one
place that lists every archived board - with its own search and its own pager -
was a box floating over whatever you happened to be looking at. It had no
address, so it could not be linked to a colleague, bookmarked or opened in a
second tab; there was nothing to come back to; and Escape closed it while you
were reading it. "Restore the board I archived last month" is a task, not a
glance.
/archive is a page now, in the default layout, with the same second top header
bar as every other page and the board session state cleared the way the other
non-board pages clear it. The template is the same one the modal used, minus its
own h2: a modal has no header bar to be named in, so it drew its own title, and
on a page that is the title printed twice. archivedBoardsHeaderBar names it
once, where every other page is named. The search, the per-board Restore and
Delete, and the SERVER-side paging all survive the move - the subscription still
publishes one page at a time, so a long archive stays fast.
All four entry points go to it by route NAME rather than by a path spelled out
in four places: the board menu, the member menu, the board sidebar, and the All
Boards sidebar.
That fourth one did not work at all. The row was drawn in the All Boards
sidebar's home view, and clicking it did nothing: the handler it relied on lived
in the header bar's events map and went when that map was rewritten for the
sidebar. A Blaze event map only sees events inside its own template, and the
button had moved out of it. It has its own handler now, and the sidebar closes
behind it - the page it opens replaces the page the panel belongs to.
Written down in docs/Design/Page/Archive.md.
Thanks to xet7 !
Three things xet7 reported with a screenshot, all of them mine, all of them in
the shell the sidebar borrows from a board.
It was WHITE TEXT ON LIGHT GREY. .sidebar .sidebar-content .sidebar-btn is a
light grey box whose text is white; what makes that readable on a board is a
.board-color-* ancestor replacing the grey with a themed colour. This page has
no board, so nothing did. The shell carries board-color-belize now, the
established default for a themed thing outside a board - globalSearch.js falls
back to the same one. It is a class on the element, so the theme is the same on
a phone and on a desktop; only the geometry below is desktop-only.
It FLOATED OVER THE BOARD ICONS, starting halfway down the page and ending as
soon as its content did. It had inherited position: absolute, which resolves
against the nearest positioned ancestor: on a board that is the board container,
which already starts below the header and runs to the bottom of the window, and
this page has no such container. It is pinned to the viewport now - top is
var(--wekan-header-height), the height the header MEASURES itself to be (it is
not a constant: its buttons wrap to one, two or three rows depending on language
and window width, and utils.js keeps the variable current with a ResizeObserver),
and bottom is the window. Below the second top header bar, full height, like the
board's.
And the boards now move LEFT instead of being covered:
.all-boards-wrapper.sidebar-open .boards-layout gives the panel its 420px back -
the width the sidebar is - so the icons reflow into what is left between the menu
and the panel and every one stays visible.
Desktop only, both of those. On a phone .board-sidebar.sidebar in the board
sidebar's own stylesheet already pins this element - it carries that class - to
the full screen width below the header, and there is nothing to move aside from
a full-width panel.
All three views share the shell, so Search and the hamburger's home menu are
fixed by the same change, not only Multi-Selection.
Thanks to xet7 !
v10.53 built the amd64 snap, the arm64 snap and both variant snaps - forty
minutes of runner time across four jobs - and then every one of them died at
the upload with the same red X, because the credential was not usable. Nothing
before that point had asked the store anything: the per-job check only tested
that the secret is non-empty and longer than 100 characters, which a revoked or
long-expired credential also is.
snapcraft whoami is the question, asked once, in a job that snap-native,
snap-launchpad and snap-variants all wait for. It costs about a runner-minute,
it answers from the store itself, and its answer distinguishes the causes that
a failure at upload time cannot:
cannot be parsed the secret is not an exported login at all - mangled,
truncated, or the terminal OUTPUT of export-login instead
of the file it wrote. The store was never asked.
expired it WAS valid. An exported login lasts one year by default,
so a credential that worked for a year stops without
anything having changed. This is the cause the upload-time
message never mentioned, and the likeliest one when every
arch fails identically.
401 / 403 readable, but without the ACL for this snap name.
It also checks the credential covers all three snap names this release
publishes. One exported for `wekan` alone lets snap-native succeed and
snap-variants fail, which reads as two unrelated bugs; `packages: no
restrictions` covers everything and passes.
The credential is never echoed - only what the store said about it. The whoami
call runs with `set +e` on purpose: `set -e` would kill the step at the failure,
before the case statement that says which failure it was.
build-sandstorm publishes no snap, so it does NOT wait for this - the first
version of the change made it wait, because it happened to have the same needs
line.
Thanks to xet7 !
Two entries for the two commits that gave every left-menu entry an address:
the Admin Panel's /settings/visibility, /people/roles, /admin-reports/cpu, and
All Boards' /allboards/starred and /allboards/workspaces/<name>/<sub-name>.
Thanks to xet7 !
The page was three addresses - / (Starred), /templates and /remaining - and the
workspaces tree had none at all. Which workspace you had open was a ReactiveVar,
so a workspace could not be linked to a colleague, bookmarked, opened in a
second tab or reached with the back button.
/allboards/starred
/allboards/templates
/allboards/remaining
/allboards/workspaces
/allboards/workspaces/engineering/front-end/design-system
The route is '/allboards/:section?/:path*'. :path* is zero or more SEGMENTS -
[^/]+ would stop at the first slash and a workspace two levels down would not
resolve - so a workspace nests as deep as its tree does. / stays the home and
still shows Starred; /templates and /remaining redirect to the new form.
A workspace is addressed by the slugs of its NAMES down the tree, not by its id:
the id is a random string and a URL should say where you are. The slugs come
from getSlug (limax), the same function that gives a board its slug in
models/boards.js, so a workspace and a board turn a name into a URL the same
way, including the scripts where a naive slugifier returns an empty string. When
a name slugifies to nothing anyway - an emoji-only name - the node's id stands
in, because a workspace with no address could not be opened from a link.
The route resolves the section and splits the wildcard; the PAGE resolves the
workspace, in an autorun, once its tree has loaded. The router cannot: the tree
is on the user document, which it has no way to read before the page has it. And
it has to be an autorun rather than a one-shot read, which would always run
before the tree arrived and never select anything. A slug path that names
nothing leaves the Workspaces section selected rather than an empty list.
models/lib/allBoardsUrls.js takes slugify as an ARGUMENT rather than importing
it, so it has no dependencies at all and is unit-tested with a stub - and with
the real limax, for the tests that are about the real one.
One thing this had to fix rather than add: boardsList.js filters boards by
membership only on the All Boards routes, by route NAME, and a route missing
from that list falls through to the public-boards branch - the page would have
shown public boards instead of the user's own. The new name is in the list, and
the guard pins all four.
Written down in docs/Design/Page/All-Boards-URLs.md.
Thanks to xet7 !
The panel was four addresses - /setting, /people, /admin-reports, /attachments -
each opening whichever pane its page happened to open first. Which pane you were
looking at was ReactiveVar state and nothing else, so a pane could not be linked
to a colleague, bookmarked, opened in a second tab or reached with the back
button, and /setting always landed on Version even if you had just been in
Global Webhooks.
Every entry has its own now: /settings/visibility, /settings/global-webhooks,
/people/roles, /admin-reports/cpu, /attachments/s3. Lowercase, words separated
by -, and the DEFAULT pane keeps the bare page URL - /settings, not
/settings/version - so there is one address for "the Settings page" rather than
two that show the same thing. The Settings path is plural: /setting was the odd
one out beside /people, /attachments and /admin-reports, and it still resolves,
as a redirect.
The slug is NOT derived from the pane id. The ids are internal and read like it
- tableVisibilityMode-setting, layout-setting, report-cpu - while a URL is
something a person types and pastes into a chat, and a name derived from another
name is wrong the moment the two spellings differ, which is what
allBoardsMultiselectionSidebar was. So models/lib/adminUrls.js is an explicit
map, and the guard checks it against the real menus in BOTH directions: every
slug names a pane the page has, and every menu entry has a slug. Neither failure
shows up until somebody clicks that row. A slug that is not one falls back to
the page's default rather than rendering an empty panel, because a URL is typed.
The route resolves the slug and hands the pane id to the page, which reads it in
an autorun - reactive, not a one-shot read, because following a link to another
pane while the page is open runs the route action again WITHOUT re-creating the
template. A menu click does the same in reverse: open the pane, then go to its
URL. go, not replace, so Back returns to the previous pane instead of leaving
the Admin Panel, and only when the path would actually change. Each page now has
ONE function that opens a pane by id, used by both the URL and the click.
/information and /translation redirected to /setting and handed their pane over
in a Session value the page consumed once. They redirect to the pane's own
address now.
Two guards pinned that Session mechanism and now pin the URLs, each saying why
it changed. Writing the map turned up that the Settings page's pane list still
named registration-setting, the Login pane that moved to People - which its own
guard caught, correctly.
Written down in docs/Design/Page/Admin-Panel-URLs.md, with every URL listed.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. All 27 links in the Upcoming section resolve.
Thanks to xet7 !
All Boards had a search FIELD in its header bar, and a Multi-Selection button
whose actions were four icons beside it. A board has a search BUTTON and a
Multi-Selection button, and both open the right sidebar. Two pages, the same two
control names in the same place, behaving differently - and one of them not the
way the rest of WeKan does. They are the board's now, and they are the same
markup: headerBarControls.jade holds one headerSearchButton and one
headerMultiSelectionButton, included by the board header of the Swimlanes view
and by the All Boards bar. The two copies had already drifted - the close button
that turns Multi-Selection off said "Clear filter" on the board header, which is
what a different control does, and says multi-selection-off in both now.
Only the markup is shared. What a click does is not - a board searches and
selects cards, All Boards searches and selects boards - and it does not need to
be: a Blaze event map catches events from the templates rendered inside it, so
each bar's own map sees the clicks on its own copy. isActive is passed in,
because the two pages keep different selection objects.
All Boards has a right sidebar of its own. Not the board one: that is built
around a board's members, labels, activities and settings, and this page has no
board. It borrows the SHELL - the same .board-sidebar.sidebar classes, the same
close button, the same title-and-back-arrow above a view - so the two look and
behave alike, and it has three views. home, what the hamburger opens, is the
page's menu: Search, Multi-Selection, and Boards in Archive, which had a handler
in the header bar and no way to reach it. search is the field that was in the
bar, still writing the page's own search term so the boards behind it narrow as
you type. multiselection is where the actions on a selection went - star, home,
archive, duplicate and a way out - each with its name beside it instead of being
a crowded icon. Open/closed and which view are separate, so closing does not
forget where you were, and Escape closes it by KEY only: the click half of
EscapeActions would close it on every click, including clicks inside it.
The bar also gained the divider and the hamburger, in their own flex item and
last in the source exactly as the board header has them, which is what keeps the
hamburger in the top right on a phone while the other buttons wrap.
Two things this turned up. A .jade file is not picked up by being on disk - it
has to be imported from client/features/, and the shared controls threw "No such
template: headerSearchButton" on render until they were; a guard now requires
every .jade under client/components to be imported and every +template it
includes to exist, and it found a dangling +subtaskDeleteDialog that has never
had a template (unreachable, so it has never thrown, and it is recorded with
that reason rather than hidden). And deriving a template name from a view name
gave allBoardsMultiselectionSidebar for allBoardsMultiSelectionSidebar - one
letter, renders nothing, no error worth the name - so the names are an explicit
map the guard checks.
Written down in docs/Design/Page/Search.md and Multi-Selection.md, one per
shared control, each covering both pages, with All-Boards.md pointing at them.
Four guards pinned the previous shape and now pin this one, each saying why it
changed: the search field in the bar, the four selection buttons in the bar, the
Multi-Selection parity check that is structural now that there is one template,
and the home-board action that moved to the sidebar.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. All 26 links in the Upcoming section resolve.
Thanks to xet7 !
The "Selected: star" button only ever ADDED stars: it walked the selection and
starred whatever was not starred yet. Once every selected board was starred it
did nothing at all, so there was no way to undo from here what it had just
done, and its tooltip read "Star the selected boards" whatever state the
selection was in. It is a toggle now - none starred stars them all, all starred
unstars them all, and a mixed selection stars the rest, leaving the starred
alone. The mixed case deliberately does not flip each board independently: one
click that starred some boards and un-starred others is not something a button
may do. Only the boards that must change are called, because toggleBoardStar
flips one board and calling it for an already-starred one would un-star it.
The tooltip says which way the button goes right now, set-selected-starred or
the new set-selected-unstarred, and it reads the SAME function the click does -
two copies of "which way does this button go" would eventually be two answers,
and the tooltip would lie about what the click does. The rule itself is
models/lib/selectedStars.js: pure, so it is unit-tested rather than reasoned
about, including the mixed case and an empty or junk selection.
All four buttons on a selection are icon-only now, and they follow the
"Selected:" label in the order star, home, archive, duplicate - the two that
only mark a board first, the two that change what boards exist last. Archive
and duplicate carried their names, which are sentences and pushed the bar onto
a second row.
Checking that each button says what it is turned up one that did not: the close
button that turns Multi-Selection off said "Clear filter", which is what the
OTHER one in this bar does, in the search box. It is multi-selection-off now. A
guard requires every .board-header-btn in the bar to carry a title, and every
title to come out of a translation key rather than being literal English.
Both new keys are in all 147 language files as English placeholders, which is
what the translation policy does with a string untranslated everywhere, so no
language silently loses a tooltip. The seven language files that are symlinks
share their target's copy rather than getting a second one, and the 43 files
that have no trailing newline still have none.
The Font Awesome guard flagged a character in a jade COMMENT, which renders
nothing - the same exemption it already makes for arrows and box drawing. It
skips comment blocks now, tracked by indentation so a continuation line is
skipped too, with a self-check that a rendered line is still caught.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. All 25 links in the Upcoming section resolve.
Thanks to xet7 !
Starred was the first button in the header bar, and Starred is a section: the
left menu already lists it beside Templates and Remaining, counts it, and
highlights it when it is the one shown. A second way to reach one section, one
click away from the first, is a control whose only job is to be kept in step
with the menu - so it is gone, and with it the header bar's own js-select-menu
handler and isSelectedMenu helper, which had no other caller there. The left
menu is part of boardList and has always had its own.
Multi-Selection moved to the right of the Lists/Table menu. The bar now reads
left to right as what is shown - Sort, Search, Lists/Table - and then what is
selected: Multi-Selection, followed by the archive, duplicate, star and home
actions that appear with it.
The search box is 150px wide, half of the 300px it was drawn at when it had a
card of its own. Getting there turned up that it had no styling at all: its
rules said .boards-path-header .board-search, the bar it used to live in, so
from the moment the controls moved to the header bar they matched nothing and
the box rendered at the browser's default input size. They are
.all-boards-controls now - and because a white box on a themed bar cannot
inherit that bar's light-on-dark colour without putting white text in a white
box, the input, the magnifier and the clear button each set their own.
The two guards that pinned the old order now pin this one and say why. Both of
them, and the removed-bar guard beside them, had started reading the comments
of the rules they were checking - the new rules explain themselves by naming
the selector they replaced - so they strip comments before asserting.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. All 24 links in the Upcoming section resolve.
Thanks to xet7 !
Once every control had moved to the header bar, what was left above "+ Add
Board" was a white strip carrying one thing: a Font Awesome icon for whichever
left-menu section is selected. Three things already say which section that is -
the left menu highlights it, the header bar names the page, and the Starred
control is emphasised while Starred is on - so the strip said nothing and cost
a bar's worth of height on every screen. The board icons start at the top of
the right column now.
It took more with it than the markup. currentMenuPath, sixty-four lines that
resolved a workspace path to an icon and a name, had no other caller. Every
.boards-path-header rule went - the seventeen that styled the bar and its
contents, and the phone media query that had already been reduced to holding
the title. So did the pulse keyframes, whose only user was the multi-selection
hint that lived in the bar. The pager's flex: 0 0 auto was sharing a selector
list with the bar, and is kept on its own: it is still the fixed-height thing
above the scrolling list. Verified the stylesheet's braces still balance and
that it has no empty at-rule left.
Two guards named the bar and now assert it is gone, each saying why: the
scroll-chain guard asked which element above the list keeps its own height,
and the tile-height guard asked whether the bar wraps.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. All 23 links in the Upcoming section resolve.
Thanks to xet7 !
"Install WeKan dependencies" ran brew install node@24, which gives whatever
24.x Homebrew currently has bottled rather than what nodejs.org has released,
and which is keg-only - so the branch also wrote PATH, LDFLAGS and CPPFLAGS for
it into ~/.zshrc by hand. It is nvm install 24 now: the major alone, so it
resolves to the newest 24.x every time it runs and never needs bumping, and nvm
puts it on PATH itself. npm comes with the Node it installs, so brew install
npm is gone too.
The nvm installer is fetched from a pinned release tag rather than master,
because the line pipes a downloaded script into a shell, and nvm.sh is sourced
before the first nvm call - nvm is a shell function, not a binary, so without
that every call is "command not found" even straight after a successful
install. An NVM_DIR the caller has already set is honoured, and a failed
install is reported instead of run into.
Two things the old branch did are now actively undone. npm config set prefix
'~/.npm' cannot coexist with nvm: it overrides the per-version prefix, global
installs land outside the Node they were installed for, and nvm refuses to
switch versions while it is set - so the branch clears it, which a machine that
ran the Homebrew path needs. And that prefix directory was created with a
quoted tilde, mkdir "~/.npm", which makes a directory literally named ~ in
whatever directory build.sh was run from.
Linux is untouched and still installs Node with n, which the new guard pins so
the split stays deliberate. Verified the guard fails on the branch as it was -
seven of its nine tests - and passes on this one, and that build.sh still
parses.
Thanks to xet7 !
The entry was written before the commit it describes existed, so the amend
made its placeholder stale. fix-changelog-hashes.sh found the rewritten copy
by subject and author date. All 22 links in the Upcoming section resolve.
Thanks to xet7 !
The header bar took the controls of the page, but the actions ON a selection -
Move Board to Archive, Duplicate Board, and the "Selected:" star and home -
were left where they were, in a strip above the board icons, on the reasoning
that they are about those boards rather than about the page. That still left
two places to look for a button. They are in the header bar now, to the right
of the controls that are always there, as .board-header-btn like every control
beside them, and .boards-path-header holds the section title and nothing else.
They appear only while something is selected: four buttons that would do
nothing are worse than no buttons. Archive and duplicate carry their names;
star and home stay icon-only under the "Selected:" label that already named
them, because their names are sentences - "Set as Home board (opened after
login)" - that belong in a tooltip, and spelling them out pushes the bar onto
a second row. The label stays a label, with neither the button class nor any
button behaviour.
Two things had to move with the buttons, because Blaze binds both to a single
template: their four click handlers, which an event map on boardList could no
longer see, and hasBoardsSelected, which decides whether they are drawn. The
stylesheet lost .path-right, .selected-action and .selected-actions, which now
select nothing, and the phone media query lost the four rules that flattened a
controls row this page no longer has.
Two guards pinned the previous decision and now pin this one, each saying why
it changed: the All Boards guard asserted the selection actions stay beside
the boards, and the tile-height guard asserted that .path-right wraps - which
the header bar's own button group does instead.
Thanks to xet7 !
The entry was written before the commit it describes existed, so it carried a
placeholder that the amend then made stale.
fix-changelog-hashes.sh found the rewritten copy by subject and author date.
All 21 links in the Upcoming section resolve.
Thanks to xet7 !
The page chooses between the board icons and the Table view with
{{#if isAllBoardsView 'table'}}, and that helper was registered on
boardListHeaderBar and on allBoardsViewPopup but not on boardList - the
template that actually asks. A Blaze helper belongs to the template it is
registered on, so the page threw as soon as the router rendered it, right
after login, and All Boards did not come up at all.
The guard did not notice because it read the jade and the JavaScript as two
separate files: it checked that the controls are in the header bar and that
the Table branch calls +tablePage, never that the template asking a question
has the helper that answers it. It now collects every helper this file
registers, and for each template in the jade every helper it uses that this
file defines must be registered on THAT template. Only helpers the file itself
defines are checked - a name it registers nowhere is a model helper on the
data context, like colorClass on a board, and a guard cannot tell one of those
from a typo. The other four templates in the file were clean.
Verified the new test fails on the code as it was and passes on the fix.
Thanks to xet7 !
Updated dependencies. was the twentieth commit since v10.53 and the only one
without a Changelog entry: @meteorjs/rspack 2.0.1 -> 2.1.0-beta.0, the bundler
half of the Meteor 3.5.1-beta.0 upgrade beside it. Its rimraf 6 brings glob 13,
which no longer ships a command line, so twenty-seven packages leave the
lockfile with it - 975 to 948 - and nothing is dropped from WeKan itself.
Checked the whole Upcoming section against the rules in CLAUDE.md: one summary
was 115 characters against the 110 it aims for, and is shorter now. Everything
else holds - one # heading, 80-column wrap outside links, every summary on one
line with its own commit link and no markup in it, no hash or URL as link
text, blank lines around every block, the subsections reading as one sentence,
and the closing Thanks to above GitHub users line. All twenty commit links
resolve in this clone.
Thanks to xet7 !
The Upcoming section listed twelve of the nineteen commits made since v10.53,
and put eight of them under "and documents the following:", which described
one of them. It is now the order CLAUDE.md asks for - new features, the user
interface, dependencies, bug fixes, documentation, translations - and it holds
the seven that were missing: the All Boards header bar and Table view, the two
fixes that followed the Public Boards page, the Roles Status translations, the
newest Transifex pull, Meteor 3.5.1-beta.0 and the meteor-node-stubs fork. The
section ends with the "Thanks to above GitHub users" line it was missing.
All nineteen commit links resolve in this clone.
Thanks to xet7 !
Design: docs/Design/Page/All-Boards.md, whose Table view is the shared table page
(docs/Design/Page/Table.md) and which describes only what is different here.
ONE ROW OF CONTROLS. The page carried its own row above the board icons -
Multi-Selection with its archive and duplicate actions, Sort, the search box - in
.boards-path-header, while the second top header bar above it held only the title.
Two rows of controls on one page, one of them styled like the board header of the
Swimlanes view and one not. Starred, Sort, Search, Multi-Selection and the view
menu are in the header bar now, as .board-header-btn with the same Font Awesome
glyphs and the same emphasis state, so this page agrees with every other page
about where a WeKan page puts its controls.
The actions ON a selection stayed with the boards: Archive, Duplicate and the
"Selected:" star/home actions appear only while something is selected and are
about those rows, not about the page.
SEARCH IS A FIELD, not a button that opens a search view. It filters as you type,
searches across all your boards ignoring the selected section while it has text,
and Escape clears it - the old right-pane behaviour exactly. That is a deliberate
difference from the board header, whose Search opens a search view over cards;
here it filters the list it sits above.
THE VIEW MENU names the CURRENT view - "Lists" or "Table" - not the words "Board
View", the same as the board header, which says "Swimlanes" or "Lists" rather
than naming the menu. Lists is the default and is what an account that has never
chosen sees. The choice is kept in localStorage rather than on the user document:
it is a view preference for one page and changes nothing anybody else can see. A
board's view IS on the profile, because it follows the user between devices; this
deliberately does not.
THE TABLE VIEW is the shared table page, editable - which is what separates it
from the other board table, /public, which is read-only. Columns: Edit, Board
title, Board description. Ten rows a page.
Edit opens the SAME popup the Swimlanes view opens from its board menu, not a
copy of it. That took one change: boardChangeTitlePopup's submit read
Utils.getCurrentBoard(), which is the board you are looking at - and on All Boards
you are not looking at one. It takes the board from its own data context when it
has one and falls back to the current board, so the board header is unchanged.
TWO THINGS THE REFACTOR NEEDED.
The state had to be shared. boardListHeaderBar and boardList are separate Blaze
instances - the bar is rendered into the layout's headerBar region, the page into
its content region - so the search field would have filtered nothing. The search
term and the selected section are module-level ReactiveVars now, assigned onto the
page instance so every `tpl.boardSearchVar.get()` already written keeps working.
And "which boards am I looking at" had to stay one answer: the `boards` helper's
body is `boardsForView(tpl)` now, called by both views, because two copies of a
membership + section + search + sort + paging query would drift.
The view module is split in two for the same reason the others are: which views
exist and which is the default is pure (models/lib/allBoardsView.js) and unit
tested; the ReactiveVars and localStorage are Meteor glue and cannot be loaded in
a plain Node test.
The guard in tests/addBoardTileHeight.test.cjs pinned the ORDER of the three
controls inside .path-right. That row is gone on purpose, so the guard now pins
the order where the controls are - and that the page body does not also carry
them, which is the thing that was wrong.
Thanks to xet7 !
The row carried the board's colour CLASS, but nothing in boardColors.css matches
it: every board colour there is written for `.board-list .board-color-X a` - an
anchor inside the All Boards list - and a table row is neither. So the background
never arrived, while publicBoards.css forced `color: #fff` on top of it. White on
white; only the emoji in a title was visible.
Two fixes, and the second is the one that actually mattered.
The colours now reach the row: `.public-board-row.board-color-X` is added to each
of the seventeen existing selector lists in boardColors.css - the same
declaration, one more selector - so the rows follow the board colours and the
theme without a single hex value being repeated in the new stylesheet. The test
counts both lists and fails if a colour reaches the All Boards tile but not the
row.
And a board with NO colour matches none of those rules however they are written,
so the row needs a default background of its own. That is the case that was
reported: without it the row keeps the table's white background and the light
text vanishes. The All Boards tile has the same problem and answers it the same
way - `.board-list-item` falls back to grey so its white text always has
something to sit on - so the row does that too, and the text is the tile's own
#f6f6f6 rather than a hardcoded white.
The route renders `boardListHeaderBar`, whose h1 already says "Public", and the
pane then supplied `titleKey: 'public-boards'` to the shared table page - so
"Public boards" appeared again directly underneath it.
The shared table page prints a title only when it is GIVEN one, for exactly this
reason: docs/Design/Page/Table.md says so in the template itself, and it is why
the Admin Panel panes supply none either - their heading comes from the active
left menu entry. This page had a heading too and asked for a second.
The test now pins it, and reads the LAST `return` of the helper: the earlier one
is the per-board row object, which legitimately has a `title` of its own - the
first version of the guard matched that and failed on the fix.
The eleven new keys of the Admin Panel / People / Roles pane, written directly -
by the assistant, from each language's own existing translations and general
kanban terminology - which is what CLAUDE.md's translation policy asks for. No
external translation service, API or key is involved, and nothing here is pushed
to Transifex: a filled string must never be able to masquerade as a human one.
Applied through releases/translations/fill-translations.mjs --apply, so the fill
can only ever write into a placeholder. It reported the same thing for nearly
every language - "filled 10, skipped 1 existing human translation" - because
'roles-status-comment' already had a real translation in most files, and the tool
refused to touch it. That is the guarantee working, not a rounding error.
The terms come from each language's own file rather than from English: the word
for a board differs everywhere (Tableau, Tablero, Quadro, Bacheca, Tavla, Taulu,
Tablica, Доска, Pano, Nástenka, 看板, ボード, לוח), and so does 'settings' and
'comment'. Several files are contaminated with other languages - the Greek file
has French and Italian values, the Korean has Japanese, the Thai has Vietnamese -
so those anchors were NOT copied; the strings were written in the actual target
language.
111 of the 142 non-English language files are done. THIRTY-ONE ARE NOT, and are
left as English placeholders on purpose: ace, ary, ast-ES, br, gu-IN, ig, oc,
or_IN, pa, ta, te-IN, tk_TM, tlh, ug, ve, ve-CC, ve-PP, vl-SS, vo, wa, wa-RR, wo,
wuu-Hans, xh, yi, yo, yue_CN, zgh, zh-GB, zu, zu-ZA. A wrong translation of a
permissions table is worse than an English one an admin can still read, and the
policy is explicit that the English source stays when there is no translation.
Regional variants take their base language's text (de-AT/de-CH/de_DE from de, the
eight Spanish variants from es, and so on), and the German wording avoids ß so
de-CH is correct as it stands.
Only the eleven keys changed, in 104 files: the diff touches no other key, key
ORDER still matches en.i18n.json everywhere, and the 43 files with pre-existing
formatting quirks are all files this did not touch.
releases/translations/verify-human-preference.mjs still passes 10/10.
docs/Design/Page/Public.md is the design; it describes only what is different
about this page and links back to docs/Design/Page/Table.md for everything shared,
which is that page's own rule.
WHAT IT WAS. /public rendered `boardList` - the All Boards page - with its query
swapped for `{ permission: 'public' }`. That brought the whole of All Boards with
it: the Starred / Templates / Remaining menu counting the user's OWN boards beside
a grid that was not, the workspaces tree, the org and team filters,
Multi-Selection with its archive and duplicate actions, the sort popup, board
dragging, and an "Add board" tile that made a private board from a page about
public ones. Multi-Selection offered to archive boards the visitor has no rights
to at all.
WHAT IT IS. Only the table. Two columns - board title and board description - ten
rows a page, paged and counted on the server. No left menu, no create, no
selection, no drag, and nothing on the page changes anything: a row's only action
is to open its board.
It supplies a rowTemplate rather than a text-cell column spec, because a row is a
LINK and carries its board's colour class and background image - so a board is
recognised here the way it is on All Boards (#5157) - and a text cell can express
neither. Read-only is about what the page can CHANGE: the row template renders one
anchor and no control.
WHAT A PAGE COSTS. Six fields for ten boards, not ten board documents: title and
description for the columns, slug for the link, color and backgroundImageURL for
the row. `members` is deliberately absent - it is the largest field on a busy
board and this page shows no avatars. The selector is built on the SERVER and
takes nothing from the client: public, not archived, a real board rather than a
template container, and not an internal ^Subtasks^ board. A search goes in as its
own $and term rather than replacing the title clause, or it would drop that last
exclusion.
Not carried over from the tile: member avatars, the per-list card counts, and the
spent-time clock. What a visitor needs of a board they do not belong to is what it
is called and what it is for; the rest is the inside of a board they have not
opened, and each costs a query the page would otherwise not make - the clock in
particular answers by looking for cards, which this page does not publish, so it
would read false for every board on every instance.
client/lib/reportPages.js now declares the DDP-only page-index collection, because
`new Mongo.Collection(name)` throws if the name is taken and it was declared
inside adminReports.js - so the second page to need it could not have one. The
guard in tests/adminPageRows.test.cjs that pinned that declaration is updated with
the reason: what it protects (declared once, from the shared constant, never a
typed string) is unchanged, it just lives in a different file.
tests/publicBoardsPage.test.cjs pins the route, that none of the All Boards chrome
is on the page, that a row carries no control, the two columns and one cell each,
that the labels are translation keys that exist, that paging is ten a page on the
server and the rows drawn are the ids the server named, exactly which six fields
the publication sends, that the selector is server-built and survives a search,
the row colouring, the shared collection, that the files are registered in the
bundle, and that every path the design doc names exists.
Thanks to xet7 !
The pull rebased the 14 local commits onto the released v10.53, so every commit
link written in the Upcoming section pointed at a hash that no longer exists.
releases/fix-changelog-hashes.sh followed all 11 by subject and repointed them;
only Upcoming is touched, and the released sections are pushed history.
WeKan creates boards of its own to hold machinery - a subtasks board, for one.
They are real boards and the user "owns" them, but nobody chose to make one and
nobody means to open one, so no list of boards shows them (#5582). They are
recognised by their title being wrapped in carets: `^Subtasks^`.
The selector for that was typed out at each list - five copies of the same
`{ $not: { $regex: /^\^.*\^$/ } }` - and the sixth place forgot it. /public
built its own query and listed every public subtasks board on the instance beside
the real ones.
models/lib/helperBoards.js is that selector now, once, and every list uses it -
the four in boardsList.js, userBoards in models/boards.js, and /public, which
gains it. A FUNCTION rather than a shared constant: Mongo selectors get merged and
mutated by their callers, and a shared object would carry one caller's edit into
the next list.
The test fails if a copy of the pattern comes back anywhere, if a board list stops
using the helper, or if /public in particular does - and pins what the pattern
does and does not match, so a board somebody really named "Subtasks" is never
hidden.
Thanks to xet7 !
The board scope came from Boards.userBoards, whose $or lists the ways a user
reaches a board - member, organization, team, e-mail domain - and
`{ permission: 'public' }`. That last one is the odd one out: it is not a
relationship to the user at all, it is "anybody may open this".
That belongs in the boards LIST, where a public board is meant to be
discoverable. In a search it meant every public board on the instance was
searched: on a public server a common word answered with strangers' cards, and
following a hit dropped the user into a board they have no part in. Someone who
wants to look inside a public board can still open it and search there.
`includePublic` is an option on userBoards / userBoardIds, defaulting to TRUE so
every existing caller - the boards list, the lists and comments lookups - is
unchanged. The search publication names it once as SEARCH_BOARD_SCOPE and passes
it to all four board lookups plus the `board:` filter's name resolution: one
missed lookup and that branch of the search still reaches the whole instance,
with nothing looking wrong.
Boards.userSearch takes the same option, because it is what resolves `board:name`
- left unscoped it would name a public board the search itself can return nothing
from, which is a filter that silently empties the results. With public boards
excluded an anonymous caller can reach nothing at all, and an empty $or means
"match nothing" in Mongo but is an error in some backends, so that case is
answered directly instead of being sent to the database.
Only the four real relationships stay unconditional; the test fails if any of them
becomes optional, if a board lookup in the search loses the scope, or if
models/boards.js ever switches public boards off for everybody.
Thanks to xet7 !
It scaled the board with a CSS transform, it did not work, and there is no plan to
fix it - WeKan already has a font-size setting (Member Settings / Change Font),
which is what the control was reached for anyway. A control that does nothing is
worse than no control, so it is gone rather than hidden.
What went with it: the pill and its number in the header, the helper and the three
handlers behind it, Utils.getZoomLevel / setZoomLevel / applyZoomLevel and their
three call sites, the `profile.zoomLevel` schema field, its entry in the published
user fields, the model setter and the server method, the `click-to-change-zoom`
translation string, and 57 stylesheet rules spread over four files - header.css,
layouts.css, boardHeader.css and boardsList.css - which is how much of the
stylesheet a broken feature had accumulated.
The card zoom is a DIFFERENT feature and is untouched: getCardZoom / setCardZoom /
applyCardZoom and the +/- buttons in the card header still work.
Three tests existed only to constrain the pill, and each is handled on its own
terms rather than deleted to make the run green:
* uiDensity's "zoom pill fits inside the 28px quick-access row" has nothing left
to measure; it is replaced by a guard that the pill has not come back into any
of the four stylesheets that carried it - it was spread widely enough that a
partial revival is a real risk.
* mobileAllBoardsFit's "the quick-access bar gives way" capped the zoom input at
50px of a 375px phone. The rest of that test - notifications and the user bar
never shrink, because they are what the user came for - is untouched, and the
zoom half is now the same "it has not come back" assertion.
* mobileAllBoardsFit's "the zoom number stays INSIDE its white pill" was a real
bug once (the pill shrank below its contents and the number ended up beside it
in 8px type under the notification bell). There is nothing left to lay out, so
it is removed with a note saying what it used to protect and where the
replacement guard is.
Thanks to xet7 !
The swatch list is shared with the board-BACKGROUND picker, where it is a
float-based TWO-column grid (boardsList.css: float: inline-start; width: 50%).
Two columns is right for background thumbnails; for the Select Color picker it
meant Flat, Clear, Dark and Special each ran down the popup in a narrow pair, and
most of them were below the fold however wide the browser was.
Auto-filling columns instead - the same answer the Change Language popup already
uses, for the same reason. `repeat(auto-fill, minmax(120px, 1fr))` takes as many
columns as fit and collapses to one on a narrow window, so no media query is
needed and a phone is unaffected. Scoped to .theme-color-picker, so the
board-background picker keeps its pairs; the shared float rules are undone
explicitly inside the grid, because a floated grid item is still floated and
width: 50% would leave every other column half empty.
Width buys columns, so both Change Color popups get more of it on desktop -
Member Settings and Board Settings, which are the two places the picker opens as
a popup. Desktop only: below 800px popup.css lays every popup out as a
full-screen sheet and an !important width would fight that rule and win.
The 720px is in TWO files and has to be, so it is stated in both comments and
checked by the test: client/lib/popupOffset.js clamps a popup into the viewport
using its width, and computed for the default 380px it placed a wide popup opened
near the right edge with a third of itself off the screen - the same class of bug
as #5667, which is what that module exists for. Ordinary popups still clamp
against 380px, which the test also pins.
It said "Apply" while every other settings form in WeKan says Save, and it was
pure black. Both came from one line: the submit carried no `.primary` class, so
it fell to the BASE button rule in forms.css - whose fallback is `#000` - instead
of the primary rule beside it, which is the themed one
(`var(--theme-accent, #005377)`). The Change Language form directly above it in
the same popup uses `input.primary.wide`, which is the shape this now matches.
The test guards both halves on that one line, so a Save that loses its theme, or a
form that goes back to "Apply", fails.
What each role may do was spelled out THREE times - in the server allow helpers,
in the client's canModify* helpers, and in prose in the docs - and the three had
drifted apart. Every place they disagreed was a role that did not do what its name
says. models/lib/boardRoleCapabilities.js is that table now, in code, and
everything reads it: the allow rules, the UI helpers, the new Admin Panel pane and
the documentation. There is nowhere left for a fourth opinion to appear.
THE THREE GAPS, fixed:
* "Comment only, assigned" (isCommentAssignedOnly) had FULL WRITE ACCESS.
Nothing outside the card publications read that flag and it was not in the
write rule, so the role could create and edit cards, lists and checklists - it
was "Normal, assigned only" under another name. It is comment-only now, like
the role it is named after; the two differ only in what they see.
* "No comments" (isNoComments) could not write ANYTHING. The write rule excluded
it, so the role blocked editing as well as commenting - a second read-only
role under a name that says otherwise, and one the UI still offered the edit
buttons for. It blocks commenting only now, which is what the name and the
board schema both say it is for.
* The write rule did not exempt board admins. Every has*() helper on the board
ignores a flag on an admin; that one read the raw flags, so an admin who also
carried isNoComments silently lost write access. Not reachable from the Web
UI, which writes all eight flags at once, but reachable over the REST API,
which takes them individually. memberRoleOf() resolves isAdmin first.
The UI helpers were part of the same drift - canModifyCard() did not exclude
isNoComments while the server did, and canModifyBoard() excluded neither
isNoComments nor isWorker - so each disagreement was a button offered to somebody
whose write the server then refused. All three ask the same table now.
A FOURTH gap found while building the table, NOT fixed: a Worker cannot move a
card, which is the one thing the role is for. Moving a card is a card UPDATE, so
it goes through the write rule, which excludes Worker. The fix is not a table
edit - it means letting a role write SOME fields of a card and not others, and
"assign himself" means validating that a member change only ever adds the caller.
That is a field-level policy on the path every card update takes and wants
deciding on purpose. It is recorded under "Known gaps" with what it would take.
ROLES STATUS, at Admin Panel / People / Roles, below the Save button: a READ-ONLY
table of what each role may do - which cards it sees, and whether it may comment,
create and edit, or change the board's settings. It is the shared table page
(docs/Design/Page/Table.md), so it looks and behaves like every other Admin Panel
table, with no markup of its own; it has no rowTemplate, no actions and no
editable cell, because a role's capabilities are a property of the code and not a
setting. Every string is a translation key, the Yes/No of each cell included - the
values are booleans, and a hard-coded "Yes" would be English in every language.
The "Invite to board" column reads the pane's WORKING copy, so the table follows
the checkboxes above the Save button as they are ticked, before saving, which is
the point of putting it there.
docs/Design/Page/Table.md listed Roles among the panes that do NOT use the shared
design, "so the gap is visible rather than forgotten" - it has a table now, so it
moved to the list of pages that use it, and the exclusion covers the two panes
that are still nothing but a form.
Two guards were checking the shape of the old code rather than what it guaranteed,
and are updated with the reason in the test: listDragPermission read the flag
exclusions out of canModifyBoard's own body (it has none now, so it checks the
BEHAVIOUR - anonymous is falsy, and each excluded role still cannot drag a list),
and tablePage counted the pager handlers file-wide, which also forbade a handler
on a different template - a separate event map is not a duplicate key.
tests/boardRoles.test.cjs is the suite: the module itself including each fixed
gap, that the server rules and the UI helpers ARE the table and name no flag
themselves, that every cell of the documentation matches it, that the
assigned-only column matches the publication scope, that the remaining gap is
still real and the three fixed ones are recorded as fixed, and that the Roles
Status pane renders from the table, is read-only, is the shared template, follows
the working copy, and translates every string it shows.
Thanks to xet7 !
Three entries for the commits that had none: the boardCardsWindow assigned-only
restriction, the board-roles table under docs/Features/Members/, and the
aldeed:collection2 4.2.0 -> 4.2.1 bump as a dependency bullet.
There was no comparison of the roles anywhere. docs/Features/Members/Members.md
listed three of them - Admin, Normal, Comment only - in one line each, and there
are NINE: board admin, normal, no comments, comment only, worker, read only, and
an assigned-only variant of normal, comment-only and read-only. docs/API/Role.md
shows how to set each flag over the API without saying what any of them does.
docs/Features/Members/Roles.md is the table: for every role, which cards it sees,
whether it may comment, create or edit cards, move cards, edit lists and
swimlanes, and change the board's settings and members. It also says WHERE each
column comes from, because the answer is only two helpers -
allowIsBoardMemberWithWriteAccess() and allowIsBoardMemberCommentOnly() in
server/lib/utils.js - plus isBoardAdmin() and, for visibility, the assigned-only
scope in the card publications. The table is what the SERVER allows, because the
server is the authority and the UI can only hide buttons.
VALIDATED FROM THE CODE, and three things do not match their own names. They are
recorded as gaps, not fixed here, because each needs a decision about which side
is wrong:
* "Comment only, assigned" (isCommentAssignedOnly) has FULL WRITE ACCESS.
Nothing outside the card publications ever reads that flag - it is not in
allowIsBoardMemberWithWriteAccess(), where isCommentOnly is - so the member
may create and edit cards, lists and checklists. The role is in practice
"Normal, but only sees the cards assigned to me", which is what
isNormalAssignedOnly already means.
* "No comments" (isNoComments) cannot write ANYTHING. That helper excludes it,
so the role blocks editing as well as commenting - while the schema describes
it as "is the member not allowed to make comments" and the UI's
canModifyCard() does not exclude it, so the member is offered the edit
affordances and the server refuses the write. The name and the schema comment
both point at the helper being the wrong side.
* The write helper does not exempt board admins. Every has*() helper on the
board requires isAdmin: false, so a flag on an admin is ignored, but that one
reads the raw flags. Not reachable from the Web UI, which writes all eight
flags at once and never leaves two set - but reachable over the REST API,
which takes them individually.
A fourth section lists where the UI is more generous than the server, i.e. the
buttons that do nothing: canModifyCard() does not exclude isNoComments, and
canModifyBoard() excludes neither isNoComments nor isWorker. None of these is a
security hole - the server rules hold - but a button that silently fails reads as
a bug to whoever clicks it.
tests/boardRoles.test.cjs keeps the page honest rather than trusting it, which is
the point: a permissions table that quietly goes stale is worse than none, because
it is what an admin decides who to trust with. It parses the table and checks that
every role memberRole() can return has a row and every row names a flag it really
reads, that the "create / edit" and "comment" columns match the flag lists in the
two server helpers, that the "which cards they see" column matches the
assigned-only scope, that only the board-admin row may change settings, that each
gap the table marks is still real AND still explained - so fixing one has to
update the page with it - and that the page is linked from both Members.md and
the API role page.
Thanks to xet7 !
Resolved by the Meteor package resolver; .meteor/versions is the lockfile that
records it. collection2 is what cleans and validates every write against a
collection's SimpleSchema, so it sits on the path of every insert and update
WeKan makes.
Three board-member flags mean the same thing - isReadAssignedOnly,
isNormalAssignedOnly, isCommentAssignedOnly - the member may only see the cards
they are assigned to. The `board` publication has always narrowed its card cursor
with `assignees: { $in: [userId] }` for such a member. `boardCardsWindow`, which
is what ships the cards in LAZY card-loading mode, did not.
So whether the restriction applied at all depended on the board's card-loading
mode. The same member saw only their own cards on a small board and EVERY card in
the window on a big one (or on any board with CARDS_LOADING=lazy) - and with the
cards went their comments, attachments, checklists and checklist items, because
the window's children hang off the same selector.
The restriction is part of the window scope now, and of its COUNT: an
unrestricted `boardListCardCount` still told the member how many cards the list
really holds and offered to scroll in cards that would never arrive.
Two things this had to get right.
The FIELD PROJECTION. publish-composite hands each child the document as the
PARENT cursor published it, and that cursor projected to `{ _id: 1 }` - so
`board.members` was undefined in every child and the restriction would have been
dead code. The parent publishes `members` now, which also makes it reactive:
changing a member's assigned-only flag re-runs the window instead of taking effect
on the next subscribe. The board publication already ships this board's members to
the same client, so nothing new is exposed.
The MERGE. The scope was spread into the client's selector at the top level
because FerretDB v1 (SQLite) does not push a top-level `$and` down to its index -
the wrapped form full-scanned the whole cards table on every poll and cards never
loaded on a big board (10.22). But a top-level spread can only be used when the
two selectors do not both speak for the same key, and the board Filter HAS an
assignee filter, so this collision is reachable from the UI. In the direction the
publication spreads them the client's value would have won and the restriction
would have been silently dropped. The inline `safeCollides` guard covered
boardId/archived only; it is now mergeCardScope in models/lib/boardCardScope.js,
which merges when the keys are disjoint and falls back to `$and` - where BOTH hold
- when they are not. An assigned-only member filtering for someone else now gets
nothing rather than everything, and an unrestricted member keeps the fast path.
tests/boardCardScope.test.cjs covers each of the three flags, an ordinary member,
an INACTIVE assigned-only member document (matching the publication's
isActive: true lookup), a non-member and a logged-out visitor - both deliberately
unrestricted here, because this narrows what a MEMBER sees and board visibility is
decided before it - malformed member arrays, the assignee-filter collision, that
an unrestricted member keeps the top-level merge, that BOTH the window and its
count are narrowed, and that the parent cursor publishes the members its children
read.
Thanks to xet7 !
"If I use any filter, the modal that appears on screen sometimes doesn't
disappear. Ideally, this should close the moment I click anything outside the
modal."
It is the board sidebar showing its filter view, and nothing dismissed it but the
sidebar's own toggle or Escape. The reason is one argument: the document click
handler in client/lib/escapeActions.js runs
`clickExecute(evt.target, 'multiselection')`, and `sidebarView` sits BELOW
`multiselection` in the hierarchy, so `_execute` returns before ever reaching it.
A click could not close the sidebar by design.
The handler lives in the filter template rather than raising that limit, because
raising it would make EVERY sidebar view close on any outside click - Archive,
Settings and Card Settings are panels people work beside on purpose, and only the
filter reads as a thing you open, use and are done with. Escape is untouched: the
existing sidebarView action still returns the sidebar to its default view, and
this change did not have to alter its registration.
Three clicks deliberately do NOT close it. Inside the panel, obviously. A pop-over
the panel opened - the label, member and due-date pickers render outside the
sidebar, so without this, choosing a value in one would close the panel behind it.
And the header button that opens the filter, which would otherwise toggle it shut
in the same gesture that opened it. The handler is also bound on the next tick, so
the opening click - whose flush can still be in flight when the template renders -
cannot reach the handler it just created; a panel destroyed before that tick
clears the timer rather than leaving one behind. It is namespaced and removed by
name in onDestroyed, so it can never outlive the panel and close the sidebar under
some later view.
The sidebar is hidden, not reset: reopening it comes back to the filter you were
using. Escape is the one that returns to the default view, as before.
tests/filterSidebarOutsideClick.test.cjs pins the reason as well as the fix - that
a click really cannot reach sidebarView through EscapeActions, so a later
"simplification" that moves this into escapeActions has to argue with it first -
and each of the three exceptions, the next-tick bind, and that Escape still does
what it did.
Thanks to xet7 !
Two problems from one report with screenshots, both in how a list decides what to
draw at its bottom edge.
1. "ONCE A FILTER IS APPLIED FOR A MEMBER, THE 3 DOTS CONTINUE TO ANIMATE." The
screenshot shows a list with NO cards under the filter and the load-more spinner
still turning under it - and `_updateList` raising the window limit by ten every
idle callback for as long as it stayed on screen.
The spinner asked "does this list hold more cards than the window I asked for?"
and answered it from a total built somewhere else than the cards being drawn. The
cards come from the filtered selector; the total came either from
`list.cards(swimlaneId).length` or, in lazy card-loading mode, from a count
document published per list/swimlane - whose id was `listId::swimlaneId` and did
NOT include the filter. So changing the filter re-subscribed with a new selector
under the SAME document id, two publications wrote one document, and Meteor's
merge box serves whichever subscription it prefers, which during the changeover is
the older, pre-filter one. The list drew its empty filtered window while its count
still described the unfiltered list.
The count document now carries a short stable key for its selector, so each filter
counts into its own document and a count can never describe another filter's
cards. Both subscribers pass it; the two-argument form still returns the old id
for a caller with no selector to hand.
And the spinner no longer depends on that being right. There is nothing more to
fetch unless the window came back FULL: if we asked for twenty cards and got
three, those three are all there are, whatever any count says. That holds in both
card-loading modes and for a stale count in either direction, which is why it is
worth asking as well as the total.
While there: showSpinner asked `isLazyCards()` with no board while cardsWithLimit
asked `isLazyCards(list.boardId)`, so the two could take different branches for
the same list. Both ask about the board now, and both build the selector the same
way instead of from different sources - that disagreement was the bug.
2. "RANDOM BLANK CARDS ARE APPEARING ON THE BOARD." White minicards with the
handle icon and nothing else - no title, no members, no labels - mixed in among
the real ones. In the screenshot the only two that render are the two carrying the
viewer's own avatar.
A minicard renders blank when its document is in minimongo without its fields:
`Cards.getTitle()` returns null for `title === undefined`, and every badge is
conditional on a field that is not there either. That is NOT a card with an empty
title - the schema declares `title` as optional with `defaultValue: ''`, so a card
that went through it has the key, `''` at worst. A document without the key at all
is a partial replication, and several publications ship cards with a projection:
`openCardData` publishes `{ _id: 1 }` as the parent of its children cursors, the
search publications ship their own field lists, and minimongo merges what every
live publication says about an id.
WHICH of them produced these particular stubs is not settled - it needs the
running board to catch - so this is a guard where the card is drawn rather than a
fix at the source: a document that does not carry the field the minicard is built
around is not drawn. `$exists` is what separates the two cases; filtering on a
falsy title would hide real cards. It cannot hide a card, and when the full
document arrives the card appears, which is what the blank box was standing in for
anyway.
tests/listCardWindow.test.cjs covers the reported case (a filter empties the list
and the total still says 25), a short window in general, that a full window with
more behind it still offers to load more, a stale total in both directions,
missing input, that an empty title is still drawn while a missing one is not, that
the selector stays flat and an existing `title` clause is not silently replaced,
that two filters no longer share a count document while the same filter always
names one whatever order it was built in, and that every subscriber names it the
same way.
Thanks to xet7 !
"notice how the card info docks neatly right next to the card" - the 6.09
behaviour asked for in #6465. The window had been moved off the middle of the
board and docked to the end edge instead, which stopped it covering the board but
left it nowhere near the card it belongs to: open a card in the FIRST list of a
wide board and its details are a screen away, with the whole board between them.
It now opens beside the minicard it was opened from, on whichever side has more
room, and always entirely inside the visible area. A card on the left of the
board opens to its right; a card on the right opens to its left.
This is X ONLY. The vertical geometry - the staggered `top` and the `bottom: 8px`
that makes the window full height - is already right, so nothing here writes
`top`, `bottom` or `height`, and a test fails if it starts to.
client/lib/cardDetailsPlacement.js is the decision, pure and unit-testable
without a DOM (like client/lib/cardDragGeometry.js beside it); cardDetails.js is
the DOM half. The width is passed through UNCHANGED unless the viewport itself is
narrower than the window. Shrinking the window to fit the gap beside the minicard
was tried and dropped: on a 600px-wide desktop it turned a 520px window into a
240px one, and this is about where the window is, not how big it is. When neither
side has room it overlaps the card instead, pushed as far towards the roomier side
as the viewport allows - the card is behind it for a moment, which is
recoverable; a window off the edge of the screen is not.
Nothing is placed unless there is something to place it against: a card opened
from a URL, from search, or whose list is scrolled out of view has no minicard on
screen, and keeps the stylesheet's dock. Only the desktop floating window is
touched - the popup form (Board Table, search results) and the mini-screen card
have their own geometry, and the maximized window's insets are !important, so
writing inline styles for it would be a no-op that only looked like it did
something. A window the user has DRAGGED keeps where they put it; the viewport
clamp still applies to it, so a browser window that shrinks cannot leave it
hanging off the edge.
The one vertical side effect that had to be paid for, in cardDetails.css: the
default-position rule is `:not([style*="left"]):not([style*="top"])`, so writing
an inline `left` switches it off - and it carried the `top` as well as the width.
Without a replacement, a SIXTH open window (past the five staggered nth-of-type
rules, reachable with "Open many cards at once") would have had no `top` at all.
The replacement is Y-only and written BEFORE the stagger rules, so cards 1-5 still
take their staggered `top` from those and no vertical position changes anywhere.
The test pins that order, because the same rule written after them would win the
specificity tie and flatten cards 2-5 onto card 1.
Re-placed on resize, coalesced into one animation frame. The inline geometry is
cleared before measuring, so what is measured is the width the stylesheet wants
rather than this function's own previous output - otherwise one run on a narrow
viewport would clamp the width and every later run would re-clamp that clamp, and
widening the browser again would never give the window its full width back.
tests/cardDetailsPlacement.test.cjs covers the placement for a card at each end of
the board, that the side is chosen by which has more room rather than by a fixed
edge, that a tie breaks towards the reading direction, that the window stays on
screen for every anchor position across the viewport including one scrolled
partly out of view, the narrow-viewport and neither-side-fits cases, that the
width is never grown, that a missing anchor places nothing - and the wiring: both
drag handles mark the window as user-placed, the reset happens before the
measure, and no vertical property is ever written.
Thanks to csonkaoszimt, Mintyt and xet7 !
Fixes#6465,
The values survived the move; their keys did not. Each entry came out with
`_id: ""`, which no board can match to a field definition, so the card arrived on
the destination board with every custom field showing empty. Drag-and-drop, the
Move card popup and the REST API `newBoardId` move all go through
Cards.helpers.move(), and Cards.helpers.copy() had it too.
`mapCustomFieldsToBoard()` was SYNCHRONOUS and called
`ReactiveCache.getCustomField()`, which is async on the SERVER - it awaits
findOneAsync - and synchronous only on the client. So on the server both lookups
returned Promises. A Promise is truthy, so `if (!oldCf)` never fired and the
`if (newCf)` branch always did, assigning `newCf._id`: `undefined` on a Promise.
The schema declares `customFields.$._id` as `optional: true, defaultValue: ''`, so
collection2 cleaned that undefined to `''` on the way to the database. Nothing
threw and nothing was logged.
Both lookups are awaited now, and so is `oldCf.addBoard(boardId)` - also async,
and until the two above were awaited its branch was unreachable, so its own
missing await had never been exercised.
Two things found while fixing it, in the same function:
* The entries are rebuilt rather than mutated. copy() deliberately works on a
shallow copy of the card "to avoid mutating the source card in ReactiveCache",
and `cf._id = newCf._id` reached straight through that copy into the source
card's own entry objects - re-keying the card being copied FROM.
* An entry with no id is passed through instead of looked up.
getCustomField() defaults its selector to `{}`, so `getCustomField(undefined)`
returns an ARBITRARY custom field, and a blank entry - including one blanked
by this very bug - would have been re-keyed to whichever field came first.
This is the same defect as #6504 (unawaited ReactiveCache.getBoard in this same
cross-board branch of move(), which gave "newBoard.getNextCardNumber is not a
function"), one line further down. The guard added then named the two getBoard
calls and stopped there, so the third call shipped broken for twenty more
releases; tests/cardMoveAwaitBoard.test.cjs now checks the branch as a whole and
fails on any unawaited async call in it - verified against the pre-fix file, where
it reports mapCustomFieldsToBoard.
tests/cardCustomFieldsMove.test.cjs lifts the real function out of models/cards.js
and runs it against both worlds - an async ReactiveCache (the server, where this
broke) and a synchronous one (the client, where it always worked) - which must
give the same answer: a value whose field exists on the destination board by name
and type is re-keyed to that board's definition, and one whose field does not is
left pointing at the definition it had, which gains the destination board so the
value still resolves. It also pins that addBoard is finished before the array is
returned, that an unknown field id costs no value, that a blank entry is never
matched against an arbitrary field, that the source card keeps its own ids, and
that both call sites await.
Cards moved or copied between boards on an affected release are NOT repaired by
this: the entry kept its value but lost the only reference to which field it
belonged to, so there is nothing left to match it back with. Those values have to
be set again.
Thanks to ChristianMa97 and xet7 !
Fixes#6560,
Ticking "Propagate Members To Boards" for a team in Admin Panel > People > Teams
stored the flag and added nobody. The members only appeared later, when the LDAP
sync cron ran the propagation by its other, correct route.
`setTeamPropagateMembersToBoards(team, value)` receives `team` as the SELECTOR the
client sent - `{ _id: … }`, the same value it hands to `Team.updateAsync` on the
line above - and passed it whole:
await propagateGroupMembersToBoards('team', team);
`propagateGroupMembersToBoards(kind, groupId)` puts that straight into the member
lookup, so it ran
Meteor.users.find({ 'teams.teamId': { _id: 'abc' } })
comparing a string field against an object. It matched nobody, the function
returned early with "0 boards updated, 0 members added", and nothing threw. The
checkbox went green and did nothing.
The org column beside it was identical - `setOrgPropagateMembersToBoards` passed
`org` the same way - and is fixed with it, though the report was about teams.
Both call sites pass the id now, and `propagateGroupMembersToBoards` normalises
whatever it is given at the one point every caller goes through: a plain id, or a
document/selector carrying one. Anything it cannot turn into an id is REFUSED AND
LOGGED rather than quietly treated as a group with no members, because a silent
"0 members added" is exactly how this survived a release. A missing group stays
quiet - propagateAllFlaggedGroupsToBoards may legitimately have nothing to pass.
The select-all checkbox in the column header is the same promise to the admin, and
it did not propagate at all, not even wrongly: setAllTeamsFeature /
setAllOrgsFeature set the flag on every row and stopped. They now propagate when
that field is the one being turned ON, and only for their own kind, so ticking the
team column does not act on the org column beside it.
propagateAllFlaggedGroupsToBoards takes an optional kind for this; the default is
unchanged, so the LDAP cron and the propagateOrgTeamMembersToBoards method still
do both.
The two wiring tests in tests/propagateMembers.test.cjs REQUIRED the buggy calls -
they asserted `propagateGroupMembersToBoards('team', team)` verbatim, pinning that
a call happened without asking whether its argument was right, and so held the bug
in place. They require the id now and fail if the whole selector comes back, and
the normaliser is exercised for real: every shape a caller might hold an id in
resolves to it, a selector with no id resolves to null AND warns, and an absent
group is quiet.
Thanks to ChristianMa97 and xet7 !
Fixes#6559,
The crash loop is gone - a transient database error no longer ends the boot
(00startupResilience) or the process (00processErrors) - and the reporter's 10.49
log is the same contention arriving in front of a user instead:
Exception while invoking method '/users/updateAsync' MongoServerError:
... [collection.go:191 sqlite.(*collection).UpdateAll]
[db.go:151 fsql.(*DB).InTransaction] database is locked (5) (SQLITE_BUSY)
That error goes to the CLIENT. The user's edit fails, and they reload to find out
what happened - which is exactly the complaint, "they only see new cards after a
reload". And it was not supposed to: models/lib/databaseErrors.js has classified a
locked SQLite as { id: 'deadlock', act: 'retry' } with "Retried automatically."
since it was written, and 00processErrors says "the write is retried by whatever
issued it". Nothing read `act`. No code in WeKan retried anything, anywhere.
SQLITE_BUSY is the one database error a client is meant to handle itself. SQLite
has a single writer; a second writer arriving while the lock is held is told to
come back, and nothing was applied - FerretDB takes the lock before the
transaction (_txlock=immediate), so a BUSY answer means the write did not happen.
Retrying the same write is the documented behaviour and stays idempotent: Meteor
has already chosen the _id, so a retry that raced a duplicate is refused by the
unique index rather than inserted twice.
server/00retryBusyWrites.js wraps insertAsync / updateAsync / upsertAsync /
removeAsync on Mongo.Collection.prototype: a transient database error is retried
with exponential backoff and full jitter, bounded at 5 attempts and 2s in total
(WEKAN_DB_RETRY_*). Bounded on purpose - retrying for longer holds a method
invocation and its slot in the connection pool while the contention it is waiting
for gets worse. When it still fails the ORIGINAL error is thrown unchanged, so a
database that is genuinely stuck looks exactly as it did before and nothing is
hidden; anything that is not transient is rethrown on the first attempt, so a full
disk is not waited on four times before being reported.
It is loaded from server/imports.js, which runs after the Meteor packages, so this
wrapper sits OUTSIDE the ones collection2 and collection-hooks put on the same
prototype - and that is how it sees the error at all, because by then the busy
error is collection2's ValidationError with the database's message inside it,
which is the form in the reporter's SyncedCron traces.
Writes only. Every error in the reports is a write, which is what contends for the
one writer; SQLite in WAL mode does not block a reader against a writer, and
wrapping every read would put this on the hottest path in the server for no
reported failure.
Retries are counted and summarised at most once a minute, so a contended database
is visible without the log becoming the new problem, and a write finally given up
on is recorded for Admin Panel / Problems - except an eventlog write, which is how
the recorder writes, and reporting its failure would call the recorder from inside
itself.
The reporter asked outright whether PostgreSQL is an option for a snap
installation. It is, and it has been: the deadlock rule's advice now says how -
snap set wekan wekan-ferretdb-handler=postgresql wekan-ferretdb-url=... , or
docker-compose-ferretdb-v1-postgresql.yml in Docker - instead of only saying that
SQLite has one writer.
tests/sqliteBusyRetry.test.cjs loads the real module against a stub collection
prototype and exercises the behaviour: a busy write is retried and succeeds with
its arguments and its collection unchanged, collection2's ValidationError form is
recognised too, a full disk is thrown at once and never retried, an endlessly busy
database gets the original error after a bounded number of attempts AND a bounded
wall-clock time, the backoff grows and is jittered and capped on the shipped
numbers, the summary is rate-limited, reads are left unwrapped, wrapping twice is
a no-op, and the eventlog write is retried without reporting on itself.
Thanks to Nissulya and xet7 !
Fixes#6533,
Three attempts at this have added imports to client/lib/swcHelpers.js and 10.51
still failed in Yandex Browser with the same line. The stack says where to look:
Uncaught Error: Cannot find module '@swc/helpers/_/_possible_constructor_return'
at a.s [as link] (...) at client-rspack.js (...:285:985)
at client-meteor.js (...:285:86)
Read outward: client-meteor.js links client-rspack.js, and the failing link() is
inside client-rspack.js. But the bundle rspack writes contains no @swc/helpers
specifier at all - the built _build/main-prod/client-rspack.js has the helper
bodies INLINED and the string nowhere. So the import is in the copy of that file
that METEOR compiled, and Meteor put it there:
* package.json says "meteor": { "modern": true }, which turns on Meteor 3.3+'s
SWC transpiler for every file;
* packages/babel-compiler/babel-compiler.js sets jsc.externalHelpers: true
whenever node_modules/@swc/helpers exists - and WeKan depends on it - so the
output IMPORTS its helpers instead of inlining them;
* for web.browser.legacy that transpile passes no jsc.target and an env.targets
down to ie 11, so `class` is lowered to ES5 and the output gains
import { _ } from "@swc/helpers/_/_possible_constructor_return";
* that specifier is not in the legacy bundle's module tree and the link()
throws before anything runs. The modern bundle is unaffected: nothing there is
lowered that far, and modules-runtime/modern.js resolves
mainFields ['browser','module','main'] - the esm/ file - where legacy.js
prefers `main`, which is ../../cjs/_x.cjs.
That is also why the earlier fixes could not work. client/lib/swcHelpers.js is in
the RSPACK graph; rspack resolves its imports and inlines the helper bodies, so
they never become entries in Meteor's module tree, which is the tree the failing
link() searches. No import from app code can satisfy a link that Meteor's
transpiler writes afterwards.
So .swcrc sets jsc.externalHelpers: false and SWC inlines each helper into the
file that needs it: the import is not emitted, so it cannot go missing. Both
readers of that file merge it over their defaults and neither preserves this key -
Meteor's deepMerge keeps only jsc.target, env.targets and module.type, and
@meteorjs/rspack's cleanOmittedPaths only jsc.target - so it reaches the Meteor
transpile and the rspack build alike. It costs a copy of a helper per file that
uses one, which is the right trade for a bundle that does not load at all.
.gitignore's `*.sw*` is for vim's .swp/.swo and matched .swcrc too, so adding it
was silently a no-op; `!.swcrc` follows it, and the test fails if that exception
is removed or moved above the rule that needs it.
Only browsers served the legacy bundle could hit any of this, which is why it read
as a Yandex bug. useragent-ng reports Yandex Browser as family "Yandex Browser",
webapp camel-cases that to yandexBrowser, and modern-browsers has neither a
minimum nor a chrome alias for that name - isModern() is false for a name nobody
declared - so every Yandex Browser user was served ES5. server/modernBrowsers.js
declares yandexBrowser 18: its major version is a year, and 18.x is Chromium 64,
past full ES2015 (51) and dynamic import() (63). Samsung Internet, Vivaldi, Opera
Mobile, Whale, MIUI, UC and QQ Browser are in the same position and are left
alone on purpose - their version numbers do not map onto a Chromium version - and
the file says so rather than looking like they were forgotten.
tests/modernBrowsers.test.cjs reproduces Meteor's decision (webapp's camelCase,
modern-browsers' alias table and lookup) against real user agent strings, so it
fails if the key stops matching the family name or the minimum stops covering the
versions in the reports. tests/swcLegacyHelpers.test.cjs now pins .swcrc, that
the keys the readers preserve are NOT set there, the gitignore exception, and that
swcHelpers.js still says it is a diagnostic rather than the fix.
Thanks to zubzhaaaw and xet7 !
Fixes#6557,
A database problem arrived in Admin Panel / Problems / Database problems
with an empty Category, Name and Action, a severity of warning, and a
detail that said "The database returned an error WeKan has no rule for.
Read the message below" - with no message anywhere below, or above, or on
the page at all. So the row said that something happened and nothing
about what.
Nothing was wrong with the classifier or the recorder. EventLog has a
SimpleSchema attached, and collection2 cleans every insert against it
with filter:true, so a field the schema does not declare is dropped
silently on the way to the database. The four fields the database stream
uses - type (the rule id), db (which database said it), kind and message
- were never added to that schema, so they were the four things thrown
away, and they are exactly the four the page shows in Category, Name,
Action and the message it told the admin to read. The other four streams
were unaffected because they only ever write schema fields.
The schema declares them now, and a test pins the general rule instead of
the one instance: for each of the five event loggers, every key of the
document it inserts must be declared in the EventLog schema, so the next
field somebody adds to a logger cannot vanish the same way.
The message is shown too - the Detail cell carries WeKan's reading of the
error and then the database's own sentence, which is the one thing an
admin can search for or paste into an issue - and the stream search looks
at message, db, kind and type, so searching for "postgresql" or for a
phrase out of the message finds the row that displays it. The
unclassified advice no longer promises a message "below": the message
follows in the same cell.
Because that message is now stored and displayed, it loses its
credentials first. A database that refuses a login or cannot be reached
quotes the connection URL back, password and all - "failed to connect to
mongodb://wekan:s3cret@mongo:27017" - so classifyDatabaseError redacts
the userinfo of any URL in the message before returning it, keeping the
host, the port and the database name, which are what makes the message
useful. It is done there rather than in the recorder so no future caller
can forget it. The message is also sanitized like every other stream's
detail: one line, control characters out, capped.
Thanks to xet7 !
The rebase that landed v10.50 rewrote three of the commits the Upcoming section
links, so three links pointed at nothing; releases/fix-changelog-hashes.sh
repointed them by subject and author date. All 3024 commit links in the file
resolve to a commit in this clone again.
The section was also three commits short of what has been done since v10.50.
Added: the SNAP_AUTH message that blamed the Snap Store for a credential
snapcraft could not read, the Releases menu that makes every maintainer script
in releases/ reachable from build.sh and build.bat, the twelve one-line wrappers
that became commands plus the command line both scripts now have, and the
variant sync renaming both snapcraft files.
Every commit since v10.50 now has an entry except the changelog commits
themselves, which is the convention.
Thanks to xet7 !
The wrappers first. `releases/ufw-enable.sh` was one line - `sudo ufw enable` -
and so were eleven others: ssh-start/stop, snapd-start/stop, docker-start/stop,
multipass-remove, syncloop, git-add-revert, stable-tag and ufw-disable. Nothing
in the repository called them except the menus added yesterday, so they are the
command itself now, in the same menu entries. Checked one by one before
deleting: docker-build-deps.sh looked like the same kind of thing and is NOT
gone, because releases/docker-build.sh runs it.
An entry is "Group|Label|what|prompt|platform|key" now. `what` is a path under
releases/ or, with a leading "!", the command. `platform` is "linux" for the ten
that are systemd, ufw, snap or multipass: build.bat does not offer those,
because Windows cannot do them at all - it is not a parity gap, and the guard
knows the difference. ssh-start ran `systemctl enable ssh` twice; the entry
enables AND starts it, like its stop counterpart always did.
Then the CLI, which is what makes any of this usable from a script or a cron
entry:
./build.sh --help usage and examples
./build.sh --list all 84 names, with what each one does
./build.sh <name> [arguments] run one, without the menu
./build.sh release-snap 10.50
./build.sh push-translation ja
./build.sh ufw-enable what releases/ufw-enable.sh used to do
The name is the file name without its extension, or - for the twelve commands -
the name of the wrapper file it replaced, so anything anybody had in a script
keeps working. Arguments after the name are passed through unchanged. An
unknown name says so and exits 2 instead of doing nothing. build.bat has the
same thing, dispatched before the menu, and both menus have a "CLI commands"
entry that prints the help and the list.
tests/buildScriptParity.test.cjs gains: both scripts must dispatch from the
command line, every name build.sh answers to must work in build.bat unless it
is linux-only, the linux-only ones must NOT be in build.bat, and every example
in the help text must be a real name - which is the guard that catches a help
text teaching a command that fails.
Thanks to xet7 !
releases/ holds 90 maintainer scripts and FOUR of them were reachable from a
menu - the test run, the database conformance run, run-everything and the
CHANGELOG hash repair. Everything else existed only for whoever remembered the
file name: the bundle builds per architecture, the whole snap flow, the
Transifex scripts, the Sandstorm packaging, the tag and release helpers, the
Docker image publishing, the VM helpers.
They are one list now, `RELEASE_SCRIPTS` in build.sh, as
"Group|Label|path|argument prompt", in eight groups: Release, Snap, Bundles,
Docker images, Sandstorm, Translations, Git and repo, Server and VM. Pick a
group, pick a script; a script that needs a version, a language code, a branch
or a file is ASKED for it and gets it passed through, so it works from the menu
instead of only from a remembered command line. An .mjs entry is run by node,
everything else by bash.
build.bat has the same eight groups with the same scripts in the same order,
run through Git Bash - and it says so by name when bash is not on PATH, rather
than failing with "not recognized as an internal or external command".
Not in the menu, each for a reason the guard states: run-everything.sh,
db-conformance.sh and fix-changelog-hashes.sh (already in the Tests and Setup
menus), ensure-tools.sh (a helper the others source), ferretdb/* (they run
inside the built snap, bundle or Docker image), the superseded old-*.sh, and
build-bundle-win64.bat, which bash cannot run - the Bundles menu of build.bat
says to run that one directly.
tests/buildScriptParity.test.cjs gains the two guards that keep this true: every
.sh/.mjs/.bat in releases/ must be reachable from BOTH menus unless it is in the
documented skip list, and the two menus must offer the same scripts, in the same
order, asking for the same arguments.
Thanks to xet7 !
v10.50 built the amd64 snap, uploaded it, and died on
Publishing snap "wekan_10.50_amd64.snap"...
Unsquashing snap file 'wekan_10.50_amd64.snap'.
Credentials could not be parsed. Expected valid Ubuntu One credentials.
and the job then printed "SNAP_AUTH did not work: the Snap Store refused the
upload". The store refused nothing: snapcraft could not READ the secret. Sent
after the wrong problem again, and this time after a full snap build on every
architecture.
Three changes, no guessing about the credential format - that is snapcraft's
business, not this workflow's:
* the secrets check now rejects only what is unambiguously not a credential:
under 100 characters, or containing snapcraft's own "Exported login ..."
banner, which is what pasting the terminal OUTPUT instead of the file the
command WROTE looks like. That fails in one line at the top of the job
instead of after the build;
* the message after a failed upload no longer claims to know which failure it
was. It names both, and how to tell them apart from the snapcraft line
printed just above: "Credentials could not be parsed" is an unreadable
secret, 401/403 is a credential that lacks the ACL for that snap NAME;
* every re-export command now names all three snaps, because one release
publishes wekan, wekan-ondra and wekan-gantt-gpl:
snapcraft export-login --snaps wekan,wekan-ondra,wekan-gantt-gpl \
--acls package_access,package_push,package_release,package_update \
snap-auth.txt
gh secret set SNAP_AUTH --repo wekan/wekan < snap-auth.txt
The same distinction is in the Launchpad upload message, which had a third
possibility of its own ("is not a valid file" = the build produced nothing).
Thanks to xet7 !
Snap-Ondra-Gantt.md described the design as it was planned, not as it works:
the snap depending on the repository push, one architecture, one snapcraft
file renamed. It now says what the workflow does - two independent decisions
(publish the snap / update the repository), amd64 and arm64, both snapcraft
files, and the name check before the upload - and that the two repositories
were synced by hand on 2026-07-29.
It also points at the manual Docker path, which is new: wekanteam/wekan-gantt-gpl
and wekanteam/wekan-ondra are published by .github/workflows/docker-variant.yml
or releases/docker-publish-variant.sh, by retagging the released
wekanteam/wekan manifest.
Thanks to xet7 !
People are still on the older snap names, so a release that publishes only
`wekan` leaves them on a stale package. Two things stood in the way, and both
were in snap-variants.
The job gated EVERYTHING on WEKAN_REPO_TOKEN being able to push to
wekan/<variant>. Building and publishing a snap needs SNAP_AUTH and nothing
else; keeping the variant GitHub repositories in step with wekan/wekan is a
separate, optional thing. Because the two were tied together, a token without
push rights meant no variant snaps at all - that is why v10.48 and v10.49
published none. Now the guard answers two questions instead of one: `snap` (is
SNAP_AUTH set) decides the build and the publish, `sync` (may the token push)
decides only whether the repository is updated, and every "cannot push" warning
ends with "The snap is still built and published".
The variant tree is also no longer taken from a clone of the variant
repository: it is rsynced from the release tag this job checked out, with the
snap name and title sed into both snapcraft files. So the snap is built from
what was just released, whatever state the variant repository is in - and the
optional push sends that same tree on.
Both variants now build on amd64 AND arm64, the two native runners the default
snap uses, instead of amd64 only, and publish to stable + candidate + beta +
edge like the default snap: base core24, grade stable, so all four channels
accept it.
A last guard before the upload: the built file's name must start with the
variant's snap name. A build that produced wekan_*.snap here would overwrite
the DEFAULT snap in the store with a variant.
SNAP_AUTH must carry the ACL for all three names:
snapcraft export-login --snaps wekan,wekan-ondra,wekan-gantt-gpl \
--acls package_access,package_push,package_release,package_update \
snap-auth.txt
tests/releaseWin64AndVariants.test.cjs pins that the build and publish depend
on `snap` and never on `sync`, that the push is the part that needs the token
and runs once per variant, that both variants cover both architectures, and
that a wrongly named snap is refused.
Thanks to xet7 !
The header of snapcraft.yaml still described an older policy - "the workflow
publishes it to the candidate + beta + edge channels; the stable channel is
published MANUALLY later" - which has not been true for a while: snap-native,
snap-launchpad and snap-variants all publish stable + candidate + beta + edge,
for the default snap and for the wekan-ondra and wekan-gantt-gpl variants.
Both headers now say the actual reason for the base: core24 is released, so the
snap can be grade: stable and the stable and candidate channels accept it.
core26 is still experimental - build-base: devel forces grade: devel, and a
devel-grade snap is refused by stable and candidate, so it could only reach beta
and edge. That is why the release builds core24 and keeps the core26 file for
testing only.
The guard now pins all of it: snapcraft.yaml is base: core24 with grade: stable
and no build-base, every publish in the workflow names all four channels, and
snapcraft-core26.yaml is only ever renamed by the variant sync, never built.
Thanks to xet7 !
snapcraft.yaml is what the snap-variants job builds; snapcraft-core26.yaml is
the same snap on the next base. The sync step seds only the first, so the
core26 file in wekan-ondra and wekan-gantt-gpl kept saying `name: wekan` - and
a core26 build from either repository would have published itself as the
DEFAULT WeKan snap. Both files are renamed now, and the guard pins it.
Also ignores /wekan-ondra/ and /wekan-gantt-gpl/, which is where those two
repositories are cloned when they are synced by hand from this working copy.
They are whole git repositories, so they were never at risk of being committed
into this one, but they do not need to be untracked noise either.
Thanks to xet7 !
The release consumed the previous one, so this recreates it with what has been
done since: the SIGPIPE fix that ends the win64 mystery (a matched file
reported as missing, because grep -q closing the pipe makes pipefail report
141), and the #6558 browser test that was measuring the board's edge
auto-scroll instead of panning.
changelogFormat now excludes the closing "Thanks to above GitHub users ..."
sentence from its 80-column count. That line is prescribed word for word by
CLAUDE.md, so it is 92 characters in every release and cannot be wrapped
without changing the established form - and the file had reached exactly the
250-line budget, so writing the line the rules require failed the guard that
checks the rules. It counts the lines that COULD be wrapped now, and there are
249 of them, all in old entries.
Thanks to xet7 !
Its first run in the 00:12 suite: Chromium 248 passed, 1 failed - this test,
on `expect(during.lane).toBe(120)`, received 0. Everything it exists for
passed: the drag was really in progress, and neither the canvas nor the lane
carried `dragscroll` while it was.
The lane moved because the test grabbed the FIRST card of the FIRST list, which
sits within 40px of the lane's left edge - EDGE_SIZE in
imports/lib/boardAutoScroll.js. Inside that zone the drag's own auto-scroll
takes over by design and moves the lane SCROLL_STEP (15px) per mouse event:
eight moves, 120 - 8*15 = exactly the 0 that was read. That is #443 working
(dragging a card toward an off-screen list scrolls the board), not the panning
this test is about.
Panning is 1:1 with the pointer and happens anywhere; edge auto-scroll happens
only at an edge. So the test now drags in the middle: it measures the lane and
canvas rectangles, picks the minicard with the most room inside a 70px margin
on every side, and moves it along a short diagonal clamped to that box. If no
card can be found that far from every edge - a viewport too small - it skips
with that reason instead of measuring the wrong mechanism. The board is seeded
with cards in four lists so such a card exists.
Thanks to xet7 !
v10.49 printed the listing the previous fix added, and it settles two releases
of guessing:
7z t: archive is intact.
7z l -ba listed 51850 entries; the first five:
2026-07-28 21:58:39 D.... 0 0 bundle
2026-07-28 21:52:07 ..... 9 9 bundle\.node_version.txt
2026-07-28 21:58:36 ....A 8828928 3365469 bundle\bsondump.exe
2026-07-28 21:58:39 ....A 55313920 26791675 bundle\ferretdb.exe
2026-07-28 21:52:07 ..... 243 168 bundle\main.js
##[error]Process completed with exit code 141
bundle\main.js is right there, and the step still failed - with 141, which is
128+13, SIGPIPE. `printf '%s\n' "$listing" | head -5`: head has its five lines
and exits, printf is killed writing to a closed pipe, `set -o pipefail` (which
GitHub's bash sets) makes that the pipeline's status, and `set -e` ends the
step. The evidence printed, then killed the job.
The same mechanism is the ORIGINAL v10.48 failure, and this is the part worth
keeping: `printf '%s' "$listing" | grep -qF -e "bundle\main.js"` - grep -q exits
the instant it MATCHES, printf dies of SIGPIPE, pipefail reports 141, and `if !`
reads that as "not found". So "wekan-10.48-win64.zip has no bundle/main.js" was
printed BECAUSE the file was found. Reproduced both, exactly, in bash.
Every listing now goes through a file and every reader reads the file: the win64
verify, the four `unzip -l "$zip" | grep -q " $want$"` checks on the other
platforms (same trap, only luckier about the pipe buffer so far), and the five
`gh release view ... | grep -qxF` asset checks. No pipe, no SIGPIPE, no
pipefail verdict on a command that did its job.
tests/releaseWin64AndVariants.test.cjs pins that nothing in the workflow pipes a
listing into grep or head, and that the win64 verify reads its listing from a
file.
Thanks to xet7 !
The Launchpad project page answers what three "Stopped" builds and twenty
minutes of build time each could not:
https://launchpad.net/xet7-craft-remote-build
Licence: None specified
"Purchasing a commercial subscription is required ... The licensing of your
project does not qualify for free hosting."
`snapcraft remote-build` files every build under that auto-generated project
(57 snapcraft-wekan-<hash> repositories, one per invocation), and
auto-generated means created with no licence. A project that does not qualify
for free hosting does not get free builders, so its builds end as "Stopped"
with no artifact - Pending, Building, Stopped, `Artifacts:` empty - with
nothing wrong in the build log, because nothing was wrong with the build.
Setting the project's licence to MIT / X/Expat fixes it, and only tells
Launchpad what LICENSE, package.json and snapcraft.yaml already say. That is a
click on Launchpad, not a change in this repository, so what is added here is
the pointer: when a remote build produces no snap, the job now prints the URL,
what to look at and what to set, because this is the one cause that leaves no
trace in the build log it just printed.
The finding, and the click, are written up in ../log/workflow/TODO.txt item 5.
Thanks to xet7 !
misattributing the failures.
Every one of these made a release job report the wrong cause, which is worse
than the failure itself: two of them sent the last round of work after the
wrong problem.
1. snap-launchpad never checked whether a .snap existed. In three steps it did
snaps=( wekan_${VERSION}_<arch>.snap )
and then counted the array. That string has no wildcard, so it is a literal
filename, `shopt -s nullglob` cannot empty a literal, and the count was
ALWAYS 1 whether or not the file was there. So s390x logged an empty
`Artifacts:` list, then "Remote build s390x succeeded", then
'wekan_10.48_s390x.snap' is not a valid file
##[error]SNAP_AUTH did not work: the Snap Store refused the upload
The Snap Store never saw an upload. It is a real glob now, the first match
must also be non-empty, and the upload step says "the Launchpad build
produced no artifact - this is NOT a SNAP_AUTH problem" for a missing file
and keeps the credential advice for a refusal by the store.
2. The Launchpad build log was downloaded and thrown away. It is the only thing
that says why a build ends as "Stopped", and the job printed it only when
snapcraft's exit code was non-zero - which, after (1), it was not. It is now
printed whenever there is no snap, along with `ls -la`, and the "exit 0 but
nothing built" case says so in words.
3. build-win64 verified the zip by listing it into a variable and grepping that,
so a failure printed the verdict and none of the evidence: "has no
bundle/main.js" with no way to tell a bad zip from a bad grep. What can be
checked robustly now is: bundle/main.js, bundle/node.exe and
bundle/start-wekan.bat exist and are non-empty BEFORE zipping, and the
archive passes `7z t`. The listing is printed - five lines and a match count
per file - and a zero count is a warning naming both facts that contradict
it, not a failed release.
4. The snap-variants pre-flight asked GitHub for `.permissions.push` on the
variant repository. That field is the authenticated USER's role, not what the
token may do: it answered true, and the push one step later got
remote: Permission to wekan/wekan-gantt-gpl.git denied to xet7
It now asks the receive-pack advertisement - the first thing a real push
requests, and what GitHub answers 403 to for a token without Contents:write -
with the token in curl's -u rather than in a URL, and no git command, since
this step runs before actions/checkout.
What still needs a person is unchanged and written up in ../log/workflow/TODO.txt:
why Launchpad stops the ppc64el and s390x builds after ~20 minutes, and giving
WEKAN_REPO_TOKEN write access to the two variant repositories.
tests/releaseWin64AndVariants.test.cjs is new and pins (3) and (4);
tests/releaseSnapArches.test.cjs gains "every snaps=() must be a real glob" and
"the build log is printed whenever there is no snap", and its
"SNAP_AUTH did not work" assertion is replaced by the two messages that took its
place, with a note saying why. Both read the workflow with comments stripped -
the comments quote the broken lines on purpose.
Thanks to xet7 !
releases/fix-changelog-hashes.sh - run by build.sh's "Update git ..." after a
rebase and by release-all.sh before a release - decided a link was stale when
its commit was not an ancestor of HEAD. That is the wrong question. A commit
that lives only in an old release TAG is not on this branch, and GitHub serves
it perfectly well; calling it stale and repointing it sends the reader to a
DIFFERENT change, which is worse than the dead link it was trying to fix. Two
2019-era links were repaired that way while fixing the file today, and had to
be put back.
Staleness is now "no ref in this clone - branch or tag - reaches it", read once
from `git rev-list --all` rather than by walking the history per link (which
--all-sections would turn into thousands of walks; the whole file takes about
ten seconds).
When a hash really resolves to nothing, the replacement is now looked for in
order of how strong the evidence is:
1. same subject AND same author date - a rebase keeps the author date and
replaces the commit date, so it is the one to compare;
2. same subject, and only ONE commit has it - a subject like "Updated
ChangeLog." or "Bump versions for v9.99" repeats, and picking the newest
of several was a coin toss;
3. the same patch, by `git patch-id`, which is what survives a reword;
4. the object is gone entirely: if the first 9-12 characters still resolve,
the tail was invented (a short hash padded out to 40 characters) and the
commit the prefix names is the one meant.
Also: only `github.com/wekan/wekan` links are considered, so a link into
wekan/charts or a fork is not matched against this history; and
`--all-sections` (with `--dry-run`) checks the whole file, not only the section
being released - which is how the 106 dead links fixed in the previous commit
were found.
tests/changelogHashFix.test.cjs runs the script over a temporary CHANGELOG and
pins the behaviour: a current link and a tag-only link are untouched, a padded
hash is repointed to the commit its prefix names, an unresolvable hash is
reported rather than guessed, and another repo's link is left alone.
tests/changelogCommitLinks.test.cjs keeps guarding the wiring, with its
ancestry assertion replaced by the reachability one and a note saying why.
Thanks to xet7 !
106 of the 3014 wekan/wekan commit links pointed at nothing. Clicking one
gave GitHub's "This commit does not belong to any branch" 404, and there was
no way to tell from the page which change it had meant.
Three causes, three fixes:
* a rebase, amend or squash after the entry was written (the case
releases/fix-changelog-hashes.sh handles, but only for the section being
released) - the pre-rewrite object is still in the clone, so the commit
with the same subject and author date on this branch is the same commit,
and the link now points there;
* a hash that never existed at all - a 40-character string whose first nine
characters were right and whose tail was invented. Resolved by prefix
where the prefix still resolves, and otherwise by matching the entry's own
text against the commit messages of the release it sits in, one entry at a
time. The "Part 1 / Part 2" links carry no text of their own, so those
were read from the bullet around them: Code of Conduct, Add Header Login,
Updated dependencies, Fix drag drop lists, Red Strings drag-to-connect;
* two entries whose link is the SAME commit as their summary's - the body
repeats the link - which now agree with each other.
Checked the other way round too: a link is only rewritten when its hash is
reachable from no ref in this clone. Two links were reverted after that check
(48ebc5f11, bbc68309a): the commits are reachable from release tags, so those
links were always fine. Every one of the 3014 links now resolves to a commit
in the repository.
The 2019-era hashes that are reachable only from a tag are left as they are -
a tag is pushed, so GitHub serves them.
Thanks to xet7 !
On a board large enough to have scrollbars in both directions, dragging a
card sometimes moved the card, sometimes scrolled the list, sometimes
scrolled the board, and often several of those at once, so the card could
not be dropped where it was aimed.
A board runs three drag-scroll implementations over the same pointer: the
dragscroll library, bound separately to `.board-canvas`, to every swimlane
and to every lane; the `mousedown .board-canvas` lane pan in swimlanes.js;
and jQuery UI sortable, which is the one that is supposed to move the card.
Nothing stood any of them down while a drag was in progress. swimlanes.js
did try, for list drags, but called `dragscroll.reset()` FIRST and removed
the class afterwards - reset() binds to whatever carries the class at that
moment, so the listeners stayed - and it left the canvas tagged anyway. The
lane pan ignored the `nodragscroll` marker the library honours, so pressing
a minicard, which carries that marker exactly because it is the card's drag
handle, started a horizontal pan that ran alongside the card drag.
Now client/lib/boardDragscroll.js suspends drag-scrolling for the whole
drag - class off, THEN reset - and restores exactly the elements it took it
from, so a board route does not gain panning it deliberately turned off.
Every sortable on the board (cards, lists, swimlanes) suspends in start and
resumes in stop, a window mouseup/touchend/dragend restores in case a drag
never reaches its stop handler, and a swimlane re-rendered mid-drag does not
re-arm panning under the pointer. The lane pan now refuses to start on
`.nodragscroll` or on a drag handle, and gives way if a drag begins after
the press. The drag handles themselves are marked `nodragscroll`: a press on
a handle moves the item, it never pans the board.
tests/boardDragScrollDuringDrag.test.cjs pins the order of the two steps,
the restore-what-was-suspended rule, the safety net, the suspend/resume in
every sortable and the two markers; specs/37-card-drag-sort.e2e.js drags a
card sideways on a 12-list board and pins that neither the lane nor the
canvas scrolls while it moves, and that panning is back afterwards.
Thanks to mueschel and xet7 !
Fixes#6558,
The 18:10 run: 267 node suites, 2 failed. All three browsers clean, Mocha 500
passing, FerretDB unit and integration green - and the conformance run has all
FOUR backends answering identically now (see below).
changelogFormat was right, and about MY text: two lines in the entries I wrote
today START with `#`, which markdown renders as a heading and which splits the
version list - the exact trap CLAUDE.md warns about. The issue numbers are
escaped (`\#3138`) and the lines rewrapped so none begins with one.
boardsVisibilitySettings pinned a Yes/No radio in the account-access Save that is
not in that pane: "display the authentication method" is a checkbox with its own
handler, which writes the toggle directly. The guard now checks what that Save
really does - both fields guarded on being on screen, and nothing written when
neither is - and that the display toggle writes itself.
And the news from the same run: sqlite, postgresql, MYSQL and MARIADB all answer
identically on 98 of 100 cases, with ZERO differences. The two exceptions are the
$slice / $elemMatch projections that no backend implements. This morning MySQL
answered "Error 1064" to every filtered query and MariaDB could not create a
collection.
Thanks to xet7 !
The Upcoming section had the CodeQL fixes and the backlog update - their hashes
were corrected after the rebase - but nothing for what came after them:
* the #6533 fix, which is the one users feel: `quave:synced-cron` installs a
process-wide unhandledRejection handler that calls process.exit(1), so one
write losing a race for the SQLite write lock ended the whole server and
systemd restarted it into a busier database. WeKan decides now, and a
transient database error is logged and survived;
* the four guards that pinned an older shape, and the browser test that
reported "class missing" when the board had simply not arrived yet;
* the translations update, as a plain bullet - there is nothing more to say
about it than that it happened.
Checked against the rules: the security subsection keeps "This release", each
later one starts with "and", every summary is one line under 120 characters and
links a commit that exists in this repository, and every commit since the tag is
accounted for except the changelog-only ones.
Thanks to xet7 !
Under a three-browser run WebKit reported "element(s) not found" for
`.board-list-item.has-background-image`, which cannot tell "the board has not
arrived in minimongo yet" from "it arrived without the class". It waits for THIS
board's tile first, found by its id in the seeded title, and only then for the
class - so a future failure names the actual problem instead of both at once.
Thanks to xet7 !
The reporter's 10.45 log shows the startup work landing - "[startup] a startup
step could not finish because the database was busy; WeKan continues" and
"[checklists] Backfilled boardId on 0 row(s); 21 row(s) have no card to take it
from" instead of a 130k-card scan - and then the server dying anyway:
SyncedCron: Fatal error encountered (unhandledRejection): ValidationError:
... sqlite.(*collection).UpdateAll ... database is locked (5) (SQLITE_BUSY)
SyncedCron: Received UNHANDLED_REJECTION signal - cleaning up running jobs
systemd: Main process exited, code=exited, status=1/FAILURE
`quave:synced-cron` installs a process-wide unhandledRejection handler that calls
process.exit(1). So ANY unhandled rejection - including one write losing a race
for the SQLite write lock, which is transient by definition - killed the whole
server, and systemd restarted it into a database made busier by the restart. The
counter reached 73.
server/00processErrors.js takes that decision back. The package is deliberately
polite about it: it only exits `if (process.listenerCount('unhandledRejection')
=== 1)`, i.e. when nothing else has an opinion, so having one is the documented
way to stop it. A transient database error is logged and recorded for Admin
Panel / Problems and WeKan keeps serving; anything else is logged with its full
stack and WeKan still keeps serving, because ending everybody's session over one
rejected promise is a larger failure than the one being reported. An uncaught
EXCEPTION still exits unless it is a transient database error - a process that
threw out of a place nobody handled can hold half-applied state.
The four guards the same run surfaced, each a later assertion:
* boardsVisibilitySettings: the Visibility saves go through
visibilityTextFields(), which does the "is this input on screen" check once
for every field instead of per call site.
* changelogFormat: "the newest release" now means the newest RELEASE (an
Upcoming section may sit above it), the Upcoming section is checked by its
own test, and a release needs at least ONE entry - "more than five" measured
the day's workload rather than the format, and v10.46 carried two fixes.
* leftMenu: /information redirects the FlowRouter way, like /translation.
* narrowWindowLayout: the phone rules carry !important, because the desktop
rule they override is more specific.
Thanks to Nissulya and xet7 !
Fixes#6533,
Every issue in the backlog was checked against GitHub. Ten are closed and are
gone from the list: #3138, #3252, #3276, #3378, #3748, #3828, #4055, #4774,
#5149 and #6511. The "already correct in the current code" category went with
them - it held only #4774 and #4055, both closed - so an empty category does not
sit there looking like work.
#6509 is not a bug report any more, it is "please test FerretDB v1 with MySQL,
MariaDB and SAP HANA", and it is mostly answered: the conformance harness runs
one catalogue of 100 queries against every backend with an image for this
machine, and MariaDB now answers identically to SQLite on 98 of them - the two
exceptions being the $slice / $elemMatch projections that no backend implements.
The entry says what is still open rather than implying otherwise: MySQL's
confirming run is pending (its container lost a port race, since fixed) and SAP
HANA is untested, because its image needs a licence acceptance and a machine with
the memory for it.
And one string was actually translated: Finnish `databaseReportTitle` ->
"Tietokantaongelmat". The other 40 Finnish placeholders are numbers, symbols,
product names (Gantt, LDAP, OAuth2, S3/MinIO, GridFS) and a font name, which ARE
the same in Finnish - the headline "12,254 untranslated strings" is mostly that,
which is worth knowing before anyone sets out to fill them. The search-operator
abbreviations are deliberately left in English: `b:` / `l:` / `s:` are how a
search is TYPED, and translating them changes the syntax for that language, which
is the maintainer's call rather than a wording fix.
Thanks to xet7 !
CodeQL alert #430, js/disabling-certificate-validation, High:
`reqOptions.rejectUnauthorized = false` in the outgoing-webhook path. It is
right, and the switch is gone.
`rejectUnauthorized: false` accepts ANY certificate - including the one a man in
the middle presents - which is the attack the handshake exists to stop. What
#6553 and #6551 actually need is not "verify nothing", it is "this certificate is
legitimate", so that is what WeKan takes now:
WEBHOOK_TLS_CA_CERT the certificate (or CA) to TRUST for outgoing webhooks
MAIL_TLS_CA_CERT the same for the mail server
MAIL_TLS_SERVERNAME the name to verify the mail certificate AGAINST, for the
wildcard-one-level-short case the report describes
Each is the PEM itself or a path to a file holding it. A self-signed certificate
is its own issuer, so naming it here is exactly what makes it valid - and
verification stays ON, the chain is still checked, the hostname is still checked.
A path that cannot be read is not fatal: it logs which setting failed and keeps
the system trust store, rather than stopping mail or webhooks.
The SSRF protections are untouched: the address is still resolved once and
pinned, private ranges are still refused, redirects are still blocked.
CodeQL alert #429, js/incomplete-sanitization, High:
`helper.replace(/\./g, '\\.')` in a test escaped dots only, so a backslash in the
value could change the meaning of the pattern it was spliced into. It uses the
same escape-everything helper tests/testsAreRegistered.test.cjs already has, with
the backslash escaped FIRST.
tests/mailTransportTls.test.cjs now fails if `rejectUnauthorized: false`, that
same assignment, or NODE_TLS_REJECT_UNAUTHORIZED appears in either file - so the
pattern cannot come back quietly - and covers the certificate-from-PEM,
certificate-from-path and unreadable-path cases.
Thanks to GitHub CodeQL code scanning and xet7 !
v10.45 was tagged at 12:11, and the two changes after it went into the file with
no Upcoming section to go into: the #6556 fix landed INSIDE the released v10.45
section, where it says something that is not true - that release does not contain
it - and the test-harness fixes were not recorded at all.
There is an `# Upcoming WeKan ® release` section above v10.45 now, holding both:
the SWC helper fix that 10.45 shipped and the bundler deleted, and the WebKit
navigation retry / conformance container cleanup, with the four guards that
drifted alongside them. The entry that used to open with "…and" reads on its own
now, since it no longer follows the entry it was a continuation of.
Checked against the rules in CLAUDE.md: the file still opens with Platforms and
TODO Later, Upcoming sits between them and the newest release, nothing else is a
heading, every summary is one line under 120 characters and links the commit it
describes, the first subsection says "This release …" and the next "and …", and
the backlog still thanks nobody.
Thanks to xet7 !
Node suites: 267 run, 4 failed - each a LATER assertion in a suite fixed earlier
today, which is how this runner works.
* boardsVisibilitySettings: the template lookup tried only `name='x'`, and this
file writes both quote styles, so a template that is right there "must
exist".
* changelogFormat: my own entry's summary was 121 characters against a 120
limit, and two summaries linked no wekan/wekan commit. One is shortened; the
other two link the FerretDB commit they describe, and the guard accepts a
wekan/FerretDB link now - the fork is where that code lives, and a WeKan hash
for work that is not in this repository points at the wrong change.
* leftMenu: the old /translation URL redirects with
`redirect(FlowRouter.path('setting'))` inside triggersEnter, which is
FlowRouter's own way; the guard wanted a `FlowRouter.go`, which in a trigger
re-enters the router instead of replacing the navigation.
* narrowWindowLayout: "every rule mentioning the bell or the avatar" is three,
not two - the avatar has a second rule that only zeroes its padding. The two
PLACEMENT rules are picked by what they declare.
WebKit: 242 passed, 1 failed - "WebKit encountered an internal error" from
page.goto, which is the browser, not WeKan. openBoard retries five times for
exactly this reason, but a THROW from the navigation escaped the loop, so one
flaky goto failed a test with four attempts left. The navigation is inside the
try now, and the final message says which of the two happened: a board that never
rendered, or a navigation that never succeeded.
Database conformance: postgresql and mysql were reported as "container did not
start" when the truth was `failed to bind host port 127.0.0.1:35432: address
already in use` - a container left behind by an interrupted earlier run. The
script now removes containers named `wekan-conformance-db-*` (its own, never a
`docker compose` stack) before it starts, and a `docker run` that hits a taken
port moves to the next free one and retries instead of declaring the image
broken.
And the news from that same run: MariaDB now answers IDENTICALLY to SQLite on 98
of 100 cases, the two exceptions being the $slice / $elemMatch projections that
no backend implements. It could not create a collection this morning.
Thanks to xet7 !
10.45 still failed in Yandex Browser with the same
"Cannot find module '@swc/helpers/_/_possible_constructor_return'". The previous
fix was in that build and did nothing.
`@swc/helpers` declares `"sideEffects": false`. That is a promise to the bundler
that importing one of its modules changes nothing observable, so an import whose
bindings are never READ may be removed entirely - and
import '@swc/helpers/_/_possible_constructor_return';
is exactly that. Every line of the file was dropped, the package subdirectory was
never pulled into the bundle, and the legacy module tree came out as before. The
fix compiled to nothing and looked like it had been applied.
Every helper is now imported BY NAME and read: they are collected into an array
whose length is written to `window.__wekanSwcHelpers`. That is an observable
effect, so no optimizer may remove the imports that feed it - and the global is
useful on its own, because in a browser that fails this way again it says in one
word whether the helpers reached the bundle at all.
The `_/` path is what is imported, not `esm/`, because `_/` is what the
transform's own imports resolve at runtime; Node's resolver would refuse it (the
package's `exports` map has no `./_/*`), but Meteor's module system resolves the
directory through its package.json `main`, which is what the legacy bundle does.
tests/swcLegacyHelpers.test.cjs now fails if a bare side-effect import comes
back, if any binding is imported without being read, if the array does not end
somewhere observable, or if @swc/helpers stops declaring sideEffects: false (in
which case this reasoning should be revisited rather than silently kept).
Thanks to zubzhaaaw and xet7 !
Fixes#6556,
#6541 (users disappear on 6.09/MongoDB 3.2 with nothing in the log), #6542 (LDAP
import count vs the People list), #6548 (LDAP debug output inside LXC), #6549
(OAuth2 through Rocket.Chat's G Suite SAML app) and #6552 (file-descriptor limit
for Caddy in the snap - snapcraft has no per-app ulimit key). Each with the
reason it is not done, so whoever picks one up starts where this left off.
Thanks to xet7 !
#6536 - "Impersonate User doesn't work": nothing happened, and the log said
"Match error: Expected string, got null". The popup calls the server with the id
from its data context, and when there is none it called with `undefined`, which
arrives as null and fails the argument check. The client does not call at all
without an id now, and says so in the console; the method marks its argument as
audited (this app runs with audit-argument-checks) and then answers a missing id
with "impersonate: a user id is required" instead of "Match failed", which named
neither the method nor what was missing. isImpersonated got the same treatment.
The impersonation itself is unchanged, including that only an admin may do it.
#6538 - "Bad URL in Wekan mail": the invitation mail contained
`http://127.0.0.1/b/...`. Every link WeKan sends is built from ROOT_URL, so when
that is left at localhost the mail goes out with the SENDER's own machine in it -
unusable for everyone who receives it, with nothing failing and no error to look
at. WeKan says it once at startup now, naming the setting and what to set it to,
for an unset ROOT_URL and for one pointing at localhost / 127.0.0.1 / [::1]. A
warning, not a refusal: a single-machine install where localhost IS the address
is perfectly valid.
Thanks to ahlgrimma, BastienGraziani and xet7 !
Fixes#6536,
Fixes#6538.
"Wekan installed but is not visible in menu" - because the snap installs a
SERVER: it starts a daemon and shipped no .desktop file, so nothing appeared in
the menu and it looked like nothing had been installed.
`wekan.open` is that entry. It reads the snap's OWN settings and opens the
address WeKan is actually serving - ROOT_URL when there is one, otherwise
localhost with the configured port - so `snap set wekan port=…` is followed
without anyone editing a desktop file. The URL goes to snapd's xdg-open shim,
which hands it to the session's browser (that is what the `desktop` plug is for);
on a headless install, where there is no session, it prints the address instead
of failing silently.
Thanks to COOKIE-1816 and xet7 !
Fixes#6539.
#6545 - a Keycloak login opened the popup and closed it immediately. The snap's
default for OAUTH2_REQUEST_PERMISSIONS was "'openid profile email'" - the single
quotes are part of the VALUE - so the scope sent to the provider was `'openid` …
`email'`, which no provider knows and a strict one refuses outright. The default
has no quotes now, and WeKan normalises the value anyway
(models/lib/oauth2Scopes.js: strips surrounding quotes, accepts commas or spaces,
drops duplicates), so an install still carrying the old value keeps working
without anyone noticing the difference.
#6546 / #6555 - there was a mongodb-bind-ip but no way to say where WeKan itself
should listen, so it was always Meteor's default of 0.0.0.0 and IPv6 was
unreachable. `snap set wekan bind-ip='::'` listens on IPv6 (and on IPv4 through
it on a dual-stack host); empty keeps today's behaviour exactly.
#6550 - an IPv6 database could not be reached at all: the snap built
`mongodb://$MONGODB_BIND_IP:$PORT/wekan`, and an IPv6 LITERAL has to be
bracketed - `mongodb://::1:27019/` is not a URL and the driver refuses it. The
address is bracketed when it contains a colon, which no hostname and no IPv4
address does; the readiness probe builds its URI the same way, so it can no
longer wait forever on a URL that cannot be parsed.
#6551 - a mail server whose certificate does not match the name it is reached by
("Hostname/IP doesn't match certificate's altnames" - a wildcard one level too
short, an internal CA) could not be used at all, because Meteor builds its
transport from MAIL_URL with no say in it. MAIL_TLS_REJECT_UNAUTHORIZED=false
installs a transport that connects anyway.
#6553 - the same for an outgoing webhook to a server with a self-signed
certificate: WEBHOOK_TLS_REJECT_UNAUTHORIZED=false.
Both are OFF by default, both are per-purpose, and neither is
NODE_TLS_REJECT_UNAUTHORIZED, which would drop certificate checking for
everything the server connects to. The webhook switch changes nothing else: the
connection is still pinned to the resolved address and private ranges are still
refused, so the SSRF protection is untouched - what is given up is only the proof
of who is on the other end, for the one endpoint the operator chose.
tests/mailTransportTls.test.cjs covers the SMTP option building (ports, smtps,
credentials with encoded characters), that only the exact string "false" turns
verification off, that nothing is installed unless it is asked for, and that
neither file reaches for the global switch.
Thanks to lukasjelonek, sysblade, scoopex, 1977er, GuiGuiSoft, marioschulz93 and
xet7 !
Fixes#6545,
Fixes#6546,
Fixes#6550,
Fixes#6551,
Fixes#6553,
Fixes#6555.
#6540 - with `ldap-sync-admin-groups` set to ONE group, every user that logged in
became a WeKan administrator. Two independent causes.
The group query builds `(&(objectclass=group)(member=<the user>))`. The member
clause - the one that says WHOSE groups these are - was left OUT whenever the
user entry had no value for the configured member format, and the search then ran
as `(&(objectclass=group))`, which answers with EVERY group in the directory. So
every user "was in" the admin group. (A login restricted by group let everyone in
for the same reason.) It now answers with NO groups in that case, names the
misconfigured setting in the log, and first tries the usual other spellings of
the same value (dn / objectName / distinguishedName). The clause is added after
the guard, so it cannot be skipped silently again.
The comparison was `LDAP_SYNC_ADMIN_GROUPS.split(',')` matched exactly: "ti,
admins" produced " admins" and matched nothing, an unset value produced [''] -
one empty string - which matched a group whose name the directory did not return,
and Active Directory's case-insensitive names did not match at all. It is one
shared rule now (packages/wekan-ldap/server/adminGroups.js): trimmed,
case-insensitive, multi-valued names flattened, and an EMPTY configured list can
never grant admin. Login and background sync use it, so they cannot drift.
#6537 - "Search All Boards" answered "Server Error", with `$nin needs an array`
in the log. Two calls in the global-search publication were not awaited, so a
PROMISE was handed to Mongo where an array belongs. The `$nin` pair had been
fixed; the `$in` pair on the archived/all branch had not. And both id helpers
were declared with no parameter while their callers passed a userId, so they
asked for the boards of `undefined`: the archived half of a search matched
nothing even when it ran.
#6544 - the REST route to create a checklist item exists (it did not when that
was reported), but every item it created was given `sort: 0`, so a checklist
filled over the API came out in an order nobody chose. It appends now, like the
UI, and an explicit `sort` in the body still wins.
Thanks to karvox, ahlgrimma, frantzstaboeeg and xet7 !
Fixes#6540,
Fixes#6537,
Fixes#6544.
WeKan 10.44 in Yandex Browser died at load with
Cannot find module '@swc/helpers/_/_possible_constructor_return'
An older browser is served `web.browser.legacy`, where SWC compiles classes down
to ES5 and emits imports of its own runtime helpers. Read out of the built
bundle: it contains `link("@swc/helpers/_/_possible_constructor_return", …)` -
the app asks for it - while the module tree beside it holds 22 helper
directories, and that is not one of them. The module system cannot resolve what
the code imports, so the bundle never finishes bootstrapping and nothing renders.
The order of the build is why. Meteor's scanner decides which files of an npm
package to include from the imports it can SEE, and these imports are written by
the SWC transform afterwards - so a helper that only the transform introduces can
be linked without being included. `_call_super` came in through another helper's
relative require and `_possible_constructor_return`, which nothing else requires,
did not. Exactly one was missing, and it was enough.
client/lib/swcHelpers.js imports the ES5 class/inheritance, iteration/spread and
async helper set from ordinary client code, which the scanner does see, and
client/main.js loads it first. Each helper is a few lines, so having the whole
set removes the class of failure rather than this one instance of it - the next
class written slightly differently would otherwise pull in the next helper
nobody imported.
tests/swcLegacyHelpers.test.cjs pins it: the helper from the report is there
along with its transform neighbours, every name resolves to a real subpath of the
installed package (a typo is a silent no-op at build time and the same crash at
runtime), and the file is imported before the styles and the app code.
The modern bundle was never affected - nothing there is transformed that far -
which is why this only showed in one browser.
Thanks to zubzhaaaw and xet7 !
Fixes#6534,
Fixes#6535.
Each pass of the runner reveals the next assertion in a suite, and three of these
were broken by this morning's own fixes.
* adminCheckboxStyle: the checkbox-row ITEM rule covers two shapes now - a
label around a native checkbox, and the `a.flex > .materialCheckBox + span`
that replaced the Attachments ones - so the lookup is on the pair.
* leftMenu: a menu builder may take arguments (`function peopleMenu(user)`,
since multitenancy option D), and the helper matched `()` exactly, so it
dereferenced null.
* narrowWindowLayout: the width block was sliced up to the rule following
`position: absolute` IN it - and the hamburger is `position: static` now, the
last button in the flow rather than pinned to the corner, so that landmark
was gone and the slice ran from the start of the file. It brace-matches the
media query instead.
And two that were true before today:
* boardsVisibilitySettings: "not on screen is left alone" is
`if ($(selector).length)` - the settings are checkboxes read by `is-checked`,
not radios read by value, so `!== undefined` was the old shape.
* changelogFormat: the TODO Later section ends at whatever comes next - the
Upcoming section when there is one, otherwise the newest release. Ending it
at `# v` alone counted every Upcoming entry as a backlog entry, and those DO
thank people.
Thanks to xet7 !
The mysql/mariadb fixes live in wekan/FerretDB main-v1, so the entry's summary
links there. A WeKan hash for work that is not in this repository points at the
wrong change.
Thanks to xet7 !
`.flex` is `display: flex; height: 100%`, which is right for a pane column and
wrong for an anchor that is ONE ITEM of a row: it stretched to the row's height
and pulled the box away from its words. The storage rows and the Backup include
row now place their items - centred, only as tall as they need - whether the item
is a label around a native checkbox or the material one that replaced it.
Thanks to Alishara and xet7 !
The node runner now reports every failure, so each fix reveals the next
assertion in the same suite. Twelve of the twenty are green; these eight failed
on a LATER assertion than before, and one is new.
* themeColorPicker: the category titles are `text-align: start` now, not
`left` - a physical side is what tests/rtl.test.js fails on. The guard asks
for `start` and refuses a physical side.
* adminCheckboxStyle: Attachments left the "panes that use a native checkbox"
list, because that is exactly what #6465 was. It now asserts the REMOVAL,
and the Backup row is three material checkboxes in one row.
* boardsVisibilitySettings: the site-theme picker is a fifth group.
* changelogFormat: the open/close counts are taken on the MARKUP - an entry
that explains the format writes `<details>` in backticks, closed by nothing.
* leftMenu: the heading branch is read without its jade comments; the comment
says a heading has "nothing ... to read a data-id from", and the guard was
failing on the sentence that explains the rule.
* narrowWindowLayout: the drag-handle toggle has TWO rules in the phone block,
so the declarations are looked for across both instead of in the first.
* securityLog: the Problems menu is DATA now (PROBLEMS_MENU + the shared
+leftMenu), so the entry ids are asserted where they live.
* tablePage: "the global-search machinery is gone" is checked on the code with
comments stripped - the comment above the report's config names the
machinery it no longer uses.
Three of these eight were guards reading a COMMENT as if it were code or markup.
That is now a known shape: strip comments before asserting about source.
CLAUDE.md gains the workflow this came from: check the newest logs and fix WHILE
the run is still going - the node suites are the fastest signal (~15s for 260) -
and decide per failure whether the code or the guard is the wrong side, saying
in the test why when it is the guard.
Thanks to xet7 !
WIP-LIMIT POPUP: "the checkbox can not be unchecked and the counter always falls
back to 1". One cause for both. models/lists.js getWipLimit() read the list back
through `ReactiveCache.getList(this._id)`, and on the SERVER that getter is
ASYNC - it returns a promise, and a promise has no `wipLimit` - so the helper
answered 0 for every option, every time. `enableWipLimit` therefore saw value 0
and reset the limit to 1 on every click, and toggled `!enabled` where `enabled`
was always 0, so every click turned the limit ON. The document is `this`, so the
server needs no lookup at all - and a toggle wants the state as it was when the
click happened, not after its own write. The client keeps the lookup: it is what
makes the popup's tick and number follow the change. Apply now also refuses a
limit that is not a usable number instead of sending NaN, which passes
`check(limit, Number)` and dies in the schema with nothing to show the user.
ADMIN PANEL / ATTACHMENTS CHECKBOXES: every checkbox on those panes - Backup's
three, each storage's Enabled and Read, the S3 path-style flag, the avatar-upload
block - drew as a grey rotated RECTANGLE instead of a green tick. They were
native `<input type="checkbox">` styled into WeKan's material checkbox, which
needs the browser to drop its own rendering for `appearance: none`; where it does
not, the geometry applies and the colours do not, which is exactly that
rectangle. They are `.materialCheckBox` divs now, the same markup as the rest of
WeKan, with no native rendering to lose. Two of them could not be unchecked for a
second reason: their state was written as `checked="{{filesystemRead}}"`, a
quoted STRING - and `checked="false"` is checked in HTML.
SIDEBAR CHECKBOX ROWS: "checkboxes and text don't fit well". A row is
`a.flex > i.fa + span`, and `.flex` is only `display: flex` - no alignment, no
gap - so the box glyph touched the first letter of its label and sat on a
different line from it. `align-items: center` and a 6px gap, with a fixed glyph
width so every row's label starts at the same x whether its box is a square or a
tick.
tests/wipLimitPopup.test.cjs and tests/adminAttachmentCheckboxes.test.cjs pin
all of it.
Thanks to Alishara and xet7 !
Fixes#6465,
The reporter's snap, upgraded from 6.09 to 10.44, was in a systemd restart loop
at restart 72, with 8 CPUs at load 7 and SQLITE_BUSY everywhere:
error on boot.js Error [ValidationError]: Failed validation
[msg_update.go:133 ...] [collection.go:191 sqlite.(*collection).UpdateAll]
database is locked (5) (SQLITE_BUSY)
Two things here, each of which made the other worse. (The third, in the FerretDB
fork, is the `_txlock=immediate` default that lets the busy handler cover a
contended write at all.)
1. A TRANSIENT DATABASE ERROR ENDED THE BOOT. Meteor's boot.js exits the process
when a startup callback rejects, systemd restarts it, and the restart re-runs
the same startup work against a database that is busy because the previous
boot was doing it. SQLITE_BUSY means another writer had the lock - nothing is
wrong with the data - so server/00startupResilience.js wraps every startup
callback: a transient database error (the shared classifier's deadlock /
too-many-connections / connection-lost / timeout) is logged, recorded for
Admin Panel / Problems, and swallowed, and the step runs again next start.
Anything else - a full disk, a refused login, a syntax error - is rethrown, so
a real fault still stops WeKan.
2. THE BOARD-ID BACKFILL SCANNED EVERY CARD ON EVERY BOOT. It streamed the whole
Cards collection and issued one multi-update per card - 130,947 of them here,
for each of two collections - and its "anything left to do?" guard could never
go quiet, because a checklist whose card was deleted has no board id to copy
and stays missing one forever. It is driven by the rows that are MISSING the
board id now (normally none), collects their distinct card ids in bounded
chunks, and asks Cards only for those. What cannot be filled from a card is
counted and reported once. The pass is version-gated like the schema upgrade
beside it, so an unchanged version costs one findOne.
tests/sqliteBusyResilience.test.cjs pins both, including that SQLITE_BUSY
classifies as retryable contention while a full disk does not.
Thanks to Nissulya and xet7 !
Fixes#6533,
The new runner ran all 260 suites for the first time: 20 failed. Four were real
defects in the app, the rest were guards pinning a spelling or a design that had
since changed - each of them written when it was true, and none of them run
since, because npm stopped the chain at the first failure.
The app fixes:
* models/lib/themeAccents.js: accentOf('constructor') returned Object's
constructor - a FUNCTION - because a plain lookup answers from
Object.prototype. A board colour named after any prototype member would have
written a function into a stylesheet. Only the map's own keys are themes now.
* RTL: the dependency overlay and its connect handle each set a physical
left/right AFTER the logical property, so the physical one won and both were
pinned to the LTR side in an Arabic or Hebrew layout. The skip link, the
avatar's account badge, the stats value column and the theme-category label
were physical too. All logical now (inset-inline-*, text-align: start/end).
The guards, each corrected to what the code actually does now, with the reason:
* addBoardTileHeight, publicationArgumentGuard: a fixed-size slice
(jade + 3000, source + 1400) that a grown comment pushed the subject out of.
Both now take the whole block they are about.
* adminCheckboxStyle: the Grey Icons feature is gone; asserts its REMOVAL.
* boardsVisibilitySettings: the separator count was pinned at 3; the site-theme
picker group made it 4. Asserts the shape - one Save per section, none for
the picker that applies immediately.
* changelogFormat: "# Upcoming WeKan ® release" is a legitimate heading.
* dbConformanceWiring: the log directory honours WEKAN_LOGDIR now.
* domainTablePage: the default page is the app-wide 10, not 25.
* ferretdbOplogGating: the exec runs under the CPU launcher.
* leftMenu: peopleMenu takes the user (multitenancy option D).
* loginEmailPanesMoved: the board-member restriction is two checkboxes in
Organizations and Teams now; asserted there.
* mobileAllBoardsFit: the bell and the avatar are two rules with variants.
* narrowWindowLayout: the hamburger is the last button in the flow, not pinned.
* rulesApiTriggerNormalize: #6491 made a missing matching field mean "any
value", so the #2674 "can never match" case now matches - and removeMember
iterates assignees, not members.
* securityLog: the new-problems selector moved to models/lib/eventLogProblems.
* tablePage: the Cards report renders the page the SERVER named.
* tenantWiring: the site colour is read in two places; the autorun is the one.
* themeAccents: see above - the guard was right, the code was not.
* translationPane: the "no hand-written table" regex matched the +tablePage
include it also requires.
* uiDensity: admin table cells wrap in one td+th rule now.
* rtl: the dir attribute comes from a helper, `!important` is not part of a
value, and the scanner read CSS COMMENTS as declarations - the comment
explaining why `left: 50%` needs no RTL variant was reported as a violation.
Thanks to xet7 !
test:unit:node was `node tests/a.cjs && node tests/b.cjs && ...`, 260 suites
long. npm's && stops at the FIRST failing suite, so everything after it never
ran - and the summary said nothing about that. Tonight's run printed
"tests:508 fail:1" having skipped about 200 suites: the 01:21 run died at
recoveryReportWiring, which hid sandstormMigrationBridge, which hid whatever is
behind that. One stale guard per full test run, found one at a time.
tests/run-node-suites.cjs replaces the chain:
* it DISCOVERS the suites (tests/*.test.cjs|js and tests/unit/*), so writing
the file is registering it - the 72-suites-in-no-npm-script drift cannot
come back, and neither can a hand-maintained 260-entry line;
* every suite runs even when an earlier one failed, and the failures are
listed together at the end, so one run tells you everything that is broken;
* each suite still runs in its OWN node process, so a suite that throws,
exits or leaves a handle open cannot affect the next one;
* a per-suite timeout (5 min, WEKAN_SUITE_TIMEOUT_MS) means a hanging suite
fails that suite instead of hanging the run;
* output streams live and unchanged, so the " ok - " progress counter still
moves; `--list`, `--bail` and substring filters are there for working on one.
Discovery was compared against the old chain before switching: the same 260
suites, nothing gained and nothing lost.
build.sh reads the runner's own "===== node suites: N run, M failed" line for
the failure count now - exact, instead of guessing from error text - and falls
back to counting the failing suites it has already listed while the run is still
going. The note about the && chain is gone with the chain.
testsAreRegistered now guards the runner rather than a list: every suite on disk
is discovered, the only exclusion is the mocha entry point, every exclusion
carries a reason, and the loop does not stop on failure unless --bail was asked
for.
Thanks to xet7 !
The Chromium run failed 16 of its first 17 tests, each burning the full 60s
timeout inside the fixture: "Test timeout of 60000ms exceeded while setting up
boardPage", with the page showing "Board not found".
My own change from earlier tonight. loginWithToken installed a
page.addInitScript that removes Meteor's three Accounts keys from localStorage,
so the PREVIOUS session cannot resume and race the new login - the
33-board-domains "Unexpected userId after login". But an init script runs on
EVERY navigation of that page. So the goto right after the login, the one that
opens the board the test just logged in FOR, also started with the token
removed: the client was anonymous, the seeded board is private, and the router
answered "Board not found" - five times, 20s each, until openBoard gave up.
The one test that passed in that stretch is "user NOT added to board cannot see
it", which is what being logged out looks like too.
The clear is now ONE-SHOT: the init script does nothing unless a flag
(wekan-e2e-clear-session) is armed in localStorage, and it consumes the flag.
loginWithToken opens /sign-in, arms the flag, reloads - so exactly the one page
load the login happens on has nothing to resume - and every later navigation
keeps the session it just established. It still clears only those three keys;
board view, list widths and the settings specs' own localStorage are untouched.
tests/playwrightLoginSession.test.cjs pins it: the clear must be conditional and
self-disarming, it must not wipe anything else, and arm/reload must come before
the token login.
Thanks to xet7 !
tests/sandstormMigrationBridge.test.cjs failed the whole node suite with "bridge
is released BEFORE the importer binds the port". The ordering in
sandstorm-src/start.js is correct and unchanged; the guard was anchored on
`spawnSync(NODE, [IMPORTER]`, and every spawn in start.js now goes through
cpuExec() - `spawnSync(...cpuExec(NODE, [IMPORTER]), ...)`. indexOf returned -1,
and "stopBridge is before -1" is false. It now anchors on WHAT is spawned
(/spawnSync\([^\n]*\[IMPORTER\]/) and asserts each anchor was found, so a guard
about ordering cannot fail again because of how a process is started.
The run summary was also lying twice about that failure:
- fail:2 for ONE failure. The counter matched both "AssertionError" and the
"throw err" line of the same node dump. It now counts a suite's own
" FAIL - <name>" lines plus one per Error dump, anchored at the start of
the line so the stack frames below it are not failures of their own.
- tests:508 fail:2 read as if all 258 suites had run. npm chains them with
&&, so node stops at the FIRST failing suite and every suite after it never
starts - here about 200 of them. The unit job now says so when it fails.
Thanks to xet7 !
Both legs failed on every release, and not because of a secret or a flake:
##[error]Your build requires a base that this tool does not support (core24).
'base' or 'build-base' in your 'snapcraft.yaml' must be one of 'core',
'core18' or 'core20'.
They were built by snap-qemu with diddlesnaps/snapcraft-multiarch-action, whose
compiled dist/index.js caps at core22 in three independent places, whose build
image has no :core24 tag, and which is unmaintained. WeKan's snapcraft.yaml is
base: core24, so the build died the instant snapcraft read it - after the
version gate passed and QEMU had set up. There is no maintained QEMU multi-arch
snap action that does core24; Canonical's answer for an architecture with no
native runner IS Launchpad remote-build. The evidence, read out of the action's
source rather than off the error string, is in
docs/Design/Autoupdate/Forks/Snap-Core.md.
So: snap-launchpad's matrix is now [ppc64el, s390x, riscv64], and snap-qemu is
deleted rather than disabled.
These two arches once left Launchpad for QEMU because the old remote-build legs
ended in Launchpad state "Stopped" with no snap and then failed at snapcraft
upload ("is not a valid file", exit 64). Today's snap-launchpad job is what
those legs were not: it retries the remote build 3x, requires the .snap file to
exist, and uploads only when it is there. It stays continue-on-error,
fail-fast: false and timeout-minutes: 180, so the price of this path - a
Launchpad queue that can last hours - can neither fail the release nor cancel
another architecture, and each arch publishes the moment it finishes.
It needs LP_CREDENTIALS as well as SNAP_AUTH, which ppc64el and s390x did not
need before. Its first step names either secret when it is unset and decodes
LP_CREDENTIALS, and the remote-build step says by name when Launchpad answers
unauthorized - so a credential problem is one named line, not an ordinary
-looking build failure.
New guard test tests/releaseSnapArches.test.cjs pins it: no snap-qemu job and no
use of the core22-capped action, every platform in snapcraft.yaml built by some
job, the exotic three on Launchpad, the non-blocking options, both secret checks,
and the no-.snap-no-upload rule.
Thanks to xet7 !
The Tests menu had "ALL tests, parallel", "ALL tests, sequential" and, eleven
entries below them, "EVERYTHING (sequential)" - and nothing said what the
difference was. "ALL tests" runs WeKan's own suite only: Mocha, the node unit
suites, the import regression, the node E2E harness and the three browsers.
"EVERYTHING" runs that, then the database conformance run for every database
with a Docker image for this CPU, then all of FerretDB's own tests. Two entries
claiming to be all of them, one of which is not.
Now the everything-run is entry 1 in both build.sh and build.bat, the other two
are named "WeKan's own tests only" and their descriptions end with what they do
NOT cover, and every option says where its logs go.
Every option in the menu now also WRITES those logs: a new one_log helper in
build.sh (:onelog / :tee in build.bat) puts Mocha, the import regression, node
E2E, each Playwright browser, the floating-promises guard and the test counts
into ../log/<datetime>/ beside the whole-suite runs. It reuses WEKAN_LOGDIR when
a larger run set one, so a run stays in ONE directory. Before this, running a
single option left nothing to check afterwards - "check the newest test logs"
only worked for the whole-suite runs.
The .bat prompts stay outside the tee: PowerShell's Tee-Object buffers the
pipeline, so a piped "[y/N]" prompt is never shown.
The guard test pins the order and the wording: entry 1 must be the everything
-run, entries 2 and 3 must not claim to be ALL tests, and both scripts must log
every option.
Thanks to xet7 !
Two entries in build.sh and build.bat.
"Run all FerretDB tests - SEQUENTIAL" runs the FerretDB subdirectory's own
build.sh test-all: unit, vet and the integration suite, one at a time. FerretDB
is expected inside this repo - the "All databases" option clones wekan/FerretDB
when it is not there - and if it is missing this says so with the clone command
rather than failing obscurely.
"EVERYTHING (sequential)" runs the three suites one stage at a time: WeKan's own
tests (which build a fresh bundle and start a server), then the database
conformance run (which builds FerretDB from source and runs one query catalogue
against every database with a Docker image for this CPU), then all of FerretDB's
tests. They share ONE ../log/<datetime>/ directory - passed down as WEKAN_LOGDIR
- so a run that touches three test systems still leaves its logs in one place,
and it ends with a three-line verdict.
Nothing runs concurrently, and the menu text says so: this takes a long time,
and the reason to run it is to find out what is broken, which needs readable
output more than it needs speed.
build.bat runs releases/run-everything.sh rather than reimplementing any of it:
the WeKan stage builds a Meteor bundle and runs a server, which needs a POSIX
shell throughout, and a second implementation would drift. That script is also
the non-interactive way to run it on any platform.
Thanks to xet7 !
WeKan runs on MongoDB or on FerretDB v1 over SQLite, PostgreSQL, MySQL, MariaDB
or SAP HANA, and each answers a broken query, a full disk or a refused login in
its own words. Those words reached an admin as an opaque string: "Error 1064
(42000): You have an error in your SQL syntax" with no way to know which
database said it, that it is FerretDB's bug rather than their data, and that
upgrading FerretDB is the fix.
models/lib/databaseErrors.js is the translation - pure, so it is unit-tested
without a database: a message in, and out comes which database said it, what
kind of problem it is, what it means, what the admin should do, and whether
WeKan can do anything itself. Sixteen rules, every one of them a message a real
database produced in the conformance runs or the documented wording of the
condition: injection refused by FerretDB's SQL guard, the syntax errors of all
four dialects, the two permission failures that stopped MySQL and MariaDB dead
this week, authentication, disk full, connection limits, deadlocks (retried),
lost connections (reconnected), timeouts, duplicate keys (which is an index
doing its job, not a problem), unimplemented operations, and a handler the
binary was not built with.
server/lib/databaseProblems.js records them into a new `database` event stream,
one per problem per minute - a database that is down answers every query - and
watches Meteor._debug, which is where a database error surfaces without wrapping
every call site in the app. Admin Panel / Problems has the pane, and its first
column is the database that said it.
Thanks to xet7 !
They are after the v10.44 release commit, so they open a new Upcoming section
rather than joining the release that was prepared before them.
Thanks to xet7 !
The v10.43 run failed five jobs. Two of them were mine.
build-win64 failed with "wekan-10.43-win64.zip has no bundle/main.js" four
lines after 7-Zip reported writing a 283 MiB archive of 46014 files. The zip
was fine; the check I added last night was not. 7-Zip lists Windows paths with
backslashes, and I searched for them as a REGULAR EXPRESSION - where
"bundle\main.js" means "bundlemain.js", which nothing is called. It would have
failed on every release. The listing is taken once now and searched as a fixed
string, for either separator; both forms were replayed in bash to be sure the
old one matches nothing and the new one matches 7-Zip's own output.
snap-variants did all the work and died on the last push:
"remote: Permission to wekan/wekan-gantt-gpl.git denied to xet7". Its guard
checked that WEKAN_REPO_TOKEN was SET, and set is not the same as allowed - so
a full snap build burned before the token was found wanting. It now asks GitHub
whether the token can push to that variant repository, and skips with a named
reason if it cannot. That does not grant the rights: the maintainer still has
to widen the token, which ../log/workflow/TODO.txt explains.
The other three failures are not the workflow's: ppc64el and s390x cannot be
built by an unmaintained QEMU action that caps at core22, and the variant
pushes need a token that may write those repositories.
Thanks to xet7 !
The conformance report said postgresql and sqlite disagreed on five update
cases and on explain. They did not. $currentDate writes the clock into a field,
every later case in that group returns the whole collection, and the two
backends ran a minute apart - so one server-written timestamp made five cases
"different". Volatile fields are recorded as their type everywhere now, not
only in the case that wrote them. And an explain plan is a different plan on
every engine, keys and all, so comparing its SHAPE reported a difference for
the one thing that cannot be the same; it only has to answer.
MySQL and MariaDB could not run at all: "Access denied for user
'ferretdb'@'%' to database 'conformance'". FerretDB maps each MongoDB database
to a SQL database and CREATES it on demand, which a grant on one database
cannot allow - so this was not a test problem: WeKan on the MySQL/MariaDB
compose files would have failed on its first write to the `wekan` database.
FerretDB connects as root in both compose files and in the conformance run,
with the reason written next to it; the per-database user still exists for
anything else that reads the data.
Playwright 33-board-domains failed again, this time in Chromium: "Unexpected
userId after login". The logout-first fix was not enough, because the race is
earlier - accounts-base reads localStorage at startup and logs the stored user
back in asynchronously, so the sequence could be: page loads, our check sees no
user yet, we log the new user in, and THEN the resume completes and puts the
old user back. The three Accounts keys are removed before any script runs, so
there is nothing to resume, and any login still in flight is waited out before
the state is read.
And a unit test that had been failing since the Admin Panel pane headings
moved: recoveryReportWiring still wanted `titleKey: 'recoveryReportTitle'` in
the report spec, which was removed on purpose - every pane's heading is
rendered once, from its menu entry. The test now pins that, and that the table
does not repeat it.
Thanks to xet7 !
Three things the first run on arm64 found.
The FerretDB it built could not start: `panic: commit.txt value ... !=
vcs.revision value ...`. Go stamps the VCS revision into the binary and
FerretDB's build/version panics when it disagrees with the committed
commit.txt, which only the generator refreshes - so every commit made after the
last refresh built a binary that panicked. Fixed in the fork (its act_build now
regenerates them, as act_dist already did).
Ports: FerretDB listened on 27017, which is where a dev server's database lives
and where the compose files publish FerretDB - so this could not run beside
anything else and, worse, could have pointed the tests at somebody else's
database and rewritten it. It listens on 37017 now and publishes the database
server on 35432, both moved on if busy, both overridable with
WEKAN_CONFORMANCE_PORT and WEKAN_CONFORMANCE_DB_PORT, and its containers are
named per run so a compose stack is never reused or stopped.
And Ctrl-C only killed whatever was in the foreground - a registry lookup, a
sleep - after which the loop carried on and reported the interrupted lookup as
"NO linux/arm64", which is a lie about the image. An interrupt ends the run now,
and the image check has three outcomes rather than two: has it, does not have
it, could not ask. A FerretDB that will not start also prints the last lines of
its log, because the reason is usually one line.
Thanks to xet7 !
It is after the v10.43 release commit, so it opens a new Upcoming section
rather than joining the release that was prepared before it.
Thanks to xet7 !
FerretDB v1 translates one MongoDB query into five different SQL dialects, so
"WeKan starts on MariaDB" says very little. The question that decides whether a
backend can be trusted with a board is whether {n: {$gt: 5}} returns the same
documents, in the same order, as it does on SQLite - and nothing was asking it.
./build.sh -> Tests -> "All databases (sequential)" now does, and build.bat has
the same entry (running the same script through bash rather than a second
implementation that would drift).
It builds FerretDB v1 from source first: the FerretDB subdirectory is cloned
from git@github.com:wekan/FerretDB if it is not there, updated if it is, and
built through its own build.sh, which installs the Go toolchain and the module
dependencies when they are missing. The tests run against THAT binary, not a
downloaded release, so they test the newest code.
Then, for each backend whose database image has a build for THIS CPU - asked of
the registry with docker manifest inspect, so no table here can go stale - it
starts that database, runs the freshly built FerretDB against it, runs the whole
catalogue and stops everything. Sequential, because they all use the same
FerretDB port and a database under test should not be competing with three
others; the menu entry says so.
The catalogue is 100 cases in 15 groups, taken from FerretDB v1's own handler
sources rather than from MongoDB's manual: every query, update and bitwise
operator, the aggregation stages and accumulators, projection and sorting and
paging, count and distinct, indexes and uniqueness, capped collections (which is
how the OpLog exists at all), and the commands whose answers may legitimately
differ. The seed data is deliberately awkward - a null, a missing field, a
negative number, a zero, an empty array, an array of documents - because tidy
data lets a broken translation pass.
Answers are normalised and compared byte for byte against SQLite, so document
ORDER counts. Three cases are compared loosely and say so: an explain plan
differs per engine by definition, and collStats/dbStats are sizes a different
storage engine may answer differently. Two backends failing the same way is
agreement about a limitation; one answering where another fails is a difference.
Everything lands in ../log/<datetime>/ with every other test run: a JSON of what
each backend answered, each backend's container output, the build log, a summary
and db-conformance-report.md. SAP HANA is opt-in behind WEKAN_CONFORMANCE_HANA=1
- amd64-only, ~16 GB of RAM, and SAP's licence to accept - so a menu choice
cannot start it by accident.
Thanks to xet7 !
Every commit since v10.42 was already listed, but three of them were in the
wrong place: entries had been added at the top as they were written, so a new
feature (the FerretDB v1 compose files) and two documentation entries sat under
"This release fixes the following bugs".
CLAUDE.md gives the order - new features, then bug fixes, then developer-facing
changes, then documentation - and one "This release ...:" header followed by
"and ...:" for the rest. The section now reads that way: new features, bugs,
release tooling, the developer-facing test, documentation, and the closing
thanks line. One sentence that said "the pagination fix above" says "below",
because the entry it points at moved.
Thanks to xet7 !
The page listed images and requirements, which left the reader to work out the
pattern themselves. There is a pattern: the databases are not fifteen separate
questions but seven families, and inside a family the answer is the same one.
Each family now says what IT is missing. PostgreSQL-wire and MySQL-wire need no
code at all, only a live run against their dialect - that is where CockroachDB's
s390x image could be won. Enterprise SQL needs a whole backend each, and the
driver is the obstacle only for Db2, whose cgo-only driver cannot be in a
nine-architecture build. Embedded databases need a pure-Go driver before
anything else. Columnar engines pass the driver gate and fail the second one:
WeKan updates single cards constantly, and they are built for the opposite.
Key-value stores would have to have indexes, filters and atomicity implemented
inside FerretDB, which is not a backend but a database. And what already speaks
MongoDB needs no FerretDB at all - the reason for this page is that on ppc64le,
s390x, riscv64 and loong64 that family has no members.
The page opens with all of it in five sentences and one table, because the
conclusion - that the most valuable work is verifying the three backends that
already exist, not writing a fourth - was previously only visible to whoever
read to the end.
Corrections while checking: Oracle DOES have a pure-Go driver (sijms/go-ora
implements the TNS protocol itself), so it is not blocked by cgo the way Db2 is;
and Cassandra belongs in the CPU table, since its image covers ppc64le and
s390x.
Thanks to xet7 !
WeKan runs on every CPU Node.js runs on, and this fork of FerretDB v1 exists
because MongoDB does not publish a server for most of them. Two questions kept
coming back: which databases even have images for those CPUs, and what would be
missing in FerretDB v1 before it could store into one.
docs/Databases/FerretDB/1/Alternatives.md answers both. The architecture table
is read from each registry's own manifest, not from documentation, and it says
plainly what that data shows: PostgreSQL is the only widely-portable database
server - the only one publishing ppc64le, s390x AND riscv64 - MariaDB covers
ppc64le and s390x, MySQL neither, and MongoDB itself and upstream FerretDB 2
are amd64 + arm64 only. This fork's own image covers nine platforms.
What a new backend needs is taken from the code: a pure-Go driver, because the
binaries are built CGO_ENABLED=0 and that is what makes one build serve nine
architectures (which is why Oracle and Db2 are out, despite Db2's ppc64le and
s390x images); the three backends interfaces, none of them stubbable; a
metadata registry; the SQL features the translation actually uses - JSON path
extraction, containment and type inspection, schemas, expression indexes, a
parseable EXPLAIN, and the record-id column that capped collections and
therefore the OpLog are built on; correct MongoDB semantics on top; and a live
integration run, which is the whole difference between the confirmed and
experimental rows.
And the shortcut: a database that speaks the PostgreSQL or MySQL wire protocol
needs no new backend, only an existing one that survives its dialect -
CockroachDB brings s390x that way, for the price of a test run.
Thanks to xet7 !
It was a flat list where the database was a filename prefix, in three spellings
- MongoDB-Driver-System.md, mongodb-avx-qemu.md, MongoDB_OpLog_Enablement.md -
plus FerretDB2-PostgreSQL.md and a ToroDB-PostgreSQL directory. Somebody asking
"how do I run WeKan on PostgreSQL" had to read the prefixes to find out which
files were even about their database.
Now: Migrations, MongoDB, FerretDB (with 1 and 2, because v1 and v2 are
different products with different backends) and ToroDB (with PostgreSQL). Each
file keeps its name minus the redundant prefix - MongoDB/Driver-System.md,
MongoDB/avx-qemu.md - and the old PostgreSQL.md, which was an index of FerretDB
and ToroDB rather than a document about PostgreSQL, becomes the directory's
README.md.
Every directory has a README.md saying what is in it and where to go next,
including FerretDB/1, which had no documentation at all until now although it
is WeKan's default database and just gained four more backends. Links to a
directory point at the DIRECTORY, not at its README.md, because README.md is
what is opened by default.
Every link that pointed into the old paths is updated - in docs, in
docker-compose-ferretdb-v2-postgresql.yml, and in the wekan.fi website - and
the relative links inside the moved files, which gained a directory level and
so needed one more "../". tests/docsDatabases.test.cjs pins the layout, the
READMEs, the directory links, that every relative link resolves, and that
nothing outside CHANGELOG.md still names an old path.
Thanks to xet7 !
docker-compose.yml runs FerretDB v1 on its embedded SQLite. The same FerretDB
can store into PostgreSQL, MySQL, MariaDB or SAP HANA instead, and there was no
compose file for any of them, so those backends were reachable only by editing
the default file by hand.
There is one per backend now, and they differ ONLY in the database: the same
WeKan image, the same ~700 lines of environment and the same comments
explaining them. They are generated from docker-compose.yml rather than copied,
and tests/dockerComposeBackends.test.cjs compares the WeKan service of each
against the default file line for line - a copy drifts on the first setting
somebody adds to one file, and then a user following the PostgreSQL file gets a
differently configured WeKan than the SQLite file gives them.
Each names its own database service, runs FerretDB with the matching --handler,
and says at the top how to start, follow and stop THAT file with docker compose
-f. The images are the newest published: postgres:18, mysql:9, mariadb:12 and
SAP's saplabs/hanaexpress, with the LTS alternative named in a comment where
there is one. PostgreSQL is confirmed working with Meteor 3; MySQL, MariaDB and
SAP HANA are marked experimental in their own headers, because they are.
build.sh and build.bat offer every docker-compose*.yml in the repo now, not
four of the eight, and the test fails if a file exists that neither menu can
start - or if a menu offers a file that does not exist.
Thanks to xet7 !
Four commits since the v10.42 release commit had no entry: the three
release-all.yml changes and the per-tenant report test. They are in Upcoming
now, under "and has the following release-tooling changes:" and "and has the
following developer-facing change:", each linking its own commit, and the
section closes with the usual thanks line.
The pagination entry linked 6eca44c84, which is no longer in main: "Bump
versions for v10.42" landed underneath it and rebased it to c1add5bc5. A link
to a commit that is not in the branch 404s on GitHub, so it is corrected.
And a rule from CLAUDE.md that had been broken in the v10.40 section: a link
whose text was the hash b3537985e. The hash tells a reader nothing they can
act on - the link text says what it points at now. tests/changelogFormat.test.cjs
asserts there are none of those anywhere in the file, so this was a failing
test, not only a style slip.
Thanks to xet7 !
The workflow could fail in ways that left no explanation, or no failure at all:
a version bump that committed nothing, a release published with empty notes, a
zip that exists but holds no bundle/main.js, an upload that reports success and
leaves no asset behind, and a multi-arch image whose manifest is missing a CPU
- which nobody notices until a user on that CPU is told there is no matching
manifest.
Each of those is checked now, and each check says the same three things when it
fails: what was expected, what was actually there, and what to do about it. On
success it prints one "OK: ..." line naming what it verified, so the log shows
what worked and not only what did not.
Every job also ends with a "Job result" step that runs whatever happened, so
the run summary is one line per job - OK, FAILED or CANCELLED - instead of
eighteen logs to open. It is explicitly `shell: bash` because the same step
runs on the Windows and macOS runners.
Thanks to xet7 !
Only three jobs said anything about their secrets. Everywhere else a missing
one surfaced deep inside a tool, as a login that was refused or a checkout that
404'd, with nothing naming the secret - and the docker job did it after the
multi-arch build had already spent half an hour producing an image it could
not push.
Every job that needs a secret now checks it in its FIRST step and names what
is missing. Where the answer is cheap, it also checks that the secret WORKS,
which is the other half of the question: WEKAN_REPO_TOKEN is asked whether it
can push to the repo it is for (HTTP status, then permissions.push), the three
registry credentials are decoded and logged in with, and the base64 ones -
SANDSTORM_KEYRING, LP_CREDENTIALS - must decode to something.
What only the far end can answer is answered where it is used: the Snap Store
uploads now name SNAP_AUTH when they are refused (including the two that are
`uses:` actions, through a step that runs on their failure), and a Launchpad
build that fails with an unauthorized in its log says LP_CREDENTIALS may be
the reason.
Thanks to xet7 !
Admin Panel / Problems is instance-wide, so every report publication and count
method asks for the SITE admin flag user.isAdmin - not canOpenAdminPanel,
which a per-tenant Global Admin passes - and 'problems' is not one of a tenant
admin's tabs. That is what keeps the Boards and Files reports honest now that
they cover the whole instance instead of the admin's own boards.
The one admin list a tenant admin does get, People, is tenant-scoped in all
three places that decide what it shows: the publication, the new page-ids
method and the count all go through peopleScopeSelector, so its pager cannot
count rows its page may not show. Organizations is the same through
orgScopeSelector; Teams is site-admin only and is not one of their panes.
Thanks to xet7 !
snap-qemu (ppc64el, s390x), snap-launchpad (riscv64), snap-variants, ucs and
nextcloud were hard-disabled with `if: ${{ false }}`, so a release never said
anything about them. They all carry continue-on-error: true, so running them
cannot fail a release or hold up another job - the point of running them is to
SEE what they report.
The three guarded jobs - snap-variants, ucs, nextcloud - skip their work while
their secrets are unset. That was a quiet ::notice::; now that they actually
run it is a ::warning::, so the missing secrets are visible in the run summary
instead of buried in a log.
Thanks to xet7 !
Boards Report was empty while the Cards report beside it listed cards from
thousands of boards. It published userBoardIds(this.userId) - the boards the
ADMIN is personally a member of - and on an instance whose admin is not a
board member that is nothing at all. Until the pagination fix the pane hid
this: it rendered every board in minimongo, which the All Boards page had
already put there. The Files report was scoped the same way, to the cards the
admin can access.
Both now cover the whole instance, like Cards, Broken cards, Rules,
Impersonation and Recovery already did. The membership selector was what kept
those two publications honest, so both gained an isAdmin guard at the top -
boardsReport asked only for a logged-in user before - and both count methods
count the same set they page.
Files and Rules also name their page now, like the other reports: opening one
card puts its attachments in minimongo and opening a rules editor puts that
board's rules there, and neither belongs in a report page. The Files page is
sorted by name - paging with no sort is paging over natural order, where a
document can appear on two pages or on none - and that sort has an index now.
Thanks to xet7 !
Admin Panel / People showed the admin on every one of its 578 pages, and
Admin Panel / Problems / Broken cards was one endless page under a pager that
said "1 / 1". Same bug in two shapes: the pane subscribes to a publication
that sends exactly one page, then reads the page back out of minimongo - which
holds far more than the page. The logged-in user's own record is always there
(accounts publishes it), and so is every card of every board the admin has
opened. A plain find(query) cannot tell those apart from the page.
So the server names the page. getPeoplePageIds returns the ids of the People
page with the publication's own selector, sort and window; the Broken cards,
Cards and Boards report publications send the ids of the page they just sent
alongside it. Both panes render that list, in that order, and nothing else.
Every paginated page in WeKan now loads ten rows at a time, from one constant -
TABLE_PAGE_ROWS_PER_PAGE - including the pages that draw a pager of their own:
the reports and event streams, the four People panes, Translation, the search
pages and the archive. docs/Design/Page/Table.md records the rule and its two
deliberate exceptions.
And the counting behind those pagers is index-backed. Every count already asks
the database for a count rather than fetching the rows, but several counted and
paged on unindexed fields: People sorts users newest-first, so on an instance
with 14000 users each page of ten sorted all 14000 first. Broken cards asks an
$or over boardId/swimlaneId/listId/type, which uses no index at all unless
every branch has one. The missing indexes are created at startup by the
idempotent ensureIndex, so an upgrade adds them by itself.
Thanks to xet7 !
Every popup had 10px of empty space above its content that nothing in
popup.css asked for: peopleBody.css and translationBody.css each carried a
bare `.content-wrapper { margin-top: 10px }`, and `.content-wrapper` is not a
settings class - the only element in WeKan with that class is the scrolling
body of a popup. Removed, and the remaining gap is now 6px under the header
plus 12px of content padding = 18px, exactly the 18px beside the first row.
Change Visibility and Change Watch lay their rows out as three left-aligned
columns, so the icons, the names and the descriptions line up and the check
mark of the active row can no longer push its description out of line.
And the second header bar centers its items: symmetric block padding instead
of 7px above and none below, no top margin on the button groups, and a title
that centers on its own text - which is what made the board title sit high.
The sidebar hamburger has equal side margins, so it sits in the middle of the
space between its divider and the end of the bar.
Thanks to xet7 !
From the dev-server log, on a plain attachment upload:
[onAfterUpload] filename hardening failed: TypeError: Cannot read properties
of undefined (reading 'gridFsFileId')
at FileStoreStrategyFactory.getFileStrategy (models/lib/fileStoreStrategy.js:112)
at detectStoredFileMime (models/lib/fileTypeCorrection.js:120)
at FilesCollection.onAfterUpload (models/attachments.server.js:215)
`getFileStrategy` decided the storage like this:
storage = fileObj.versions[versionName].storage;
if (!storage) {
if (fileObj.meta.source == "import" || fileObj.versions[versionName].meta.gridFsFileId) {
A freshly uploaded file has no `meta` on its version - only a GridFS one does -
so that last read threw on EVERY upload. onAfterUpload catches and logs, so the
upload itself succeeded and looked fine, while the two things that hook does were
silently skipped for every new file: detecting the real mime type and correcting
the stored filename from it. `fileObj.meta` can be absent the same way, and so
can the version itself when a caller asks for one this file does not have.
All three reads are defensive now, and the decision is unchanged where the data
is there: a stated storage wins, an explicit argument wins over that, an import
or a GridFS version is still GridFS, and everything else is the filesystem.
tests/fileTypeCorrection.test.cjs replays that decision table, including the
document shape from the log (a version with no meta), a missing version, and no
file object at all - and fails if the unguarded read comes back.
Thanks to xet7 !
The node suites got four assertions further than last time and stopped in the
same file: two more cpuExec expectations still spelled the qemu-wrapped command
as a bare name. cpu-exec resolves it to an absolute path now (qemu-user opens the
file it is given and does not search PATH), so the multi-feature and
WEKAN_QEMU_USER cases assert the resolved path like the other two. The whole
suite was replayed through bash here: all nine cases pass.
WebKit failed 33-board-domains with "Unexpected userId after login" - the admin's
id, when the test had just switched to the non-admin. loginWithToken called
Meteor.loginWithToken over a session that was still logged in as someone else, so
`Meteor.userId()` could remain the OLD user while the new login was in flight,
and the poll could not tell "not landed yet" from "landed on the wrong user": it
timed out and reported the old id as a mismatch. It now logs the previous user
out first and waits for an empty session before logging the new one in, and the
settle deadline is 15s rather than 5s, since a run with three browsers and WebKit
in Docker is slow. Not a product bug - the switch is only done by tests - but a
flaky harness costs a real run every time.
Thanks to xet7 !
Reported after upgrading from WeKan 6 to 10.37/38/40: an attached image is
visible in board view, downloads correctly from the card, and yet the card view
shows an empty white box that cannot be maximized. Cards created AFTER the
upgrade are fine.
The card view does not look at the file; it looks at the flags Meteor-Files
writes at upload time:
if(isImage) img.attachment-thumbnail(src="{{link}}")
...
else span.attachment-thumbnail-text= extension
An attachment that came through a migration can arrive without them - no
isImage, and often no `extension` or `type` either - so it fell through to the
last branch and printed an extension that was not there: an empty box. The same
`link` in the download button worked, because a download needs no flag. The
viewer refused to open it for the same reason.
The kind of a file is derivable, and models/lib/attachmentKind.js is now the one
place that derives it: from the mime type where the document has one (in any of
the fields that have carried it over the years - type, mime, mime-type,
contentType, versions.original.type), and from the file NAME where it does not.
A flag the document states as true is believed, never contradicted; the name is
consulted only when there is no stated type, so a notes.txt that really is
image/png stays an image and does not also become text. The card gallery, the
"add cover" menu and the viewer all ask it, so a thumbnail that renders can also
be opened.
A startup repair (schema upgrade step `attachment-kind-flags`) writes the same
answer back to the documents, so the REST API, the exports and everything else
reading those flags agree with what is on screen. A file whose kind cannot be
told from either its type or its name is counted as unresolved rather than
guessed at.
tests/attachmentKind.test.cjs pins the rules - the reported case first - and the
wiring: 17 kinds derived from a name alone, mime beating a misleading name, a
name that must not be trusted to be a plain name (path separators, query
strings, dotfiles), the type read from each of the fields that carry it, and a
repair that writes exactly what is missing and nothing else.
NOT verified here: no server and no node in this environment, so the rules were
replayed against a model of the module rather than executed. That replay caught
three real mistakes in the first draft (a query string eating the extension, a
name overriding a stated type, and the repair rewriting a document that was
already correct), which are fixed.
Thanks to S0QR2 and xet7 !
Fixes#6532,
First real run of the node suites in "Run ALL tests" (they had never run
anywhere until yesterday's change) and cpuExec.test.cjs failed on this machine -
which is what that change was for. Two real things behind it.
qemu-user does NOT search PATH: it opens the file it is given. cpu-exec passed
the command through unchanged, so a bare name - `cpu-exec --features
x86_64=avx mongod ...`, or `echo` in the test - reached qemu as a relative path
that does not exist and qemu exited 1 having run nothing. On a CPU without the
required feature, the very case this helper exists for, the binary would silently
not run. It resolves the name with `type -P` first (`command -v` would answer
"echo" for a shell builtin, which is exactly the name qemu cannot open), and
hands over an absolute path; an absolute path is passed through as before, and an
unresolvable name still goes to qemu so the error names it.
The test asked for "no qemu" by setting PATH=/usr/bin:/bin - which is only "no
qemu" on a machine without qemu-user installed. This one has /usr/bin/qemu-aarch64
(any host that runs foreign-arch containers does), so the negative case quietly
became the positive one and threw. It builds a PATH containing exactly the tools
cpu-exec uses, symlinked, and nothing else, so the case is the same on every
machine. It also asserts the resolved path now, and gains a test that an absolute
path is handed over untouched.
Verified by replaying the whole suite through bash here (no node in this
environment): direct exec, qemu-wrapped with a resolved path, an absolute path
unchanged, no-features exec, the no-qemu error, and another architecture's
requirements ignored.
Thanks to xet7 !
From the #6492 comments today, on WeKan 10.40 with real users:
SyncedCron: Fatal error encountered (uncaughtException):
TypeError: self._pendingRemoveFunction is not a function
at Session.send (packages/ddp-server/livedata_server.js:362:14)
at Session._stopSubscription (packages/ddp-server/livedata_server.js:823:10)
at Session.unsub (packages/ddp-server/livedata_server.js:562:12)
snap.wekan.wekan.service: Main process exited, code=exited, status=1/FAILURE
snap.wekan.wekan.service: Scheduled restart job, restart counter is at 4.
It is a state-machine hole in Meteor's ddp-server. `_removeSession` sets
`session.messageQueue = []` and `session._pendingRemoveFunction = remove`; when
`remove()` runs it clears the function and deletes the session but LEAVES the
queue - an empty array, which is truthy. `Session.send` then takes the queueing
branch for a session that no longer exists, and the message past
`maxMessageQueueLength` (100 by default) calls that now-null function. It runs
from an Immediate, via unsub -> _stopSubscription -> send, with no try/catch
above it, so it is an uncaught exception - and synced-cron's handler exits the
process on one. systemd restarts, every user is disconnected, new cards stop
arriving until a reload, and the restart loop reads as "WeKan is slow and the CPU
is high", which is exactly what the reporter describes.
It needs a busy server: a session has to disconnect while more than ~100 further
messages are still addressed to it. That is why it shows up with fifty users and
never in a quiet test.
The guard patches Session.send once, from the first connection (the Session class
is not exported, so an instance is how the prototype is reached): a queue with no
remove function belongs to a session that is already gone, so the queue is
dropped and send() takes its ordinary path - which, with no socket, does nothing.
Nothing is lost that was not already lost, the disconnect-grace queue for a real
reconnect is untouched, and a valid overflow still removes the session.
tests/ddpSessionSendGuard.test.cjs replays the upstream state machine: it asserts
the unguarded version really does throw on the 101st message, that the guarded
one does not, that a session still waiting for its client keeps its queue, that a
legitimate overflow still calls the remove function exactly once, and that a live
session sends as before.
NOT verified here: there is no server in this environment, so this is reasoned
from the ddp-server source in .meteor/local and replayed against a model of it.
The high CPU the issue opened with is a separate thread (the FerretDB
$changeStream busy loop); this fixes the crash-restart loop reported today.
Thanks to bluetopaz1204, Nissulya and xet7 !
Fixes#6492,
WeKan used colourful Unicode emoji as its icon set in 8.00-8.24 only; before and
after, the icons are Font Awesome 4.7. A handful of emoji had survived that
change - every notification type, the board star, the vote-against thumb, the
spent-time badge, the reaction and add buttons, the list width toggles, the
bookmarks star, the back arrow, the custom-field pencil, the notification bin,
the sidebar's plus and hash, the four date badges in cardDate.css and
minicard.css, the mobile drag handle, the multi-selection tick, and the gantt
day markers. Each of those is a different picture on every platform, at a size
and colour the stylesheet does not control. They are Font Awesome glyphs now:
either an `i.fa` element, or the codepoint (`content: "\f11e"`) with the font
named, since `time::before` is not an `.fa` element. The helpers that produced an
emoji return a class name instead, and their templates render an `<i>`.
"Grey Icons" in Member Settings existed to grey exactly those emoji. It ran a
MutationObserver over every rendered subtree, for the whole session, wrapping any
text node that was one of ~50 emoji in a span it could greyscale - and only 13 of
those emoji were still anywhere in the app. With them gone it has nothing left to
find, so the feature is removed whole: the menu entry, the click handler, the
`toggleGreyIcons` method, the `hasGreyIcons` helper, the `profile.GreyIcons`
schema field and its published-fields entry, the `userGreyIcons` publication and
its subscription, unicode-icons.js/.css and the feature import, twelve
`body.grey-icons-enabled` CSS rules across six stylesheets, the `grey-icons`
string in all 147 language files, the field in public/api/wekan.yml and
wekan.html, and the two mentions in docs/DeveloperDocs.
The language flags in the language picker stay: Font Awesome 4.7 has no flags.
tests/fontAwesomeIcons.test.cjs fails on an emoji in any template or any CSS
`content:`, checks the date badges name the font and use the four codepoints,
checks the icon-producing helpers return class names, and checks that no part of
the removed feature is left anywhere.
Thanks to xet7 !
Two gaps, and together they meant most of the test suite never ran anywhere.
The flow ran six jobs - mocha, the import regression, the Node E2E harness and
the three browsers - and no npm unit script at all. Everything in
`test:unit:node` and `test:unit:all` was therefore never executed by "Run ALL
tests": that is the ~165 .cjs guards plus the sticker, Trello and OAuth2 suites.
A guard that never runs guards nothing, and several of those were written to fail
the suite when a fix regresses. Both scripts now have a `unit` job that runs
`meteor npm run test:unit:all`. It needs no server and no browser, so it starts
beside Mocha and the import regression in the parallel flow, and takes its own
step in the sequential one; it is counted, waited for and reported in both, with
its own ../log/<run>/wekan-alltests-unit.log.
And the scripts themselves were incomplete: 72 suite files existed that no npm
script mentioned - addCardTabSubmit, apiLogout, boardRepair, exportHTMLXss,
ldapPasswordLoginGuard, oidcProfileMerge, userDeletionCleanup and 65 more. They
are all in `test:unit:node` now; `tests/rtl.test.js`, which documents itself as
runnable by node, joins `test:unit:all`. `tests/all.test.js` stays out on purpose:
it is the Meteor mocha ENTRY POINT that imports the two suite indexes, and it runs
under `meteor test`, which is the mocha job.
tests/testsAreRegistered.test.cjs - which already caught suites missing from the
mocha indexes - now also fails when a plain-node suite is in no npm script, and
when the ALL-tests flow stops running that script. tests/buildScriptParity.test.cjs
pins the job in both files: the command, the launch, the key sets, the label, the
counter, and in the .bat both flows starting it, waiting for it and reporting it.
NOT verified here: there is no node in this environment, so those 72 suites have
never been executed anywhere. Some may fail on the first real run - that is the
information this change buys, not a regression it introduces.
Thanks to xet7 !
The two strings the #6531 setting added - the Member Settings entry and the
sentence explaining what OFF does - were the English source in every language,
which is what the pull leaves behind for a string that is untranslated
everywhere.
They are translated directly, per CLAUDE.md: written here, from each language's
own existing translations, with no external service. The word for "card" is the
one that file already uses - kortti, Karte, carte, tarjeta, cartão, scheda,
kartica, картка, карточка, כרטיס, بطاقة, कार्ड, カード, 카드, 卡片, kadi, ikhadi
- so the new strings read like the rest of the file rather than like a
dictionary.
142 languages, and English plus its 11 en-* variants keep the source by design.
Only placeholders were touched: a file whose value already differed from the
English source was skipped, so no human translation could be overwritten - which
is also why the count of files written is 135 rather than 142 (seven of them are
symlinks to a language already written). The two keys are the only thing that
changed in the whole directory, key order and the 2-space indent are untouched,
and every file still parses.
These stay LOCAL: filled strings are never pushed to Transifex, so none of them
can masquerade there as a human translation.
Thanks to xet7 !
Its upper part - the panel title, the tabs, the members row - was underneath the
two header bars, so the sidebar appeared to start in the middle of itself.
On a phone the sidebar is `position: fixed`, and it has to be: the board behind
it is wider than the screen, so an absolutely-positioned sidebar pins to the far
right of the BOARD and shows as a narrow strip. But fixed means "against the
viewport", and it was pinned at `top: 0` - the top of the screen, which is where
the header bars are.
There is no number to put there. The header is the quick-access bar plus a board
bar whose buttons wrap to one, two or three rows depending on the language and
the window width; every fixed value would be wrong for some of them. So the
header measures itself: client/lib/utils.js publishes its rendered height as
`--wekan-header-height` and the sidebar starts at that. A ResizeObserver keeps it
current, because the buttons re-wrapping does not fire a window resize; an
orientation change and a window resize are handled too, and a missing header
means 0 - the old behaviour - rather than a thrown TypeError.
tests/sidebarBelowHeader.test.cjs pins the rule and the measurement, including
that `top: 0` does not come back.
Thanks to xet7 !
The guard replaced `check(boardId, String)` with `Match.test(...)`, and every
subscription then failed with
Exception from sub board id ... Error: Did not check() all arguments during
publisher 'board'
This app runs with audit-argument-checks: a publisher that returns without having
check()ed every one of its arguments is failed by the audit, and `Match.test` is
not checking - it only asks. So the server no longer died, but no board could be
subscribed to either.
Each guarded publisher now marks its arguments with `check(x, Match.Any)` - which
satisfies the audit and cannot throw - and validates them with `Match.test`
immediately after. `board`, `boardCardsWindow` and `boardCardsLoadingMode` all do
this. Checked the other publications too: `activities` was the only other one
that looked unchecked, and it does check its argument, over several lines.
tests/publicationArgumentGuard.test.cjs now requires both halves - every argument
marked with Match.Any, and the marking before the validation - so removing the
check() again fails the suite instead of the server.
Thanks to xet7 !
From the dev server log:
Match error: Expected string, got null
at Subscription.<anonymous> (server/publications/boards.js:481)
SyncedCron: Fatal error encountered (unhandledRejection)
=> Exited with code: 1
`publishComposite('board')` starts with `check(boardId, String)`. A subscription
arrives with a null board id, check() throws, and a throw inside an ASYNC
publisher escapes as an unhandled promise rejection - which this app treats as
fatal and exits on. So one bad subscription stops the server for everyone, and
the arguments come from the client: any client can send it, logged in or not.
The app was in fact sending it itself, from a popup that read
`Session.get('currentBoard')` on a page that has no current board.
Both halves are fixed. The publisher TESTS its arguments instead of checking
them: a subscription that names no board publishes nothing (publishComposite
treats a falsy return as "no publications" and readies the subscription), so the
client gets an empty result and the process stays up. The same guard is on
`boardCardsWindow` and `boardCardsLoadingMode`, which are async publishers with
the same shape. And the client no longer sends a subscription for a board id it
does not have - the popup's Session read, two <select> values, a new board id
that may be undefined when the insert failed, and a template container with no
linked board.
tests/publicationArgumentGuard.test.cjs replays the guard for null, undefined,
empty string, a number and a selector object, checks the guard runs before the
publisher touches the id, and fails on an unguarded board subscription in the
client file this came from.
Thanks to xet7 !
The icons still took four rows - title, seven, three, hamburger - because the
rule that makes each button a flex item of the bar was in boardHeader.css, and
`#header #header-main-bar .board-header-btns-group { display: flex }` in
header.css has the same specificity and loads later. So the groups never became
`display: contents` and the whole set stayed one unbreakable item, which is also
why the hamburger after it got a row to itself. Same lesson as the button
metrics: this pair of files needs the rule in the one that wins.
Lists still stacked in desktop mode, because boardBody.css lays the whole canvas
out for a phone by WIDTH: `display: block` on the swimlane with `overflow-x:
hidden` on the wrapper, which makes every list a full-width row and drops the
"add list" form under the last list rather than beside it. That is mobile mode's
layout now. Desktop mode gets the desktop board on the same narrow window: the
swimlane is a flex ROW that scrolls sideways, so the lists run left to right and
the add-list form is the last item of that row - the right in LTR and the left in
RTL, since a row follows the writing direction rather than a hard-coded side.
tests/narrowWindowLayout.test.cjs pins both, including which file the contents
rule has to live in.
Thanks to xet7 !
Five things from the same two screenshots, and one theme: what belongs to the
MODE the user chose, and what belongs to the width of the window.
The board bar's buttons still took three rows in desktop mode. The metrics were
written in boardHeader.css, and Meteor loads client/components/boards/ before
client/components/main/ - so at equal specificity header.css's `margin: 0 6px`
won, and the 2px never applied. They are written in header.css now, with
`!important` so `.mobile-mode .board-header-btn` (9px/21px of padding on every
one of these buttons) cannot take them back either. 44px target + 2px each side =
48px: seven fit a 375px row, so eleven icons take two rows in both modes.
The sidebar hamburger was pinned to the top right corner, beside the title, with
the icons below it. It is the LAST button at the right of the last row now: in
the flow, with an auto start margin, so it never covers a button and reads as
what it is.
The user avatar was cut in half in MOBILE mode only. Same cause as the buttons:
the drag-handle toggle in the top bar is also a `.board-header-btn`, so mobile
mode gave it 42px of padding for one icon - the width the avatar needed. It is
sized for what it is now, in both modes.
Lists stacked one per row in desktop mode. That layout is chosen by WIDTH
(max-width: 800px), so a phone in desktop mode got the phone board: one list per
row instead of lists side by side. The stacking rules are `body.mobile-mode` now
- the same class the rest of the mobile board layout uses.
The minicard's drag handle sat near the bottom of the card in desktop mode. The
full-height thumb column is chosen by `pointer: coarse`, which is true of a
finger whatever mode the user picked; in desktop mode the compact handle in the
corner, under the menu button, is what belongs there. That block is scoped to
mobile mode as well.
tests/narrowWindowLayout.test.cjs follows all five, including that the button
metrics live in the file that wins and that the mode-based rules are mode-based.
Thanks to xet7 !
Eleven icons took three rows under the title. Each button was ~20px of icon
inside 10px of icon margin inside 6px of button margin - 52px of a 375px bar for
20px of icon - so five fitted a row.
A 44px touch target with 2px between buttons is 48px each: seven fit a row, so
the icons take two rows, and the first of those shares the title's row since the
button groups are `display: contents` there. 44px is the minimum comfortable
touch target, so this is as tight as it goes without making them harder to hit -
one row would need 34px each, which is smaller than a fingertip.
tests/narrowWindowLayout.test.cjs does the arithmetic: it fails if the metrics
stop fitting eleven icons in two rows, or if the target drops below 44px.
Thanks to xet7 !
The avatar sat above the bell and against the right edge of the screen. Its
wrapper carries `top: -5px` - a leftover from the desktop bar, where the username
sits beside it - which lifts it off the row's centre line, and `#header-user-bar`
carries 10px of padding on each side, which is 20px of a 375px bar spent on
nothing and is what pushed the avatar past the edge. Neither applies on a phone
now. The chips I put behind the mode-toggle icons cost width in the same row, so
they are trimmed from 6px of side padding to 4px.
"My Boards" had moved to the middle of the second header bar, and that was mine:
the phone rule that makes the All Boards page a flex column was written for a
bare `.wrapper`, and header.jade puts `wrapper` on #header-main-bar on every page
that is NOT a board. So the header bar became a flex column too, and the bar's
own `align-items: center` then centred its items across it. Scoped to
`#content .wrapper`: the page wrapper is inside #content, the header bar is not.
(The `height: 100vh` that rule replaced was landing on the bar as well.)
tests/narrowWindowLayout.test.cjs pins the avatar's placement and fails on a bare
`.wrapper` rule in the phone block; tests/boardListScrollChain.test.cjs follows
the scoped selector.
Thanks to xet7 !
Four things from the same two screenshots, all on a phone and all the same in
mobile mode and desktop mode, because every rule here is chosen by WIDTH.
The board's buttons started on a row of their own under the title. Every group is
one flex item - deliberately, so a long title pushes them all down together - but
that also means they move as one block even when there is room beside a short
title for several of them. On a phone the groups are `display: contents` now, so
each button is a flex item of the bar itself: they start immediately to the right
of the title and wrap only when the row runs out.
The sidebar hamburger sat on a row below the buttons, with the empty band that
goes with it. It was already meant to be pinned to the top right corner - by two
rules scoped to `body.board-view`. Nothing in this app ever sets that class:
it is written in 67 CSS rules and added by no code, so those rules have never
applied, in either mode. The width-based copy asks `:has(.board-header-sidebar-
toggle)` instead - is the hamburger there - which is the thing the rule actually
cares about. (The other 65 dead `body.board-view` selectors are left alone: they
are a separate question, and turning that class on would flip every
`body:not(.board-view)` rule in the header at the same time.)
The mobile/desktop toggle did not say which mode was on. The two icons differed
only by colour - #000 for the active one, #666 for the other - which at 14px on a
phone is no difference at all. The current mode is now a filled chip in the
active theme's accent with a white glyph, and the other side is faded to 0.35.
The avatar sat higher than the bell beside it, and its initials sat low in the
circle. The first is a 4-6px BOTTOM margin from the mobile blocks, which in a
centred row lifts an item by half of it; the bell and the avatar have no block
margin now. The second is the initials SVG: `y="11"` of a 15-unit viewBox is 73%
down, and font-size 16 in that box is taller than the box - it is `y="50%"`,
`dominant-baseline="central"` and font-size 10 now, for the user, organization
and team avatars alike.
tests/narrowWindowLayout.test.cjs pins all four, including that these rules do
not hang off body.board-view.
Thanks to xet7 !
Reported against 10.10, again against 10.37, and again against 10.38 after two
fixes that made the numbers more accurate instead of removing them. An inner
scroller only works when every ancestor between it and the viewport has a
DEFINITE height, and on a phone this chain was built out of viewport arithmetic:
.wrapper height: 100dvh - but it lives INSIDE #content,
which already begins below the
two header bars, so its bottom
sat about two bars BELOW the
screen, and it is overflow:hidden
.boards-layout (no height) - so the `height: 100%` under it
resolved to auto
.board-list height: calc(100dvh - 120px) - a guess at everything above it.
On a phone that is ~226px: two
header bars plus a search header
that wraps to two rows. The list
box therefore reached ~100px
below the screen: it scrolled
internally, but its last rows
were under the fold where no
gesture could bring them.
That is "you cannot scroll the board list", and no amount of dvh could fix it:
both the wrapper and the list were measuring the wrong thing.
There is no viewport arithmetic below `body` now. The page is 100dvh (with the
vh fallback), and from there it is a flex chain: the wrapper takes what #content
has left, the layout takes what the wrapper has left, the board column is a flex
column whose header keeps its own height, and the list takes the rest with
`min-height: 0` so it may be shorter than its content - which is what makes it
scroll. It ends exactly where the screen does, whatever the bars above it are.
The left menu is bounded the same way, and `.mobile-view` no longer carries its
own copy of the magic number, so both modes scroll by the same mechanism.
tests/boardListScrollChain.test.cjs checks every step of the chain and fails if
"viewport minus a guess" comes back; tests/mobileViewportHeight.test.cjs, which
pinned the previous attempt, now asserts the opposite for those three containers
and keeps the page-level dvh rule.
NOT verified here: there is no phone in this environment and Playwright's fixed
viewport has no browser toolbar, so this is reasoned from the source. What IS
verified is that the chain now has a definite height at every step, which the
previous two attempts did not.
Thanks to mimZD and xet7 !
Fixes#6488,
Both scripts built the bundle only when .build/bundle was MISSING - which is
exactly the case where a bundle exists and is stale. The :3000 test server runs
that precompiled bundle, so Node E2E and every Playwright browser were testing
whatever was built last time, and the run passed or failed on code that is no
longer in the working tree. That is the one thing a test run must never do.
Both now delete .build and build before starting anything, every time, and stop
with an error if the bundle is missing afterwards rather than running the suite
against nothing. build.bat gets a :rebuild_for_tests subroutine with the same
steps as its Setup "Build WeKan", called from both the parallel and the
sequential flow. The line that promised "No recompile: your existing build is
reused" is gone from both.
build.bat was also behind build.sh - the menu that is used - by two entries,
which is the drift this pairing collects:
* Dev server: CUSTOM PORT + SUBDOMAIN, asking for the port and the ROOT_URL
host, with build.sh's rule for what is local and what is proxied;
* Tests: Install Playwright browsers, natively with system dependencies (the
Docker fallback build.sh uses for WebKit on Linux arm64 has no place here).
Both .bat menus renumber and dispatch the new entries.
tests/buildScriptParity.test.cjs keeps the two together: it fails if either
script stops rebuilding before the tests, if a build.sh menu entry has no
counterpart in build.bat, if a Docker compose file one can start and the other
cannot, if a .bat menu prints numbers it does not dispatch, or if a goto lands on
no label.
Thanks to xet7 !
They were placed by whatever margin happened to win: one auto margin on the zoom
pill pushed the pill, the bell and the avatar to the end of the row as a packed
group, so the bell sat against the pill with all the empty space beyond it, and
the avatar's distance from the edge was whatever was left over - different in
mobile mode and in desktop mode on the same phone.
Below 800px - a width, so both modes get it - the free space is shared around the
bell instead: an auto margin on EACH side of it puts it midway between the zoom
pill and the avatar, and the avatar keeps a fixed 12px gap to the right edge
rather than being flung against it. Exactly one auto margin belongs to the bell
pair; the user bar's is cleared, since two would split the row and separate them
again.
Both `.iphone-device` variants are named in the selector list. That fallback sets
these margins with `!important` and two classes more than a bare id selector, so
without naming them the placement would apply everywhere EXCEPT the phone this
was reported from. The cascade was resolved property by property, shorthand
`margin` included, rather than assumed.
tests/narrowWindowLayout.test.cjs pins the two auto margins, the single fixed
gap, and that the iphone-device variants are named.
Thanks to xet7 !
Two things differed between mobile mode and desktop mode on the same phone.
The board tile's drag handle was a 26px circle in mobile mode and a 40px one in
desktop mode - two rules for the same handle, `.board-list.mobile-view
.board-handle` and the `.board-list .board-handle` inside the phone media query.
On a ~97px tile the big one covered a good part of the tile it was meant to sit
on. Both are the smaller one now, which is still well over the ~24px a finger
needs; the ≤360px block said 40px too, and says 26px now.
A workspace had no readable name in EITHER mode. The row packs a drag handle, a
folder icon, the name, a menu button and a count chip, and the rule for the phone
said the name "must give way to the fixed items around it". It gave way
completely: those items at their desktop paddings come to ~130px, the menu column
on a 375px phone is ~145px, and the name was laid out in the 15px left over. The
fixed items are trimmed to what they need on a phone - about 90px together - and
the name is given a floor of 3.5em it may not shrink below, so there is always a
name to read, with an ellipsis when it is long. It stays clipped to its own box,
so it cannot spill over the menu button, which was a separate bug and is pinned
by its own assertion.
tests/allBoardsPhoneRow.test.cjs reads the sizes out of the cascade rather than
trusting the comments: every phone handle rule is 26px, the name has an em floor
and an ellipsis, each fixed item is trimmed, and the clip is still there.
Thanks to xet7 !
v10.38 was tagged and released at 15:24; the work that followed was written into
that release's section, which says those fixes shipped in it. They did not.
Everything committed after the v10.38 tag now sits under a new
`# Upcoming WeKan ® release` above it: the four fixes - the Admin Panel old-URL
redirect, All Boards fitting a phone, the zoom number back inside its pill, and
the narrow-window layout - moved out of v10.38 unchanged, and the changelog
format work and the CLAUDE.md Hall of Fame rules are recorded beside them. The
release-only commits (the changelog edits themselves) have nothing to say and are
not listed.
Checked both ways: every post-release commit that changed something is mentioned
in Upcoming, and every commit still filed under v10.38 is an ancestor of the
v10.38 tag.
Thanks to xet7 !
The phone/desktop toggle writes an explicit choice and Utils.isMiniScreen()
returns it as-is, so a phone whose user picked DESKTOP mode is not a mini screen
and its body carries no `.mobile-mode`. Every fix written for one of those two did
nothing there - while the viewport was still 375px wide. Three of them showed up
in the same set of screenshots.
"Create board" opened 160px from the left with its right half off the screen, so
its Create button could not be reached. The geometry laid the popup out as a
floating box of min(380px, 55vw) anchored to the button, while popup.css - which
has given every popup the full width and its own 48px header below 800px for
years - then made it 375px wide. The two disagreed, and the inline `left` from the
geometry stayed. Now the geometry returns the top-left corner for any viewport
that narrow, and the CSS pins the sheet with `position: fixed` and
`inset-inline-start: 0` (with `!important`, because left/top are inline styles),
so neither can drift from the other.
The board bar's hamburger was pushed onto a third row of its own, with the empty
space that goes with it: it comes after the buttons in the flex order, and a flex
line breaks in order. The three mobile-mode rules that take it out of the flow and
pin it to the corner - and reserve its width as end padding - are now also written
by width.
The quick-access bar was still wider than the screen, so the avatar was cut off at
the right edge. The drag-handle toggle's arrows and its check/ban were breaking
onto two lines, which reads as two buttons; they are one line now. The mode toggle
gave up 21px of padding on each side of its two icons, and the logo 20px of its
cap - about 60px of a 375px bar, which is what the avatar needed. The logo cap
names the `.iphone-device` variant explicitly, since that one sets 84px with one
class more and would otherwise win.
tests/narrowWindowLayout.test.cjs replays the sheet decision at 375/800/801px and
pins each of the three rules; the popupOffset suite gains the narrow-window case
beside its mini-screen one.
Thanks to xet7 !
Two things had gone wrong with the zoom control on a phone, both visible in the
same screenshot: the white rounded pill was empty, and "100" sat to the right of
it in tiny type, half under the notification bell.
The pill was allowed to shrink below its own contents (`flex: 0 1 auto` +
`min-width: 0`, from the change that made the bar fit the screen). A flex item
that shrinks past its content does not clip it - the background box ends where
the width says, and the text carries on outside it. So the white area and the
number it belongs to were laid out at two different widths. The pill is sized by
what is in it now, and what is in it is made small instead: a compact "100%" and
a 46px input for when it is clicked to be edited.
The tiny type was `font-size: 0.7em` on a bar whose own text is 12px - about 8px,
the smallest text on the page, and set with `!important` on selectors specific
enough to beat anything written later. That declaration is now a plain 14px, the
size of the rest of the bar, which is also why the pill stays narrow: at 14px
"100%" needs about 40px.
The base rule also caps the pill at `max-height: 24px`, shorter than 14px text
with padding, which pushed the number against the top edge; the mobile rules lift
that cap and centre it. Every one of these declarations is `!important` because
the "Make zoom controls larger" block at this very width sets 21px paddings and
margins that way - the cascade was checked selector by selector, not assumed.
tests/mobileAllBoardsFit.test.cjs pins it: the pill and the number never shrink
below their contents, the cap is lifted, no zoom rule sizes the text as a
fraction of an already small bar, and the number is at least 12px.
Thanks to xet7 !
The rule named one collapsed cell; the index page now has two, each with its own
column's name as the summary - "Process" over how the report arrived, "Details"
over the story of the vulnerability. The remaining six cells, which are what a
reader scans, stay open.
Thanks to xet7 !
The index page's table grew three columns - Icon, Stars and Process - by taking
the icons out of the Vulnerability name cell and the stars and the "how the
report arrived" sentence out of the "Responsible Security Disclosure by" cell.
Written down here so the next security entry adds eight cells in that order
instead of the old five, and so the stars stay a column that can be compared down
the page rather than drifting back into the reporter's cell.
Thanks to xet7 !
The Vulnerabilities column of hall-of-fame/index.html carries the whole story of
every vulnerability, so each of those cells is a <details> with a "Details"
summary now - the table reads as a list, and the one being read opens where it
stands. Whoever writes the next security entry should not have to infer that from
the file.
CLAUDE.md now states it with the exact shape: only the LAST <td> of a row, the
plain word "Details" as the summary, a blank line under it, the cell's contents
otherwise unchanged, and the four identifying cells (CVE, name, date, reporter)
plus the header row left alone.
It also states the exception: the per-vulnerability subdirectory page is NOT
collapsed. That page was opened on purpose, for one vulnerability, so its cell
stays open and its prose Details section below the table stays as it is. Only the
index, which lists them all, hides them behind a summary.
Thanks to xet7 !
The rules described the shape the file had for one commit, not the one it has:
the "Version" list became a collapsible block inside Platforms rather than a
heading of its own, and the TODO Later introduction became one too. Whoever adds
the next entry should not have to reverse-engineer that from the file.
So CLAUDE.md now states the file's shape top to bottom - Platforms (with its
Version block), TODO Later (with its "Carried to a future release." block), then
the releases newest first, and NOTHING else as an `#` heading, including a
wrapped line that begins with an issue number. It states the exact <details>
block an entry is, line by line: the summary on one line, blank, body, blank,
close, blank between blocks. It states that a summary is plain text with no
markdown, ends with a full stop and its Thanks, and links its own commit; that a
change with nothing to reveal stays a plain bullet, as does a dependency batch;
that a TODO Later block has no <a> and no Thanks; and the order of a release's
subsections, ending with the "Thanks to above GitHub users" line.
tests/changelogFormat.test.cjs follows the file as it is: two non-release
headings, the Version block inside Platforms, the TODO Later opener, and the
CLAUDE.md rules it checks are named by their new wording. One 2021 heading that
had lost its `v` (`# 4.93`) is normalised, so "every other heading is a release"
is true rather than nearly true.
Thanks to xet7 !
The previous pass went the wrong way about #6524. It made every entry a title and
moved the story into the commit message, so the changelog told a reader WHAT
changed but nothing about why - and it showed the commit hash as the link text,
which is a number nobody can do anything with without leaving the page.
Both halves are here now. Every entry is a <details>: the <summary> is a SHORT
description of what was done, and it IS the link to the commit - the hash is in
the href, never on the page - followed by the "Thanks to" line. Clicking it
reveals the long description below, word-wrapped at 80 columns, with its links,
code and emphasis intact. A change with nothing more to reveal stays a plain
bullet, because a <details> whose body repeats its summary is noise.
977 entries across every release section were converted, and the ones the old
prose format had left malformed - an entry whose closing `](url)` sat at column
0, a summary that swallowed the following entry's links, a title that began with
a stray bracket - were repaired rather than carried over. Nothing was dropped:
every URL the file had is still in it, and every heading is where it was.
The top of the file is now two named sections, Platforms and Version, instead of
two unlabelled lists. TODO Later is <details> too, with one difference stated in
CLAUDE.md: its summary carries NO "Thanks to", because nothing there is done yet,
so there is nobody to thank.
tests/changelogFormat.test.cjs checks the whole file against those rules: the
opening sections, summary length, that a summary is one closed line holding no
markdown link, that no hash is ever a link's visible text, that no long URL is
visible, that no wrapped line starts with `#` (which Markdown would render as a
heading), the TODO Later exception, and the 80-column wrap.
Thanks to xet7 !
Two things from the same screenshot.
The board titles were laid out TWO CHARACTERS per line - "Da" / "ta". The drag
handle is one absolutely-positioned ~26px circle, but the space for it was
reserved three times on the way down: 32px on the `li`, 30px on the tile and
50px on `.details`. On a ~97px phone tile that is more than the whole tile, so
the title was laid out in what was left, about 27px. It is reserved once now,
on the tile, and not at all when the handle is not rendered - with drag handles
off there is nothing there to reserve for, which is the state the screenshot was
taken in. The `.mobile-view` tiles already had this fix; the plain ones, which
is what a phone gets when the list is not in mini-screen mode, did not.
The page could also be dragged sideways: the avatar sat past the right edge and
the board list moved with the page when you did. On a small screen the
quick-access bar is `flex-wrap: nowrap` with `overflow: visible` - deliberately,
so an item that does not fit spills rather than disappears - and every item
declares `flex-shrink: 0 !important`. Nothing could give way, so the row was
wider than the screen, and a visible overflow is scrollable overflow. The widest
item by far was the zoom pill: an 80px fixed input plus padding took ~113px of a
375px bar, more than the home icon, the mode toggle and the bell together. "100"
fits in about half of that, and the pill may now shrink; the bell and the avatar
never shrink, being what the user came for. `html { overflow-x: hidden }` on a
small screen is the guarantee that a future item, a long translation or a custom
logo cannot bring the sideways scroll back.
tests/mobileAllBoardsFit.test.cjs pins both: the handle width is reserved once
and dropped entirely when there is no handle, and the bar's widest item can give
way while the page cannot scroll sideways.
Thanks to xet7 !
Playwright caught this on all three browsers: "Version page shows Reactivity
mode" got All Boards instead. Both old URLs are panes of Admin Panel / Settings
now, and both redirected with FlowRouter.go('setting') called from INSIDE
triggersEnter. A trigger runs while its own route is still entering, and a go()
from there is swallowed - the action() renders nothing, so whatever page the
browser was already showing simply stayed. A bookmark to either URL landed
nowhere.
A trigger redirects with the `redirect` it is HANDED, which is the form the
redirections table at the bottom of config/router.js has always used.
Each URL now also asks for the pane it used to be a page of - Version for
/information, Translation for /translation - so the bookmark lands where it
pointed rather than on the default pane. The request is consumed once, so a
later visit to /setting opens on the default, and it marks the open pane as
decided so the site-admin autorun does not undo it a moment later.
tests/adminOldUrlRedirect.test.cjs pins the redirect form (and that no
FlowRouter.go() creeps back in), the pane each URL asks for, and that the
ReactiveVars it sets are created before it runs.
Thanks to xet7 !
The reporter says the board list still cannot be scrolled on a phone at v10.37,
after the layout fix. There is a reason that fix cannot have covered it, and it is
not visible in the Playwright run: a fixed test viewport has no browser toolbar.
The page sizes its scroll containers as `100vh` minus a bit - the wrapper, the
left menu, the board list, and the mobile body and content area. On a phone
`100vh` is deliberately the LARGEST the viewport can be: the height with the
browser's toolbars hidden. With the toolbar showing, every one of those boxes
reaches under it - and the wrapper is `overflow: hidden`, so what is underneath
cannot be scrolled to at all. The bottom of the board list is simply unreachable,
which looks exactly like "the list does not scroll".
Each of those rules now states the `vh` value first, as the fallback, and the
same value in `dvh` - the viewport as it is at that moment - immediately after. A
browser that understands `dvh` gets the real height; one that does not behaves
exactly as before.
The two scrollers also declare `overscroll-behavior: contain` and
`touch-action: pan-y`, so a vertical swipe is given to them rather than to the
page behind or to another gesture.
NOT verified here: there is no phone in this environment, and no browser toolbar
in Playwright, so this is reasoned from the source and from how the mobile
viewport units are defined. What IS verified is that nothing else in the page's
touch handling blocks the scroll: with drag handles on - which a touch screen
turns on - a board drag may only begin on the handle, the tile itself stays free,
and the touch drag-and-drop bridge honours that cancellation.
tests/mobileViewportHeight.test.cjs pins all of it, including that the `vh`
fallback is declared before the `dvh` value.
Thanks to mimZD and xet7 !
Fixes#6488,
Opening a card APPENDED it to the open-cards list, so the card that was already
open stayed open behind the new one - which the reporter saw as soon as the new
card was dragged: the old one was still sitting there. Clicking another card means
"show me that card", not "show me both".
A click now opens THAT card and closes the previous one. Both ways of opening a
card - the minicard and its title - go through one helper, so neither path can
drift from the other again.
Keeping several cards open at the same time is still possible, as the per-user
setting it should always have been: Member Settings / "Open many cards at once",
off by default, stored as `profile.openManyCardsAtOnce` and toggled by a server
method like the settings beside it. A reader who is not logged in gets the
default rather than an error.
tests/openManyCardsAtOnce.test.cjs replays the decision in both states and guards
the wiring: schema, helper, method, menu entry, check mark and translation.
Thanks to mimZD and xet7 !
Fixes#6531,
The board export REST endpoints look a user up by the login token in
`?authToken=`. A token that matches nothing makes that lookup answer `undefined`,
and the next line dereferenced it:
user = await ReactiveCache.getUser({ 'services.resume.loginTokens.hashedToken': … });
adminId = user._id.toString(); // TypeError on an unknown token
The handlers are async and had no try/catch, so the TypeError escaped as an
unhandled promise rejection - which this app turns into a full process crash (the
note in server/ldapGroupSync.js explains why). One crafted GET against a private
board id took the server down for every user. Reachable by anyone who can obtain a
private board id, which on an open-registration instance means anyone at all.
It was an incomplete fix: models/exportPDF.js and models/exportExcelCard.js
already had the `if (!user)` guard; three handlers in models/export.js and one in
models/exportExcel.js were missed.
Fixed on both levels:
* Every token lookup in the export models is now followed by the guard - 401
"Invalid token" and return - including the two handlers that did not crash
because they hand the user to canExport() instead of dereferencing it. One
rule for every lookup is what stops the next handler being the missed one.
* Every export route body is wrapped in safeRoute() (server/apiMiddleware.js),
which awaits the handler, answers 500 once and logs the request that failed.
A throw from any other cause is now one broken request instead of an outage.
tests/exportTokenGuard.test.cjs does not check four places by hand: it finds every
token lookup in the export models and requires a guard on each, that nothing
dereferences the user before it, that every route is wrapped, and that the two
handlers which were already guarded stay guarded.
Thanks to laijunyue for the coordinated disclosure, and xet7 !
An entry had grown into a paragraph - one ran to 1,600 characters - so the file
could no longer be read as what it is: a list of what changed, by version. That is
what the reporter asked for: "i just wanna see title of changes (fixes, new
feature, improves, ...) by the time and version, as changelog was before".
Every entry is now
- <one-line title> ([<short hash>](https://github.com/wekan/wekan/commit/<hash>)).
Thanks to ...
with the long story left where it belongs: in the commit message the link points
at. 3,000 entries were rewritten across the whole file, every commit link shows and
uses the 9-character hash instead of a description or "merge commit", 61 bare long
URLs became short links, and everything is wrapped at 80 columns - a line carrying
a link excepted.
A few malformed entries surfaced and are repaired on the way: a stray `](url)`
whose opening bracket was never written, a doubled `/commit/commit/`, a link with
no hash at all, and one URL missing its repository name.
CLAUDE.md now states the rules - title not story, hash as link text, never a long
URL as visible text, 80 columns - and tests/changelogFormat.test.cjs checks the
file against them, strictly for the Upcoming section.
Thanks to mimZD and xet7 !
Fixes#6524,
Caught by the newest Playwright run: the Version page test failed in all three
browsers, and the page it got was Visibility.
The multitenancy work decided the opening pane at onCreated:
const siteAdmin = tenantAdmin.isSiteAdmin(ReactiveCache.getCurrentUser());
this.versionSetting = new ReactiveVar(siteAdmin);
At onCreated the user document has often not arrived yet, so getCurrentUser() is
null, "is this the site admin?" is false for EVERYONE for that moment, and the page
opened on the pane meant for an Organization's own admin - for the site admin too.
Admin Panel / People had the same shape and could open on the wrong pane the same
way.
Both open on what they always opened on again - Version and Login - and the
exception for an Organization's own admin is applied in an autorun, once, when the
user is actually known.
Thanks to xet7 !
The app-wide rule that hides a native checkbox hides it in THREE ways at once:
display, visibility, and `inset-inline-start: -9999px`. The Admin Panel rule undid
the first two, so the box was on screen - 9999px to the side. Unchecked it was
simply not there; checked it appeared, because the checked state sets its own -3px
offset. That is exactly what "only the checked state is visible" was, in the
S3/MinIO, Azure and GCS panes and everywhere else a native checkbox is used.
`inset-inline-start: auto` (and `top: auto`) undoes the third.
The test now reads the hiding rule and requires the Admin Panel to undo every
property it hides with, rather than a list written by hand - so a fourth way of
hiding one would fail here instead of on screen.
Thanks to xet7 !
TypeError: can't access property "set", tpl.loading is undefined
on every click in the Login pane - Forgot Password, Self-Registration, Username
Change, Self delete user account, Display Authentication Method - and on the
E-mail pane's Save.
Blaze hands an event handler the instance of the template the handler is
REGISTERED on. When those handlers moved onto Template.general and Template.email -
which they had to, because Admin Panel / People renders those panes now - the
state they poke, `loading`, stayed behind on Template.setting. So the first line of
each handler threw, the setting was never written, and nothing on screen said so.
Both templates create their own `loading` now.
tests/adminTemplateState.test.cjs walks the Admin Panel components and fails when
an events or helpers block reads `tpl.<name>` that its own template never created,
so moving a handler without its state cannot pass again.
Thanks to xet7 !
"Support page enabled" animated to checked and fell back to unchecked. The reason
was not the checkbox: Admin Panel / Settings / Visibility draws it from
`currentSetting.supportPageEnabled`, and that field was not in the `setting`
publication. On the client it was therefore always undefined - the box drew
unchecked, ticking it wrote the setting to the server, and the next re-render drew
it unchecked again. The setting was saved; the checkbox said it was not.
Announcement's checkbox never had the problem because it reads the Announcements
collection, which is published whole - which is exactly why that one worked and
the Settings-backed ones did not.
Now published, and each of them is a control that was unusable: supportPageEnabled,
supportPagePublic, supportTitle, supportPageText, supportPopupText,
hideBoardActivitiesOnAllBoards (Visibility / All Boards) and
boardMembersFromSameOrgOnly / boardMembersFromSameTeamOnly (People / Organizations
and Teams). The SMTP settings stay out: they carry a password and have their own
admin-gated publication.
tests/settingPublishedFields.test.cjs walks every `currentSetting.<field>` in every
client template and fails when the publication does not carry it, so the next field
added to a pane cannot silently render as undefined.
Thanks to xet7 !
The material declarations were right, but one thing still fought them: forms.css
styles `input:not([type=file])` as a form FIELD - grey background, 6px radius,
padding, bottom margin, and `min-height: 41px`. Everything else was overridden;
the height floor was not, so a 13px box was drawn as a tall rectangle and the tick
it turns into was stretched with it. That is why the checked state looked roughly
right and the unchecked one did not, in Attachments / Limits / Avatars, in the
S3/MinIO, Azure and GCS storage panes, and everywhere else a native checkbox is
used.
`min-height: 0` (and `min-width: 0`) undoes it - the same reset
`input[type="radio"]` does a few lines below that rule in forms.css, for exactly
this reason.
The test now asserts every part of the form-field styling is undone, naming the
41px floor, so this cannot come back unnoticed.
Thanks to xet7 !
Day of week was a text field. It only ever accepted an English day name, typed
exactly right, from an admin reading a page in their own language - and nothing
said so. It is seven buttons now, each labelled in the reader's language.
Day of month was a number spinner: 27 clicks to reach the end of the month, and no
sign that the 29th to the 31st are not offered at all - a schedule there would
skip February. It is 28 buttons, one per date.
What is STORED is unchanged: the English day name and the number, because that is
what the cron sentence is built from (models/lib/backupPaths.js scheduleText).
Only the labels are translated. The chosen one is filled with the theme colour,
the way the selected left-menu entry is, and the rows wrap rather than squeeze.
The choice is template state now, seeded from the saved schedule when it arrives -
and not overwritten by it once the admin has picked something.
Thanks to xet7 !
"Attachments, Avatars, Data (text)" already draw as the Admin Panel's checkbox -
the plain square when off, the green tick when on, animated between, like
Announcement's "Active System-Wide Announcement" - since the checkbox style was
made the material one for every native checkbox in the panel.
What they lacked was layout: three inline labels, so a label could wrap away from
its own checkbox, and the box shifts a few pixels as it turns into the tick, which
unaligned text follows. They are one flex row now, each label holding its box and
its words together.
Thanks to xet7 !
The Save inside the New and Edit popups for Translation, User, Organization and
Team is an `input[type=submit].primary.wide` in a flex `.buttonsContainer` - and
`.wide` never reached it, because the rule for it in forms.css is written as a
DESCENDANT selector, `input[type="submit"] .wide`, which an input can never match.
So those Saves were the right colour but a different, cramped size from the Save
in a pane (People / Login, People / E-mail, Visibility).
All eight popups are now listed with the panes' own Save declarations - the theme
accent, the same padding, weight and states - and each Save takes its row, which
is what `.wide` was for. The popups are named one by one on purpose:
`.buttonsContainer` is board-sidebar and member-menu markup too, and those are not
Admin Panel buttons.
The test walks the Admin Panel templates and fails if a popup with a Save is not
in that list, so the next popup added cannot quietly get a plain button.
Thanks to xet7 !
The last Yes/No pair in the pane. Like the four in All Boards: Hide above it, the
setting is on or off, so it is one checkbox in the Admin Panel's own style -
square when off, green tick when on, animated between - and the Logo section's
Save writes the tick, skipping it when the checkbox is not on screen.
Visibility has no radio pairs left.
Thanks to xet7 !
Public boards, Board activities, Card counter list and Board member list were
Yes/No radio pairs. Each of them is on or off, and the group's own title already
says what turning one on means - "All Boards: Hide …" - so each is one checkbox
now: the same checkbox as everywhere else in the Admin Panel, with the plain grey
square when off, the green tick when on, and the animation between.
The section's Save writes the ticks the way it read the radios, and still skips a
setting whose checkbox is not on screen rather than writing it as false - the
guard that keeps a hidden field from being blanked, which is what these settings'
own regression test is about.
Thanks to xet7 !
The first attempt drew the checkmark with a pseudo-element over the box. That got
the checked state right and lost the other two thirds of the checkbox: the plain
grey square when unchecked, and the 0.2s morph between them that Announcement's
"Active System-Wide Announcement" checkbox has.
The rules are now `.materialCheckBox` and `.materialCheckBox.is-checked` applied to
the input itself - the same square, the same morph into the same green tick, the
same transition - with `appearance: none` as the only addition, to take the
browser's own rendering out of it. A native Admin Panel checkbox and a WeKan one
are now the same checkbox in every state.
The test compares them declaration by declaration against forms.css, so a change
to the material checkbox that is not carried over here fails rather than quietly
leaving the two different again.
Thanks to xet7 !
A pane's Save is a `button.primary`, which forms.css themes. The Save inside the
Admin Panel edit popups (Edit User, Edit Organization, Edit Team) is an
`input[type=submit].primary.wide` in a flex row - and `.wide` never reached it,
because the rule for it in forms.css is written as a DESCENDANT selector,
`input[type="submit"] .wide`, which an input can never match. So the popups' Save
was the same colour but a different, cramped size.
Both are listed with the same declarations now - the theme accent, the same
padding, weight and states - so they cannot drift apart again, and the popups'
Save takes its row, which is what `.wide` was for.
Also: a checkbox written as `label > input + text` (Attachments / Limits /
Avatars, and the Backup checkboxes) gets the gap between box and words that the
.materialCheckBox markup gets from its own layout.
Thanks to xet7 !
WeKan hides the native checkbox app-wide and draws its own square with a green
tick - `.materialCheckBox`, which is what Admin Panel / Settings / Announcement
shows for "Active System-Wide Announcement". But several Admin Panel panes use a
real <input type="checkbox">: the storage Read toggles, the Organizations and
Teams feature columns, the Backup checkboxes, the Problems summary. Those were
either invisible, because nothing re-enabled them, or re-enabled pane by pane and
then drawn by the BROWSER - on Ubuntu a big orange box that ignored the chosen
theme entirely (orange under clearblue), at a different size in every pane.
The Admin Panel now styles them itself: `appearance: none` takes the browser's
rendering out of it, and the tick is drawn the same way .materialCheckBox draws
it - two borders of a rotated box, in the same green - so a native checkbox and a
WeKan one are the same checkbox to look at. Grey icons, disabled and keyboard
focus are handled with it, and the panes no longer each re-enable and re-size
their own.
Admin Panel / People / E-mail / Allow Email Change is one such checkbox now
instead of a Yes/No radio pair: the setting is on or off. Save below writes it as
it wrote the radios, and only when the checkbox is on screen.
Thanks to xet7 !
The twelve strings the multitenancy and site-theme work added - the Organization's
domains and their description, the domain-taken error, the Organization admins
popup and its description, the backup scope and its description, and the line that
says a site admin's theme applies to all tenants - are translated into all 142
languages, using each language's existing WeKan terminology for Organization,
backup, admin and theme.
Nothing existing was touched: every value was written through
releases/translations/fill_translations.py --apply, which only ever fills a
placeholder (a key that is missing, or still equal to the English source), so a
human translation can never be overwritten. Key order and the 2-space indent are
preserved, and none of these are pushed to Transifex, where a real translation of
them can replace them at any time.
Thanks to xet7 !
It used to be filled with `--theme-accent`, one flat colour. That is close for most
themes and wrong for clearblue, whose bar is a colour SLIDE - a gradient no single
accent value can express.
Every theme's own `#header` rule in boardColors.css now names the selected row as
well, so the two are painted by exactly the same declaration, theme by theme: a
flat colour stays flat, a gradient stays a gradient, and adding a theme cannot make
them drift apart. The `--theme-accent` rule stays as the answer for an instance
with no theme at all.
tests/themeAccents.test.cjs asserts every allowed theme paints the row, and that
the selector is only ever added to a rule that also paints the header - never to a
copy of the colour.
Thanks to xet7 !
Choosing a named theme recoloured the header - which has a
`.board-color-<name>#header` rule of its own - and left everything that reads the
`--theme-accent` CSS variable on the stock blue: the Admin Panel's selected
left-menu row, its pane buttons, every Save button, the table-page controls and
the popup header. That variable was only ever set when a user picked a CUSTOM
colour for a flat/clear theme.
models/lib/themeAccents.js now maps every allowed theme to the colour that theme
paints its header with, and globalThemeColor.js publishes it as --theme-accent
whichever theme is in force: the user's own override, the board's colour, or the
site theme. A custom colour still wins over it, and the has-custom-theme-* classes
stay tied to a custom colour - they exist to override a named theme's own header
rule, which a named theme must not do to itself.
tests/themeAccents.test.cjs parses boardColors.css and fails if the map and the
stylesheet ever disagree, so a theme cannot be added in CSS alone and quietly fall
back to blue.
The Admin Panel edit popups (Edit User, Edit Organization, Edit Team) also got
their layout fixed: they are centred on the window rather than positioned from the
table row that opened them - which pushed their right-hand side, and the Save
button, off the screen - and their fields lay out in as many columns as the window
has room for, so a long form no longer has to be scrolled to reach Save. No popup
can be wider than the window any more.
And two smaller things in the Admin Panel: the Wait Spinner setting shows a live
preview of the spinner beside its dropdown, which wraps below the dropdown when
there is not enough room; and the Translation table's New column moved to the
left, where every other Admin Panel table page has it.
Thanks to xet7 !
Admin Panel / Settings / Visibility / Change color set the site theme and the
buttons picked it up - but both top bars stayed on the default colour, while a
user's own override still coloured them.
The reason: #header, #header-quick-access and .board-wrapper each spelled the
order of themes out in the template - the user's own override, else the board's
colour - so nothing there read the site theme (docs/Design/Page/Theme.md, layer 2)
at all. Only the <body> autorun knew about it, which is why the buttons changed
and the chrome did not.
One Blaze helper, themeColorClass, now answers for all three, in the one order:
the user's own override, then the board's own colour on a board page, then the
site theme. The templates read that single answer instead of re-deriving part of
the order, so the layers cannot drift apart again.
tests/globalThemeColor.test.cjs asserts both halves: that the three places use
the helper, and that the helper keeps the order.
Thanks to xet7 !
Every app file is an ES module in Meteor, so `module.exports = {…}` in one of
them throws the moment the CLIENT bundle loads it:
Uncaught Error: ES Modules may not assign module.exports or exports.*,
Use ESM export syntax, instead: ./models/lib/tenantAdmin.js
and because it throws, every module after it in the client graph never runs -
models/users.js imports tenantAdmin, so the whole client went down with it.
models/lib/tenants.js, tenantAdmin.js and tenantBackup.js now export with ESM
syntax, and every importer uses import instead of require(). The .cjs unit tests
load them with a dynamic import(), the way tests/cardUrl.test.cjs already loads
its module.
tests/tenantWiring.test.cjs guards both halves, so the same crash cannot come
back quietly.
Thanks to xet7 !
Implements option D of docs/Design/Multitenancy/Multitenancy.md, which that
document now describes as shipped.
An Organization may claim hostnames (Admin Panel / People / Organizations ->
Edit), carry its own branding - product name, logos, help link, legal notice and
theme colour - and have its own Organization admins, appointed from the row's
"..." menu. The request's host picks the Organization; its branding replaces the
instance branding for that request, and the client bundle that host serves points
its DDP connection back at that host instead of at the one ROOT_URL.
An Organization admin administers their own Organization and nothing else: its
people, its Organizations row, its theme colour and its backups. They can never
grant the site-wide Admin flag, never manage a site admin, and never see another
Organization's people or archives.
Per-tenant backup and restore is one new control in Admin Panel / Attachments /
Backup - Scope. An Organization's archive holds its boards and everything on them
plus the attachments those boards use, and no accounts, no instance settings and
no org/team documents, because those are shared. A restore may only write to
boards that Organization owns: the board ids are the intersection of what the
archive claims with what the Organization really owns, every document is checked
against that, and "replace all" replaces that Organization's documents rather
than everyone's.
Admin Panel / Settings / Visibility gains a Change color section above Logo: the
site theme, rendered by the SAME shared picker as Board Settings and Member
Settings - one template for all three, the way one shared table page serves every
table. Its design is the new docs/Design/Page/Theme.md. The order of themes is
WeKan's default theme, then the site theme (an Organization's own value on its own
hosts), then a user's own override; a board's own colour still owns the board page.
All of it is OFF unless the server is started with MULTITENANCY=true (plus
MULTITENANCY_TRUST_PROXY_HOST=true when a trusted proxy sets X-Forwarded-Host), so
an instance that has never heard of tenants answers exactly as before. One WeKan
server per customer remains the supported topology for customers who must not
share a process, and the design says plainly what this does NOT isolate.
The decisions are three pure modules - models/lib/tenants.js, tenantAdmin.js and
tenantBackup.js - so the same rules run on the client, on the server and in the
tests. Four new suites pin the separation rather than the plumbing: forged Host
headers, cross-tenant queries, privilege escalation and cross-tenant restores.
Thanks to xet7 !
The pane only had content inside a Sandstorm grain: the one-time MongoDB 3 ->
FerretDB migration status and a button that DELETED the raw MongoDB 3 database
files to reclaim grain disk. Compacting the MongoDB database frees that space as
well, so deleting raw database files is not something WeKan needs to offer.
The left-menu entry, the pane template, the helpers, the template state and the
click handler are commented out rather than deleted, so nothing of it runs and
the grain migration report can be brought back if it is ever wanted. The server
methods it called are left in place.
Everything else keeps working: the storages and their statistics, moving
attachments between storages, the MongoDB <-> FerretDB database migration, and
Backup. The grain's own migration, which runs in sandstorm-src/start.js before
the app boots, is unchanged.
Thanks to xet7 !
14 tests failed in every browser in the newest run (../log/2026-07-26_05-22-11),
all on one selector:
TimeoutError: locator.waitFor: Timeout 15000ms exceeded.
- waiting for locator('.js-people-menu') to be visible
`.js-people-menu` and `.js-templates-menu` do not exist any more. Admin Panel /
People renders the ONE shared left menu now, which is `a.js-left-menu-item(
class="{{jsClass}}" data-id="{{id}}")` - and People passes no jsClass, so its
entries have no per-page class at all. data-id is what the design says a page's
click handler reads (docs/Design/Page/Left-Menu.md), so that is what the tests
address the entry by: it cannot be removed by a conversion the way a per-page
class was.
The same conversion had left three other groups of selectors behind:
* Admin Panel / Problems' report entries - a.js-report-files / -rules / -boards
/ -cards / -impersonation - are the shared menu too, so they become
[data-id="report-files"] and so on;
* every report's own search input (input.js-rules-search-input and its four
siblings) is the shared controls row's input.js-table-page-search, and
.admin-report-pagination is .table-page-pagination - one shared table page for
all of them (docs/Design/Page/Table.md). The Files test also asserts the old
input is GONE, beside the Search button it already asserted;
* the People pager in the page object, button.js-people-next-page /
-prev-page, is the shared button.js-table-page-next / -prev.
The four reports that must not hang on FerretDB were proved ready by their own
search input rendering; with one shared input for every report that no longer
distinguishes them, so each is now proved by the shared input AND the pane title
naming that report.
Not run here: this sandbox has no node, so the suite has to be run on a machine
that has one. Every selector introduced was checked to exist in the app, and the
four report titles were checked against en.i18n.json.
Thanks to xet7 !
One MongoDB server holding one database per tenant - which is the shipped
docker-compose-multitenancy.yml unchanged. Only the Node side differs from the
baseline: one process opens all of those databases instead of n processes opening
one each. And because each driver takes a full connection URL, one server with
many databases is the common case rather than a requirement - a large tenant can
be moved to its own mongod without the others noticing.
Thanks to xet7 !
docs/Design/Multitenancy/Multitenancy.md. The shipped topology
(docs/Platforms/FOSS/Docker/Meteor3/) runs one WeKan Node.js server per customer:
one ROOT_URL, one database, one uws.port and one upgrade each. This designs the
alternatives to that - one server serving many domains - and says what each one
would cost, from WeKan's own code rather than in the abstract.
Six things one process must solve, with the Meteor 3 API for each: resolving the
tenant from the Host header (Meteor.onConnection gives httpHeaders, cookies
excluded; behind a proxy it is X-Forwarded-Host, and a forgeable header is a data
leak); the client bundle's baked-in ROOT_URL (WebApp.addRuntimeConfigHook rewrites
__meteor_runtime_config__ per request - and was broken in Meteor 3.0 alpha/beta/rc
until meteor#13156, which any use of it has to state a minimum version for);
server-side absolute URLs (Meteor.absoluteUrl's {rootUrl} override, and the handful
of WeKan call sites - universalUrlGenerator.js already builds relative URLs and is
the model); the data itself; accounts; and the eight settings singletons plus the
~102 process.env reads that are per-process today.
Four alternatives, compared in a table: one process per tenant (today), one
database with a tenant field (mizzao:partitioner from Meteor-Community-Packages,
Meteor 3 async), a database per tenant in one process (MongoInternals.
RemoteCollectionDriver), and Organizations as tenants - which is the one WeKan
already half has, since orgs, teams, their membership and the same-Organization /
same-Team board restriction all exist and are enforced server-side.
The recommendation is to keep one process per tenant as the supported topology and
reach for Organizations when the tenants are groups of one organisation: the other
two trade an operational cost that is merely tedious for a failure mode - a missed
selector on one of 46 collections or 66 publications - that is silent
cross-tenant disclosure. With, if it is ever attempted, the order that keeps it
honest: resolve the tenant once, do the settings singletons first because they
prove the pattern end to end, content collections only then with a test per
publication, and accounts last or not at all.
Linked from the two guides it is about and from the Scaling section of
docs/README.md.
Thanks to xet7 !
The section had grown one bullet at a time, so it read in the order things were
written rather than in the order CLAUDE.md asks for, and three threads of work were
missing from it entirely. Checked against `git log v10.37..HEAD`, the merged pull
requests and the dependabot bumps.
Order now: the CRITICAL SECURITY ISSUE (ZipBleed), then the Admin Panel
reorganisation, then the dependency updates, then the bug fixes, then the
developer-facing changes, the documentation and the translations - each later
subsection starting with a lowercase "and" so the headers read as one sentence.
Added, because no bullet covered them:
* the Settings reorganisation itself - Layout becoming PWA, the Accounts pane
going away, Registration being renamed Login, "don't show board activities"
becoming one global setting instead of a write over every board, and the
branding, Wait Spinner, Support, help link and legal notice moving to the panes
they belong to;
* the four People panes rendering through the shared table page, with the row and
header slots and the controls-row features that came from that pane;
* the shared left menu on every Admin Panel page, the selected entry matching the
selected tab above it, and the page-title bars going away;
* the five dependency updates merged since v10.37 - @aws-sdk/client-s3, unzipper,
bson, @playwright/test and docker/login-action - each with its pull request and
merge commit, thanked to dependabot;
* the Sign In / Register scrollable space;
* the left-menu design and its test suite, beside the table page's.
Two bullets moved to the group they belong to: the E-mail pane saving neither of
its settings is a bug fix, and every .jade template being compiled by a test is
developer-facing.
Thanks to xet7 !
vl-SS 93 strings from nl: Flemish and Dutch share these UI words, and its own
file already used Bord / Kaart / Lijst. What is left is what Dutch spells
like English too.
vo 51 in Volapük, following the file's own vocabulary (tab, kad, lised,
svimavög)
tlh 54 in Klingon, following the file's own vocabulary (raS, nav, tetlh, He)
The long prose strings of vo and tlh - the recovery-report description and the
problems-in-progress help - are deliberately left in English: composing new
sentences in either language with any confidence is beyond what can be verified
here, and an invented sentence is worse than the English source that at least
reads correctly.
Thanks to xet7 !
wa 49 in Walloon, propagated to wa-RR
fy 95 in Frisian, propagated to fy-NL - one of the two longest lists that were
left, now down to what Frisian spells like English
Thanks to xet7 !
hy 45 in Armenian
af 46 in Afrikaans, propagated to af_ZA
tk 57 in Turkmen (tk_TM)
Each is the same set: the Admin Panel toggles, the recovery report, the problems
status, the broken-card repair, the CPU figures, board status, the import timeout
and the map-to-existing-user dialog, in that language's own kanban words.
Thanks to xet7 !
ug 49 in Uyghur: the Admin Panel set, recovery, board status, storage, CPU
zu 53 in Zulu, propagated to zu-ZA
be 75 in Belarusian: the same set plus the whole search-predicate vocabulary
(archived, open, ended, overdue, week/month/quarter/year, assignee, member,
public/private, selector, projection)
xh 50 in Xhosa
Thanks to xet7 !
68 strings in Khmer: the Admin Panel set, the Version page fields (database commit,
FerretDB version, reactivity mode, OS architecture / free memory / load average),
board status, the date formats, the Azure and GCS fields, backup, recovery,
problems, repair and CPU. km-KH took them afterwards; km_KH already had its own.
Thanks to xet7 !
gu-IN 74: theme and font, the date formats, board status, the Azure/GCS fields,
backup, avatars, recovery, problems, repair and CPU
or_IN 50: the Admin Panel set, recovery, board status, the storage fields
uz 49, propagated to uz-AR/uz-LA/uz-UZ
az 49, propagated to az-AZ/az-LA
Thanks to xet7 !
sw 50: the Admin Panel set, recovery, problems, repair, CPU and board status,
plus the colour names Swahili has its own words for
nl 49: sjablonen, checklist, lettertype, stickers, the OS/FerretDB fields of the
Version page, the S3 and Azure fields, repository, logboek
yo 39 and ig 41: the same core set - the Admin Panel toggles, recovery, repair,
board status and CPU - in Yoruba and Igbo
nl-NL took nl's words afterwards.
Thanks to xet7 !
de the last few that differ in German (Beginn, Rechner, Detail, the storage
descriptions) - the rest of its list is words German spells as English
it 47: lista di controllo, carattere, adesivi, assegnatari, archiviazione, the
cron/backup/server vocabulary
th 83: the whole Version page (Node heap, Mongo sessions, OS arch), the S3 and
Azure fields, board status, support, accessibility, the date formats
ta 48: the Admin Panel set, recovery, problems, repair, CPU and board status
te 48 (te-IN): the same set in Telugu
pa 46: the same set in Punjabi
Thanks to xet7 !
One language at a time, in order of how widely it is spoken, filling everything
that is genuinely translatable and leaving what is identical in that language
(the tooling ignores a value equal to the English source anyway).
zh-CN/zh-TW the S3 fields, the date formats, the pangram, FerretDB commit, cron
hi board status, card loading, statistics, the date formats, pangram
es checklist, stickers, the Azure/GCS descriptions, bucket, selector
ar the date formats, selector/projection, storage descriptions, cron
fr the two storage descriptions - everything else left is a word French
spells the same as English
pt / pt-BR board status, statistics, website, card loading, storage descriptions
id 67 strings: theme and font, the search predicates, board status, the
S3 fields, backup, support, the file/log/server vocabulary
ms 73 strings: the whole Admin Panel set, recovery, problems, repair and
CPU, plus the predicates, board status and the storage descriptions
Their regional variants were refreshed from each base afterwards - zh-Hans/zh-Hant/
zh-HK/zh_SG/zh-GB/cmn/wuu-Hans/yue_CN, hi-IN, the eight es-*, ar-DZ/ar-EG/ary,
fr-CH/fr-FR, pt-PT, ms-MY.
Thanks to xet7 !
Filled by hand, no service: sk, sl, hr, sr, lt, lv, et-EE, eu, gl, th - the same
Admin Panel, recovery, problems, repair and CPU strings as the previous batch, in
each language's own kanban terminology (hr ploča/kartica, sr табла/картица, lt
lenta/kortelė, lv dēlis/kartīte, et tahvel/kaart, eu arbel/txartel, gl
taboleiro/tarxeta, th บอร์ด/การ์ด).
And a variant pass: 64 regional files - de-AT/de-CH/de_DE, fr-CH/fr-FR, es-AR/es-CL/
es-CO/es-LA/es-MX/es-PE/es-PY, pt-PT, ru-RU/ru-UA, uk-UA, zh-Hans/zh-Hant/zh-HK/
zh_SG/zh/cmn/wuu-Hans/yue_CN, ja-HI, ko-KR, ar-DZ/ar-EG, ca_ES/ca@valencia, cs-CZ,
el-GR, fa-IR, he-IL, hi-IN, nl-NL, pl-PL, ro-RO, sl_SI, vi-VN, wa-RR, ve-CC/ve-PP
and the rest - take their base language's translation for every string they had not
translated themselves. 1,903 strings, none of them a machine translation: they are
the same language's own words, and a variant that HAD its own translation keeps it.
Thanks to xet7 !
The strings that were untranslated everywhere - Transifex and git - are the ones
this repo fills directly, with the language's own existing translations and its
kanban terminology as the reference, and no external translation service, API or
password anywhere near it (releases/translations/fill-translations.mjs, and the
CLAUDE.md policy above it).
Filled for: fi, sv, da, nb, de, nl, fr, es, pt, pt-BR, it, ca, ro, cs, pl, hu, ru,
uk, bg, el, tr, ar, he, fa, hi, id, vi, ja, ko, zh-CN, zh-TW - 1,127 strings. Most
of them are today's Admin Panel work (the Login: Allow group, All Boards: Hide, the
two board-member restrictions, the invite-domain field, Visibility) plus the
recovery report, the problems status, the broken-card repair, the CPU figures, the
import timeout and the map-to-existing-user dialog.
Terminology follows each file: fi taulu/kortti/lista, de Board/Karte/Liste, fr
tableau/carte/liste, es tablero/tarjeta, pt-BR quadro/cartão/raia vs pt
quadro/cartão/pista, it bacheca/scheda, nl bord/kaart, ru доска/карточка, pl
tablica/karta, cs tablo/karta, tr pano/kart, uk дошка/картка, zh 看板/卡片, ja
ボード/カード, ko 보드/카드, ar لوحة/بطاقة, he לוח/כרטיס, fa تخته/کارت, hi बोर्ड/कार्ड.
Nothing here can overwrite a human translation: a key is filled only while it is a
placeholder (missing, or equal to the English source), and the apply step reports
and skips every key that already holds a translation - 150 of them across this
batch. Filled strings stay LOCAL and are never pushed to Transifex as human ones.
releases/translations/fill_translations.py is added beside the .mjs: the same rules
in Python, because the sandbox this ran in has no node runtime. Either can be used;
they agree on what a placeholder is, on the en.i18n.json key order and on the
2-space indent.
111 languages still have untranslated strings (14,112 placeholders, of which a
large part - numbers, "?", "/", LDAP, OAuth2, GridFS, S3/MinIO, Arial, the
__board__ patterns - are identical in every language and can never be "filled").
Thanks to xet7 !
Both remaining documentation entries of CHANGELOG's TODO Later, done together
because they are the same sweep.
A menu path is a docs path now. Admin Panel / Settings / Visibility is
docs/Features/Admin-Panel/Settings/Visibility.md; Admin Panel / People / Teams is
People/Teams.md; and each of the four sections has an index listing its panes in
menu order. Before this a reader could not map what they were looking at to a file:
the folder held Admin-Panel.md plus two loose pages, and the prose still described
panes that had moved or gone.
What the prose now says, and did not:
* Version is a Settings pane and the one that opens with the Admin Panel; the
Info tab is gone and /information redirects.
* Visibility is four groups with a Save each - All Boards: Hide, URL, Product
name, Logo - and absorbed Allow-private-boards-only.md and Custom-Logo.md,
which were separate pages for two of its settings.
* Layout is PWA, and holds only the PWA settings: everything else in it moved to
Visibility. Wait-Spinners.md pointed at Layout and now points at the group it
is in.
* Registration is People / Login, one "Login: Allow" group of checkboxes, and
the Accounts pane is gone - allow e-mail change is in People / E-mail, username
change and self delete in People / Login.
* The e-mail domain field decides who may INVITE while self-registration is off,
not who may sign in.
* The board-member restriction is two checkboxes, in Organizations and in Teams.
* The Features tab is gone: its panes are the Settings group of Problems, whose
menu is two named groups. Undo.md, which plans a Features / Delete pane, says
so where it plans it.
* Attachments has a page per menu entry, Backup first, and Problems' index
describes today's two groups.
Every link into the moved pages was updated - docs/README.md, Features.md,
Boards.md, Templates.md, Status.md, Members.md - and every relative link inside the
Admin Panel tree resolves.
wekan.fi: the Admin Panel row of docs/index.html described the old panes (Features,
Info, Translation as tabs; "registration, accounts, table visibility, layout"), the
Registration control row named settings that have moved, and install/index.html sent
readers to Settings/Layout for the logo. Those are edited in ../w/wekan.fi and left
uncommitted there, as that repository is not this one.
Thanks to xet7 !
"Add board members only from the same Organization or Team" was one checkbox in the
Login pane - which is where neither of the two things it restricts lives. It is two
checkboxes now, each in the pane it is about:
Admin Panel / People / Organizations [_] Add board members only from the same
Organization
Admin Panel / People / Teams [_] Add board members only from the same Team
A candidate may be added to a board when they share at least one ENABLED kind with
whoever adds them: an Organization when the first is on, a Team when the second is.
With both on that is "an Organization OR a Team" - exactly the rule the single
setting had - so an install that has the old field and neither new one is migrated
to both on first start, and nobody's restriction changes by upgrading. Ticking only
one is the new, narrower choice that was not expressible before.
models/settings.js boardMembersFromSameOrgOnly, boardMembersFromSameTeamOnly
server/models/settings.js the startup migration from the old single field
server/lib/orgTeamRestriction.js
boardMemberRestriction(setting) reads the pair - and
still reads the old field, so an install behaves the
same before the migration runs; canAddUserToBoard()
takes a flag per kind (the old restrictEnabled still
means both)
models/users.js sharesOrgWith / sharesTeamWith, and
sharesRestrictedOrgOrTeamWith(user, restriction)
Enforced in the same three places as before - inviteUserToBoard, the user-search
typeahead that must not offer what the server would reject, and the imported-user
reconciliation - so the two settings cannot drift apart from what the UI says.
Thanks to xet7 !
The pane mixed two opposite ways of saying the same kind of thing: "Disable Forgot
Password" and "Disable Self-Registration" as checkboxes where TICKED meant off, and
"Allow Username Change" / "Allow users to self delete their account" / "Display
Authentication Method" as Yes/No radios. Half the rows meant the opposite of the
other half, and the word Allow or Disable was repeated on every one of them.
One group title says it once - "Login: Allow" - and every row under it is a
checkbox that is ticked when the thing is allowed:
Disable Forgot Password -> [_] Forgot password
Disable Self-Registration -> [_] Self-Registration
Allow Username Change (Yes/No) -> [_] Username Change
Allow users to self delete their account (Y/N) -> [_] Self delete user account
Display Authentication Method (Yes/No) -> [X] Display Authentication Method
`disableForgotPassword` and `disableRegistration` are stored as "disable" flags, so
their checkbox asks `unless`: only the DISPLAY is inverted, the stored fields and
their handlers are untouched. The three former radios write on click like the
checkboxes they now are - a checkbox that has to be confirmed by a Save button
further down the pane is a checkbox you think you have already set - so the Save at
the bottom keeps only what is still a field: the default authentication method and
the OIDC button text.
Translations: `forgot-password` already existed and is already translated
everywhere, so the row reuses it and `disable-forgot-password` is gone;
`disable-self-registration` becomes `self-registration`, whose name no longer
contradicts what the row means; `display-authentication-method` is reused as it is.
The two account settings keep their keys - `accounts-allowUserNameChange` and
`accounts-allowUserDelete` still describe the setting exactly - and only lose the
"Allow" their group title now carries, so every language keeps its translation
until Transifex offers the shortened source.
One bug fixed on the way: a dead `js-toggle-display-authentication-method` handler
that only toggled a CSS class sat LATER in the same event map than the real one. A
duplicate key in an object literal silently overrides the earlier one, so it would
have swallowed every click on the new checkbox.
Thanks to xet7 !
Two settings, neither of which was ever written:
* "Email domain name" (mailDomainName). The Save handler starts with
checkField('#mail-server-host'), and the SMTP block is commented out of this
pane's markup - checkField THROWS on an input that is not there, and the throw
was caught and swallowed, so the handler returned before its Settings.update.
Pressing Save did nothing at all.
* "Allow Email Change" (accounts-allowEmailChange). The radios rendered the
stored value and NO handler anywhere in the app wrote them back.
The Save button moves out of the Yes/No row - where it read as part of that one
radio pair - to its own line below both settings, and writes both: the domain into
Settings, the Yes/No into AccountSettings. Every field is written only when its
input is actually rendered, which is the guard the rest of these panes use, so the
SMTP fields being commented out can no longer abort the save.
And the label is renamed with its value, because "Email domain name" said nothing
about what the field decides and read as if it limited who may sign in. It does
not: a NON-ADMIN whose address ends with this domain may send board invitations,
and only while self-registration is disabled (isNonAdminAllowedToSendMail in
server/models/settings.js). The key `can-invite-if-same-mailDomainName` becomes
`email-domain-allowed-to-invite`, "Email domain allowed to invite people, when
self-registration is disabled".
Thanks to xet7 !
Every row in that group repeated the group title and the word "Hide": "Hide card
counter list on All Boards" under a title reading "All Boards". The title says
"All Boards: Hide" and each row says only what is hidden:
Boards visibility: Allow private boards only -> Public boards
Don't show the board activities on all boards -> Board activities
Hide card counter list on All Boards -> Card counter list
Hide board member list on All Boards -> Board member list
The three keys used only by this pane are renamed with their values -
`board-activities`, `card-counter-list`, `board-member-list` - because their names
described the old wording. A renamed key falls back to English until it is
retranslated, which is the honest outcome here: a translation of "Hide card
counter list on All Boards" is not a translation of "Card counter list", and
keeping the key would have shown the old sentence under the new title in every
language but English.
Two keys are NOT touched, and that is the point of the two new ones:
`all-boards` is the menu and page label everywhere else, so the group title is a
new `all-boards-hide`;
`tableVisibilityMode-allowPrivateOnly` is the message boardBody.jade shows on a
board you may not open - where "Public boards" alone would say nothing - so the
row label is a new `public-boards` and the setting's own key keeps its sentence.
(It is also the _id of the TableVisibilityModeSettings document, which no rename
may touch.)
Thanks to xet7 !
Each of the four sections - All Boards, URL, Product name, Logo - now ends with
its own Save, directly above the horizontal rule that closes it, and each handler
writes only that section's fields. One Save for the whole pane meant pressing it
in one group also wrote whatever was half-typed in another, and it was easy to
miss which button belonged to what.
Three buttons are folded into their section's Save and are gone with their
handlers: the pane-wide `js-tableVisibilityMode-save`, the single-setting
`js-hide-board-activities-save` sitting mid-section, and `js-support-save` inside
the Support block. The Support page's Enabled / Public checkboxes still save on
click, as before - they are toggles, not fields.
The guard that every one of these moves has needed is kept and is now in one
place: a field is written only when its input is actually RENDERED
(`$(sel).length`, `!== undefined` for a radio). Reading an absent input gives ''
or undefined, and writing that blanks a stored setting or silently turns it off.
Thanks to xet7 !
Every group but the first is now separated by a horizontal rule - URL, Product
name, Logo. All Boards opens the pane directly under its title, where a rule would
separate it from nothing.
Thanks to xet7 !
The group holds ONE field, so a group title above a label that says the same thing
printed it twice. The group title stays - at the group title size - and takes the
field's own translation (`custom-product-name`, "Custom Product Name"), which is
the string that already exists in every language; the field's separate label is
gone, and so is the English-only `settings-group-product-name` key added for it
yesterday, which nothing uses now.
Thanks to xet7 !
Top to bottom, under the pane title:
All Boards boards visibility (allow private only), don't show board
activities on All Boards, hide card counter list, hide board
member list, wait spinner
URL Support (link, enable, title/content), custom help link URL,
custom legal notice URL, custom URL schemes
---
Product name the custom product name
---
Logo hide logo, the login logo image/link/text, the top-left corner
logo image/link/height
The settings themselves are untouched, and so is every input id - the one Save
button at the bottom looks its fields up by id, not by position, so grouping them
changed nothing about what it writes. The three dedicated Save buttons (board
activities, Support, and that one) stay with what they save.
A group title uses .admin-pane-group-title: 1rem against the pane title's
1.25rem, so the page reads as one heading with groups under it rather than as
several pages stacked. Three new English strings for the titles that had no key -
URL, Product name, Logo; All Boards reuses the key it already has.
Thanks to xet7 !
Broken cards was the one entry in this menu with a different set of controls: no
search box, no total, no "page X / N", just a prev/next of its own - because it
ran on the global-search machinery (CardSearchPaged, a session document and the
nextPage/previousPage publications) instead of the shared table page. It is a
column spec in REPORT_TABLES now, like Files, Rules, Boards and Cards, driven by
the same loadReport(): a new admin-only `brokenCardsReport` publication takes a
search term plus limit/skip and publishes ONE page manually (a returned
sorted+limited cursor hangs on FerretDB's OpLog, as with the other reports), and
`getBrokenCardsReportCount` gives the total behind the counter.
What "broken" means - no board, swimlane or list, or a type that is not a card
type - is now one selector shared by the report and by the standalone
/broken-cards page, which still runs on the global search and keeps its own
publication unchanged.
The menu is two named groups. Summary, then a rule and a "Settings" title over the
two panes that came from Admin Panel / Features, then a rule and a "Reports" title
over the reports. A title is a new kind of menu item - `{ heading: true, labelKey }`
- with no id, no icon and no handler class, so there is nothing to click, nothing
for the page's click handler to read a data-id from, and it can never be the active
row (or a group name could end up as a pane title). Both use an i18n key the app
already has, so no language has to translate anything new.
Performance moves down to sit with the Speed, Tests and CPU usage streams it is
about, below Impersonation Report - it was three groups away from them, up with the
other two Features panes.
While there: the separator between groups is styled with the menu itself. The rule
for it lived in adminReports.css, twice, targeting a class the shared menu does not
render - so it had never applied to anything.
Thanks to xet7 !
Admin Panel / Attachments / Backup showed "Backup" twice: the pane heading comes
from the open left-menu entry now (docs/Design/Page/Left-Menu.md), and every
Attachments pane still printed its own name under it. Those h3s are gone - all ten
of them - and with them the same repeat on Roles, Shared templates and Broken
cards.
A heading that says something the menu label does not is not a repeat and stays:
Limits keeps "Attachment And API File Size Limits" and Locked users keeps "Brute
Force Protection Settings", neither of which is the label of the row that opened
it.
tests/leftMenu.test.cjs now reads every h1-h3 in the Admin Panel templates and
fails on one whose text is a menu label - by i18n key, or by the English string
for a literal heading like the Sandstorm one.
Thanks to xet7 !
The row at the top of a menu and the pane that opens are the same one now - the
rule Admin Panel / Settings follows for Version. Backup was moved to the top of
the Attachments menu while the page still opened on Move attachments, so the menu
highlighted the second row on arrival.
Landing on Backup asks once whether a backup is running (pollBackupStatus only
keeps polling while it is), so arriving during one shows its progress instead of a
pane that looks idle.
Thanks to xet7 !
Reported one after another, all in the Admin Panel, and they turned out to share
two causes: a stylesheet deciding a table's width from outside the design that
owns it, and a pane having to write for itself what every pane needs.
The tables
* Admin Panel / People / People rendered NOTHING - no table, no search box, no
pager. `buildFilters` and `buildActions` were used in peopleTablePageData but
never imported. That is not a build error: it is a ReferenceError thrown inside
a helper while rendering, which Blaze answers by rendering nothing at all.
Organizations, Teams and Domains use neither function, so they drew normally,
which is what made it look like a People-only problem.
* The right-hand side of a table was off screen - reported on Domains, and just
as true of Admin Panel / Version, where the value column was cut off at the
window edge. Two admin stylesheets forced `min-width: 1200px !important;
width: max-content !important` with nowrap cells on a bare `table` selector.
peopleBody.css had no page in the selector at all, so it reached every table in
WeKan, and `!important` beat the shared table page's own width:100% +
table-layout:fixed. The same rules also made a SHORT table shrink to its
content, which is why Domains sat at a third of the panel on a narrow window.
No admin table is forced wide any more: it fits its panel and its cells wrap,
and the phone-width exception that used to undo the floor is simply the rule at
every width. The shared table page's width and wrapping are `!important` now -
a guarantee a stylesheet in another folder can silently override is not a
guarantee.
* An empty table page rendered no table at all, and the "New" link of
Organizations, Teams, People and Translation is a column HEADER - so an empty
pane had no way to create the first row. The table always renders now; the
"no items" message moved below it.
* The controls row: every control shares one height and no margin. forms.css is
`button { display: block; margin-bottom: 14px }`, written for stacked form
buttons, so a button that kept that margin was centred higher than one that did
not - "Unlock all users" sat lower and shorter than "Teams" beside it, since it
also carried a 20px margin and a 28px height from the old hand-written header.
Action buttons are themed with the pager, in the one stylesheet that owns those
colours, every state spelled out, or a bare <button> falls through to the
forms.css fallback, which is literally black.
Admin Panel / Settings / Translation now renders through the shared table page
(docs/Design/Page/Table.md) instead of a hand-written table: four columns, an
interactive row, the "New" link as a column header. It pages ONE page of 25
server-side with limit/skip and a count method, where it used to grow a window by
infinite scroll; the publication publishes the field it is sorted by, so the
client's sort matches the server's page.
The pane title
Every Admin Panel pane opens with the same heading, and the heading is the ACTIVE
LEFT MENU ENTRY's own label - `paneTitle()` in models/lib/leftMenu.js, one class
`.admin-pane-title`, which the shared table page's own title carries too. Before
this only the paginated table pages had a title at all: Domains said "Domains"
while Login, Announcement, Accessibility, PWA and Version opened with no heading.
Deriving it from the menu is what keeps them identical - a pane cannot end up with
a title of a different size or none at all - and it is why a table page inside the
Admin Panel now passes no titleKey: the section already rendered the heading.
The menus
* Version is the FIRST pane of Admin Panel / Settings and the one that opens with
the page, so what an admin sees first is the version, database and system
information they usually came for. Its page, its one-entry menu and its tab are
gone - a page whose menu had a single entry was a page in name only - and
/information redirects to Settings, the same move Translation made.
* Admin Panel / People: Domains moves up beside E-mail, the settings it is about.
* Admin Panel / Attachments: Backup moves to the top.
Tests: tests/tablePage.test.cjs gains the Translation conversion, the empty-table
header, the one-height controls row, the themed actions and a guard that no admin
stylesheet may force a table's width; tests/leftMenu.test.cjs gains the pane title
(helper, template, every page renders it, one shared size) and Version as the
first Settings pane; tests/translationPane.test.cjs is rewritten for the pane that
is left once the shared design owns the table.
Thanks to xet7 !
Admin Panel / Problems is the longest menu - 15 entries since Performance, Security
and Notifications joined it - and its last four sat on the page's grey with no panel
behind them.
The panel is a flex item stretched to the row's height, so its background, border and
rounded corners end at the bottom of the page. With the default `overflow: visible`
the entries simply kept rendering past that edge. Nothing was hidden and nothing was
unclickable; the menu just stopped looking like a menu halfway down.
It scrolls now. `min-height: 0` goes with it: a flex item does not shrink below its
content without it, so the box would stay as tall as the list and the overflow would
never engage - the rule would look right and change nothing.
Whatever is visible is now always on the panel, at any window height and for any menu
length, rather than depending on the menu being short enough.
Tests: 1380 passing.
Thanks to xet7 !
`./build.sh` stopped with
Jade compilation error in peopleBody.jade: Can't use the built-in 'if' here
A `//-` comment placed BETWEEN `if loading.get` and `else if registrationSetting.get`
splits the chain, and the orphaned `else if` is not a valid statement. The comment
moves above the chain, where it was meant to be, and says why it has to stay there.
The real failure is that tests/jadeCompiles.test.cjs was green while the build was
red. It called JadeCompiler.parse() only, and this error is not a parse error - the
loader parses and THEN runs SpacebarsCompiler.codeGen on the body and on every
template, and that is the step that rejects the orphaned else. A suite written to
catch "a broken template breaks the build" missed a broken template that broke the
build.
It now does both steps, exactly as npm-packages/meteor-jade-loader does, and a
negative test pins the gap itself: the broken chain must throw through compile(), and
the same input is fed through parse() alone in the same test to show that parsing does
NOT see it. If that parse ever starts throwing, or the compile stops, the check has
been weakened back to what missed this.
Verified by running the actual loader function - the one rspack calls - over
peopleBody.jade, adminReports.jade and settingBody.jade, which now all generate code.
Tests: 1379 passing.
Thanks to xet7 !
Its last three panes - Performance, Security and Notifications - moved to Admin Panel /
Problems in 4df87fd6b, leaving a tab that opened an empty page.
Removed: the /admin-features route, the tab in the Admin Panel bar, its isFeaturesActive
helper, both imports, and adminFeatures.jade / adminFeatures.js.
NOT removed, and this is the whole risk in the change: the three pane templates and
their helpers and handlers lived in those two files. Deleting them would have left
Problems rendering three templates that no longer exist - which is not a build error.
The app compiles and loads, and then throws `No such template: featuresPerformance`
when the pane is opened, losing whatever else that view was drawing. They move to
adminReports.jade / adminReports.js instead, with the page that renders them, together
with the toggleSettingField() helper the handlers call.
tests/templateIncludesResolve.test.cjs is new and general: every `+templateName` in
every .jade must name a template that exists. It is the mirror of
templateHandlersExist.test.cjs, which catches a HANDLER on a template that does not
exist; between them a template can neither be referenced without being defined nor
extended without existing. It also asserts the removed page's route, tab, helper and
imports are gone - a tab that survives its page leads to a route rendering a template
that is not there.
Five includes are package-provided rather than ours (fullcalendar, atForm, mentions,
markdown) plus one pre-existing (subtaskDeleteDialog); they are listed explicitly so
the check stays honest rather than being loosened.
Tests: 1378 passing.
Thanks to xet7 !
The Problems menu now reads:
Summary
Performance | Security | Notifications (moved from Admin Panel / Features)
Speed, Tests, CPU usage
--
Security Report
Impersonation Report
Broken Cards, Files, Rules, Boards, Cards, Recovery
"Security" is renamed "Security Report" and moved above Broken Cards, with
Impersonation Report directly between the two. The rename is what makes the rest safe:
the pane arriving from Features is ALSO called Security, and the two now sit in one
menu. It is the English SOURCE string that changed (securityReportTitle), so every
other language keeps its existing translation until that string is retranslated - no
human translation is overwritten, and the key is unchanged so nothing else moved.
One correction worth stating: the request named Admin Panel / SETTINGS as the home of
Performance, Security and Notifications. They are Admin Panel / FEATURES panes -
Settings has no entry by any of those names - so they were taken from there, which is
the only place they exist.
Their handlers and helpers came with them, which is the half that fails silently. All
twelve helpers and twelve toggles were registered on Template.adminFeatures; Blaze
resolves a helper, and delivers an event, against the template the element is IN,
never an enclosing one. Left there, each pane would have rendered on Problems with
every checkbox reading as unchecked and no click doing anything. Each pane is its own
template now, and the shared helper/handler pair is registered on all three - a handler
whose element is not in a given pane simply never fires there, so splitting them per
pane would buy nothing.
That leaves Admin Panel / Features with no panes at all. Its page, menu and route stay,
so nothing linking there breaks and a future feature has a home, but the tab is empty
until it gets one. Removing the tab is a separate decision and is not made here.
Tests: 1374 passing.
Thanks to xet7 !
Both panes are about the people who can sign in and how they are reached, which is
what the People page is for. They are its first two entries now, and Login is the pane
that opens with the page.
The move is only half markup. EVERY handler those two panes need was registered on
Template.setting - the toggles for forgot-password, self-registration, same-org board
members and Display Authentication Method, the invite-people button and its board
chooser, the account-access Save, and on the E-mail side the TLS toggle, the SMTP Save
and Send test e-mail. Blaze delivers an event to the handlers of the template the
element is IN, so left on Template.setting each pane would have rendered on People and
then quietly done nothing: no toggle sticking, no Save saving, nothing in the console.
All ten moved onto Template.general and Template.email, the templates that draw them,
where they work wherever the pane is rendered. Template.general also gains
accountAccessHelpers, which Template.email already had - a helper the host template
lacks renders as unchecked, which silently shows the wrong value.
The pane TEMPLATES stay in settingBody.jade beside the other admin panes, since Blaze
templates are global and their handlers now sit beside the other settings handlers.
Both files say so where a reader would look for them.
Settings loses the two entries, their id-map rows, their reactive vars and their
isGeneralSetting / isEmailSetting helpers. generalSetting was the var that started
true, so Visibility - the first entry left - is promoted to open with the page;
without that the Settings page would open on no pane at all. The Sandstorm exception
that drops the E-mail entry moves to People with it, so peopleMenu() is a function
now rather than a bare array, because it has to read Meteor.settings at call time.
Ids and i18n keys are unchanged, so every existing translation still applies.
tests/loginEmailPanesMoved.test.cjs pins the whole move, including the half that fails
silently: each handler must be on the pane template and NOT on Template.setting, the
panes that stayed must keep theirs, exactly one pane may start open, and both pane
templates must exist for their handlers - registering on a missing template throws at
module load and takes out every module after it, which is how the password field
vanished from /sign-in earlier in this series.
Four existing suites asserted these panes were part of Settings and now assert them as
part of People.
Tests: 1368 passing.
Thanks to xet7 !
CRITICAL SECURITY ISSUE (CWE-22 Improper Limitation of a Pathname to a Restricted
Directory, "zip-slip").
A zip entry carries its own path, chosen by whoever built the archive, and path.join()
RESOLVES `..` segments instead of rejecting them. The restore checked only that an
entry's FIRST path segment was `attachments` or `avatars`, then joined the rest onto
the matching directory:
const rel = entry.path.split('/').slice(1);
const kind = rel[0];
if (kind !== 'attachments' && kind !== 'avatars') continue;
const destPath = path.join(attachmentsDir(), ...rel.slice(1));
So an entry named
2026-07-25_12-00-00/attachments/../../../../etc/cron.d/wekan
satisfied that check - its first segment really is `attachments` - and joined its way
clean out of the files directory. With attachmentsDir() = /data/files/attachments it
resolves to /etc/cron.d/wekan, and the entry's contents were streamed there. A crafted
backup.zip could drop or overwrite a file anywhere the WeKan process could write.
restoreBackup is behind requireAdmin(), which is less of a barrier than it sounds:
that is exactly how a hostile archive arrives - offered as a backup to restore, at the
one moment nobody inspects the file they were handed, and nothing in an archive is
visible before it is unpacked.
Fixed in models/lib/backupPaths.js, next to the other pure backup helpers so it is
unit-testable without Meteor: safeEntryPath() resolves the candidate to an absolute
path and requires it to sit under the target directory. It compares against the base
plus a separator, because a bare startsWith(base) also accepts a sibling directory
whose name merely begins with the same letters (/data/files/attachments-evil). An
absolute segment is caught by the same check, since path.resolve discards everything
before it.
The data half of an archive names the Mongo collection to restore into, and that name
came from the entry too, so safeCollectionName() constrains it to a plain
[A-Za-z0-9_-]+ name - which also keeps a restore out of the database's internal
system.* collections, excluded from backups in the first place.
A refused entry is skipped and logged rather than thrown on, so one hostile entry in
an otherwise good archive cannot abort a genuine restore.
This is WeKan's own code, not a dependency: it is the same class as the unzipper
advisory GHSA-884w-698f-927f, but WeKan runs unzipper 0.12.x, which that advisory does
not affect. Found while reviewing the open dependency pull requests.
tests/zipbleed.test.cjs asserts the exact traversal above is refused, that a plain
entry still restores where it belongs, that absolute segments and prefix-matching
siblings are refused, and that the restore really calls both guards. One assertion
reproduces what the OLD code did with the attack path - path.join returning
/etc/cron.d/wekan - so the suite states the danger, not just the remedy.
Tests: 1359 passing.
Thanks to xet7 !
Two reports, one of them the same bug in a third place.
Domains - and with it every other shared table page - needed scrolling to the right
to see its last columns. settingBody.css gives EVERY table in the admin body a 1200px
floor, `width: max-content` and nowrap cells, written years ago to force a horizontal
scrollbar. Applied to `.table-page-table` that overrode exactly what makes the shared
page fit: width:100%, table-layout:fixed and wrapping cells (docs/Design/Page/Table.md).
The three rules now exclude `.table-page-table`; the genuinely wide admin tables -
GridFS statistics, Version, Translation - keep them. The panel's `overflow-x: scroll`
becomes `auto` in the same breath, so a page whose content fits no longer shows a
scrollbar with nothing to scroll to.
Admin Panel / Settings / Translation showed no rows and no way to add one.
`translationList` is a helper of Template.translationSettings, but
`each translation in translationList` is written inside translationGeneral - a
different template. Blaze resolves a name against the current template's helpers, the
global helpers and the data context, never an enclosing template, so the list came out
undefined and the tbody was empty. The parent hands the list down now. This is the
third instance of that one mistake today: Organizations, Teams and People had it too.
Its Search button was BLACK. forms.css styles every bare <button> from
`var(--theme-accent, #000)`, and with no per-user theme chosen that fallback is
literally black. It takes the same colours as the other admin buttons now - the accent
when one is set, the WeKan button blue when it is not. Every state is spelled out
(:hover, :focus, :active, :active:hover) because forms.css sets each of those from the
same variable with its own black-ish fallback; overriding only the resting state
leaves a button that turns black the moment you touch it.
tests/uiDensity.test.cjs asserted against the old unscoped td/th selectors and now
asserts the scoped ones, with a note about which tables they are for.
Tests: 1352 passing.
Thanks to xet7 !
Replaces the darker-and-bold label from b775ee1e1 with the treatment the Admin Panel
bar already uses for its selected tab (settingHeader.css, `.setting-header-btn.active`):
the entry is FILLED with the theme colour and its label and icon go white. One
selected-thing look in both places.
The colour is the per-user theme accent, which Member Settings -> Change color sets on
:root, so a user with a green theme gets a green entry. The fallback is the WeKan
header blue, so with no chosen colour the menu matches the bar exactly.
`li.active:hover` is in the selector list on purpose: `li:hover` sets a white
background at the SAME specificity and comes later in the file, so without it the fill
washed out the moment the pointer crossed the selected entry. The now-dead
`background: #fff` on the plain `.active` rule is removed; its shadow stays.
Tests: 1347 passing.
Thanks to xet7 !
Organizations, Teams and People drew their search box and their pager but NO TABLE.
Their wrappers said `+tablePage(orgTablePageData)` while that helper was registered on
Template.people - the PARENT template. Blaze resolves a name against the current
template's helpers, the global helpers and the data context; it never searches an
enclosing template. So the context came out undefined, and a table page with no
rowCount draws its chrome and stops. Nothing threw and every test passed.
Domains is the control that proves it: its helper sits on Template.domainGeneral, the
template that uses it, and Domains kept working the whole time.
The parent builds the context now - where the helper actually lives - and hands it
down, so each wrapper renders `+tablePage(this)`. The named arguments the wrappers
used to take (orgList, orgCurrentPage, hasOrgPrevPage, ...) went unused once these
panes moved to the shared page, so they go too.
A new test walks every `+tablePage(name)` in that file, works out which template it is
written in, and requires `name` to be a helper OF THAT TEMPLATE unless it is `this`.
Verified it flags `orgGeneral -> orgTablePageData` when the bug is put back.
Also: the selected left-menu entry is darker and bold, so the menu says at a glance
which page is showing on the right. Its colour fell back to `inherit`, which made it
exactly the same grey as every unselected entry - the white background and soft shadow
alone were easy to miss. A per-user theme accent still wins; only the fallback changed,
from `inherit` to a grey darker than the panel's. The icon takes the same colour as its
label.
Tests: 1347 passing.
Thanks to xet7 !
The Visibility pane now reads, top to bottom:
Custom Product Name
Hide Logo
Boards visibility: Allow private boards only
Don't show the board activities on all boards
... the rest, unchanged
Custom Product Name and Hide Logo were far down the pane among the logo URLs; they
are the two settings that name and brand the instance, so they belong above the
visibility choice rather than below a dozen link fields.
"Don't show the board activities on all boards" had a left-menu pane of its own for
one radio pair. It is a visibility setting, so it moves into this pane, directly under
the visibility choice, and the pane, its menu entry, its reactive var, its helper and
its branch of the pane switch all go with it. Its own Save button moves with it: the
click handler is registered on the parent template, so it keeps working by delegation
exactly as before, and folding the field into the pane's main Save would have meant
rewriting that write for no gain.
Its save handler is untouched, so the guard that matters still holds: a radio it
cannot find is skipped rather than written as false. That is the trap this whole
series of moves keeps setting - a save left reading an input that moved silently
turns the setting off.
Tests: 1346 passing.
Thanks to xet7 !
Every Admin Panel page except Problems drew a title bar under the top bar, repeating
the name of the pane you were already looking at: "Registration" above Settings, "Info"
above Version, and so on. The top bar already says which section you are in and the
left menu highlights the open pane, so the third line only cost vertical space.
Problems has never had one; the rest match it now.
Settings, Version, Features and Attachments carried nothing but a title, so their bars
are simply gone.
People's bar was not only a title: the Organizations and Teams panes searched from a
box and button inside it, and it showed their row counts. The searches move into the
shared table page's controls row - which is where People's own pane already searched
from - and the counts were already shown there as the table's total, so they needed no
new home. One keydown handler now dispatches on the open pane, the way the pager and
the filters already do, and each pane keeps its own search term so switching panes does
not carry a search across.
What the bars left behind goes with them: the `.ext-box` rules in peopleBody.css and
translationBody.css, `.content-title` in settingBody.css, and the three count helpers
that fed the bar - all dead once the markup went, and all verified unreferenced first.
CSS was removed rule-by-rule with a brace-balance check before and after, because
line-filtering this same file orphaned five rule bodies once already.
Three existing tests asserted things that were true only while the bars existed - the
themed search button, the search handler's scoping, the PWA pane header - and now
assert the same properties in their new homes.
Tests: 1346 passing.
Thanks to xet7 !
Settings, People, Features, Attachments, Version and Problems all rendered an empty
panel where their left menu belongs.
The seam between the two halves of the shared menu was wrong. leftMenu.jade iterates
`each items`, and every page handed it the bare ARRAY that buildMenuItems returns - so
Spacebars looked `items` up ON the array, found nothing, and rendered nothing. The
template's own comment said the data context is `{ items }`; the six call sites did
not provide it.
Nothing failed anywhere: the template was correct, the helper was correct, every unit
test passed, and the menu was simply not there. Six pages lost their navigation to one
mismatched shape.
A new leftMenuData() states that shape once, in models/lib/leftMenu.js, and all six
pages build their context through it. buildMenuItems keeps returning an array, which
is what activeCount and the tests want.
The guard that was missing is the one that checks the SEAM rather than either half:
it reads which variable leftMenu.jade iterates, calls leftMenuData, and asserts the
returned context actually has an array under that name - so renaming the loop variable
or handing back an array fails the suite. A second test asserts no page calls
buildMenuItems directly in its menuItems helper, since that is exactly the mistake
that empties one page's menu while the others keep working.
Verified both fail when the bug is put back, then pass again when it is removed.
Tests: 1346 passing.
Thanks to xet7 !
The fixed-size light grey band between the blue resize bar and the next swimlane's
dark header - the one that travelled with the bar as the swimlane was resized - is
gone, along with its twin between a swimlane's header bar and its first list.
They were plain bottom margins on the swimlane header (1rem) and on each list (2rem).
On the LAST list that margin is exactly the band between the content and the resize
bar; being a fixed size it moved with the bar rather than growing, which is what
"moves along" described. Lists are separated by the 2px border under each of them, so
nothing is lost by removing it.
The reason the previous attempt did not take: boardHeader.css restates the same
selectors in SEVERAL later blocks - the mobile overrides, a max-width media query, and
a "force mobile mode to override any media query styles" block. Later rules of equal
specificity win, so zeroing the margin in the first block only looked fixed while
eight duplicates put it straight back. All of them are zeroed now.
That is the more useful lesson, so the test checks EVERY block in the file rather than
the first one it finds: no rule under .mobile-mode may leave a non-zero bottom margin
on a swimlane, a swimlane header or a list, written as either `margin-bottom` or the
four-value `margin` shorthand. Verified it fails when one duplicate is put back, so it
is not passing by construction.
Tests: 1344 passing.
Thanks to xet7 !
Follow-up to 4d67952ec, correcting it on two counts.
The grey band between the blue resize bar and the next swimlane's header was the 2rem
bottom margin on `.mobile-mode .swimlane`. The bar is pinned to the bottom edge of the
lists container, so a margin AFTER that container is a fixed band of grey sitting under
the bar - and it travels with the bar as the swimlane is resized, which is exactly how
it was described. The margin is gone: on a phone every swimlane already begins with its
own darker header bar, which separates them perfectly well. That also removes the same
band from between a swimlane's own header and its lists, since the selector matches the
header wrapper too - so the separate override added for that in 4d67952ec is no longer
needed.
The header wrapper is now only as tall as the header bar inside it. It is a `.swimlane`
as well, so it picks up that element's sizing, and anything left over renders as the
lighter grey of `.swimlane` around the darker bar.
And 4d67952ec was wrong to force `height: auto !important` on the lists container. The
height being dragged IS that inline style, so overriding it made the resize bar do
nothing at all. Only the floor is removed - `min-height: 150px` held a short swimlane
open below the height chosen for it, and THAT leftover was the grey above the bar. The
chosen height is honoured, so what is above the bar is whatever the swimlane was
resized to.
A test now asserts the dragged height is NOT overridden, so this cannot be
"fixed" back into a bar that does nothing.
Tests: 1343 passing.
Thanks to xet7 !
The blue resize bar is pinned to the bottom edge of the swimlane's lists container, so
any height that container has BEYOND its content shows as a band of empty grey between
the last list and the bar. On a phone there was a lot of it.
Two things gave it that extra height, and both are desktop assumptions:
* the container carries an INLINE `height` from the stored swimlane height - a height
the user chose for the DESKTOP layout, where lists sit side by side. Stacked full
width in mobile mode the same lists need a completely different height, so the
difference showed as dead space (and made the container scroll vertically on its
own, which is the second scrollbar in the screenshot);
* `min-height: 150px` on .swimlane.js-lists.js-swimlane held a short swimlane open
even when its content was smaller.
In mobile mode the container takes its content height instead, so the bar lands
directly under the last list - which is also directly above the next swimlane. Both
need !important: an inline style loses to nothing less.
Also removes the gap between a swimlane's header and its OWN lists. The 2rem bottom
margin is meant to separate one swimlane from the next, but `.mobile-mode .swimlane`
matches the header wrapper too, so the same 32px band sat between a header and the
lists belonging to it.
Tests: 1342 passing.
Thanks to xet7 !
Regression from moving Add List into the mobile list header in 61979c0f6. In mobile
mode the whole list row is an `a.mini-list.js-select-list` and the + sits INSIDE it,
so one click did both things: it opened the composer AND selected the list, so asking
to add a list took you into one instead.
The handler already called preventDefault, which is a different thing - it stops the
anchor's own navigation, not the click travelling up to the ancestor's handler. It
needs stopPropagation.
Harmless on desktop, where the button is not nested inside a select-list anchor.
Tests: 1340 passing.
Thanks to xet7 !
The lists area was a little too wide - a horizontal scrollbar with a small amount to
scroll right and nothing there to see. Two causes.
`100vw` again. It was fixed in boardHeader.css in 72315d8f9, but boardBody.css (18
values) and list.css (32) had the same thing, including `.mini-list.mobile-view` -
the very rows a phone shows. 100vw is the viewport width INCLUDING the vertical
scrollbar, so each of those was a scrollbar wider than the box it sat in. They had
been dormant: the `.mobile-view` class comes from isMiniScreen, which only started
being true on a desktop window once the explicit mobile-mode toggle began driving it.
An absolutely-positioned 100vw hairline in the settings body went the same way - it
stuck out past its parent and made that page scroll sideways too.
100vw is KEPT where it is right: a position:fixed overlay (the mobile card details,
a popover, the sidebar, the notifications drawer) is sized to the viewport by
definition and is not in the flow of a scrolling container. A test asserts that the
two it checks really are position:fixed, so the exception cannot be borrowed for an
in-flow element.
box-sizing. `* { box-sizing: unset }` (layouts.css) makes content-box the default, so
a rule that sets `width: 100%` AND `padding: 1rem` is 32px wider than its parent. The
swimlane header, the list header, the list body and the minicard all do exactly that,
at four nesting levels. They now measure their padding inside.
Then the vertical alignment, in four places:
* The swimlane title was a block at the TOP of a band whose height comes from the
padding and the icons beside it. It is a flex box centred on its line now, and the
wrap centres its children so the title and the icon row share one centre line.
* The list title was pinned to the BOTTOM of grid row 1 with the card count pinned
to the TOP of row 2, so the pair hugged the middle - but with no card count row 2
is empty and the title sat in the upper half. Both centre in their own row.
* The quick-access bar declares `height: 28px`, which with box-sizing unset is the
CONTENT box. Its children are ~40-44px on a phone for touch, so they overflowed a
short box, were clipped by its `overflow: hidden`, and read as sitting high. The
bar takes its content height with a 48px floor and symmetric block padding.
* The board bar centred its items inside a box padded 7px above and 0 below, which
put everything half that distance high; its padding is symmetric now, and the
title's own line box is tightened so the text centres rather than floating at the
top of a tall line.
Tests: 1339 passing.
Thanks to xet7 !
On a phone the "+ Add List" composer stood as a row above the lists, spending a whole
row on one button. The + now sits in each list header, BETWEEN the caret and the drag
handle, so the caret moves left and the + takes the middle of that group.
This is what desktop already did. #6465 moved Add List into the list header there and
left the mini-screen path alone, so the two had drifted apart. The mobile button now
uses the SAME class (js-add-list-here), therefore the same click handler and the same
behaviour - open the inline composer after this list - and the same Font Awesome icon,
fa-plus-square-o. One button in two layouts rather than two lookalikes that can drift
again.
The mobile list-header grid grows from four columns to five: title, caret, +, handle.
RTL mirrors on its own. Nothing here is placed with a physical left/right: the header
is a CSS grid, and a grid lays out along the INLINE axis, so under dir="rtl" column 1
is on the right and the whole row reverses - handle, +, caret, title. A test asserts
no physical side creeps into any of the three placements, since one `right:` would
strand a control on the wrong edge.
An empty swimlane and an empty board keep a + of their own, as on desktop: there is no
list header to host the button when there are no lists, and without it the first list
could never be created.
The addListForm template is removed. It rendered that standing row, mobile mode was
its last caller, and it is dead once the button moves. Its three handler blocks go
with it - a Template.X.events() left on a removed template throws at MODULE LOAD and
takes out every module after it in the client bundle, which is how the password field
disappeared from /sign-in in 696c49038. tests/templateHandlersExist.test.cjs covers
that, and passes.
Two existing suites referred to addListForm in comments describing the old shape;
both are updated to describe the current one.
Tests: 1332 passing.
Thanks to xet7 !
Asked whether the same clamp()/viewport-unit bug exists anywhere beyond the
stylesheets already swept. It does not - but the guard only ever looked at
`client/**/*.css`, so "it does not" was not something the suite could actually say.
Three places a viewport unit renders exactly like a stylesheet and the scan never saw:
* an inline `style=` in a .jade template (client/ and packages/)
* CSS built as a JS string - client/lib/exportHTML.js builds a card modal that way,
and sandstorm-src/migration-bridge.js builds a whole page
* stylesheets outside client/: our own packages/ and public/css
All three are now scanned, and all three are clean. What they do contain is the
allowed shapes, which is useful: the exported modal's `max-height: 80vh` keeps it
inside the window, and the migration bridge's `min-height: 100vh` is a full-viewport
box. Vendored stylesheets (fullcalendar, the jade-loader fixtures, FerretDB, .build
output, the generated Redoc page at public/api/wekan.html) are not ours and are
excluded.
A scan that silently reads nothing passes forever, so one more test proves these are
not vacuously green: it asserts the JS scan really finds the exported modal's cap in
the tree today, that the cap is allowed, and that the declaration splitter pulls
`padding:3vh 3vw` out of a run-together style string the way it would appear in a
cssText or a style attribute - and that the splitter's output is rejected.
Tests: 1325 passing.
Thanks to xet7 !
Reported on a board in mobile mode in desktop Firefox: widening the window made the
swimlanes, lists and cards taller; narrowing it shrank them again. The same complaint
as /sign-in and /sign-up, and the same cause - a size measured against the WINDOW
instead of being a size.
The earlier sweep converted 355 bare `vh`/`vw` values but explicitly ALLOWED
`min()`, `max()` and `clamp()`, on the grounds that they are caps. `clamp()` is not.
It is only a cap at its two ends; between them it tracks the viewport exactly like a
bare `vw`. So `font-size: clamp(18px, 2.5vw, 32px)` on a swimlane header, a list
header and a minicard is a font that grows with the window - and since those rows are
sized by their text, the rows grow with it. There were 75 of these across 17
stylesheets, 36 of them in the mobile-mode board rules.
All 75 are converted to the size they already rendered at on a phone - the lower bound
of each clamp. That is the value these rules were designed around (below ~800px the
clamp was pinned to it anyway), it is in line with the rest of the UI's fixed sizes,
and picking the upper bound instead would have made every phone bigger than it is
today.
Also converted, same behaviour by other spellings:
* `.board-sidebar { width: clamp(320px, 30vw, 560px) }` -> a fixed 420px. Its own
comment recorded 420px as the intended width; the clamp was added to stop a bare
30vw doubling on wide screens, but it still resized in between.
* `min-height: 3vh` on the mobile minicard -> 24px.
* `min-height: 60vh` on a collapsed list -> 540px, which is exactly what the
`height: 540px` on the very next line already says.
* `min-height: 60vh` (settings body) -> 540px; `min-height: 14vh` (search popover)
-> 126px.
* `max-width: 13vw` on a minicard custom-field chip -> 160px.
tests/noViewportSpacing.test.cjs no longer allows clamp() or a viewport `min-*`, and
says why. What stays allowed is a full-viewport box (100vh/100vw), a `max-height` /
`max-width` cap, and `min(400px, 52vw)` - a shrink-only cap, flat at the px above the
crossover width and giving way only below it so a box fits a narrow screen. It never
grows with the window, so it is not this bug; `max(...)`, which does grow without
bound, is not allowed. Both argument orders are accepted.
tests/sidebarWidth.test.cjs required `clamp()` for the sidebar - that was the fix for
the doubling, and it is now the thing being removed. It asks for a fixed px width and
no viewport unit at all, which is a stronger form of what it was guarding.
Tests: 1321 passing.
Thanks to xet7 !
Reported with two screenshots of the same app: on an iPhone 12 mini the second header
bar held a handful of icons and no board title, while a desktop Firefox window in
mobile mode showed the title and the full set of buttons. Same mode, two bars.
Mobile layout is driven from three switches that did not agree: `body.mobile-mode`
(the toggle), `Utils.isMiniScreen()` (which template branch renders) and
`@media (max-width: 800px)` (the viewport - true on a phone, false on a wide desktop
window even with mobile mode on). The first two were made to agree in a5246fbf5; the
rules that assumed the third are fixed here.
`.mobile-mode .board-header-btns.left { display: none }` is removed. The left group
holds edit title / visibility / watch / star / sort, and boardHeader.jade renders them
in EXACTLY ONE of the two groups - left `unless isMiniScreen`, right `if isMiniScreen`.
So in mobile mode the left group is already empty and hiding it changes nothing,
EXCEPT when the switches disagree, and then it deletes those five buttons from the bar
with no replacement. Gone, so that if the switches ever drift again the buttons survive
instead of vanishing.
The phone block gave the bar a fixed `height: 48px` for #6419's touch targets. A fixed
height CLIPS the second row the bar wraps to when title + buttons do not fit on one -
part of the bar was simply not there. Now `min-height`, so the targets keep their size
and the bar can grow; it still sits on one row whenever the content fits, which is the
normal case.
The list title is visible in mobile mode again, on both. listHeader.jade has two
shapes: on a mini screen the `h2.list-header-name` is a direct child of `.list-header`,
otherwise it is wrapped in a div (the one that rotates when a list is collapsed).
Mobile mode lays the header out as a grid and places the title by grid row/column,
which only applies to a direct grid ITEM - inside the wrapper the placement was ignored
and the title landed in the 30px first column, squeezed to nothing. `display: contents`
drops the wrapper from the layout so the title is a grid item in both shapes. Not for
`.list-rotated`, which needs a real box to rotate, nor for the screen-reader move
buttons.
The board reflows sideways again instead of overflowing by a sliver. The mobile board
rules sized the canvas, swimlanes, lists and list headers with `100vw` - the viewport
width INCLUDING the vertical scrollbar. The canvas scrolls vertically, so every one of
those was about a scrollbar's width wider than the box it sat in, at each nesting
level, and `min-width` pinned to the same value meant it could not shrink. All 18 are
now `100%`, which resolves against the parent's content box and already excludes the
scrollbar.
Tests: 1321 passing.
Thanks to xet7 !
On a coarse (touch) pointer the handle was a full-height strip down the LEADING
edge. That was added for #6521 for a good reason - on a touch device the handle is
the ONLY way to drag a card, since the card body deliberately pans the board
instead, so the 20-28px corner icon was too small a target to hit. It reached the
size goal but put the handle on the opposite side of the card from every other card
control, and from where a mouse user's handle already sits.
Both pointer kinds now put it in the same place: the details menu at the top of the
trailing edge, the drag handle directly BELOW it, as one column. The touch version is
just bigger. A mouse keeps the compact corner handle - `pointer: coarse` does not
match a mouse - and that one was already below the menu button, so the two placements
now agree instead of being mirror images of each other.
The touch target is not given up: the handle is 44px wide and runs from under the menu
button to the bottom of the card, so a tall card gives a tall target, with a 36px floor
for a card holding nothing but a title. The card reserves the column as trailing
padding so its text does not run underneath, and is at least 68px tall - menu (32) plus
handle minimum (36) - so both fit.
The menu button is pinned rather than floated inside that block: the card's new
trailing padding would push a float:inline-end button inward, and it would no longer
line up over the handle. Both are the same width, so they read as one column.
Everything stays in logical properties, so the column mirrors to the left edge on an
RTL board rather than being stranded.
The handle renders on `canMoveCard && showDragHandles()`, the same pair of conditions
that adds the `minicard-with-handle` class - so the reserved space and the handle
always appear together, never one without the other.
Tests: 1316 passing.
Thanks to xet7 !
Four things reported while using mobile mode, three of them in the second header
bar.
Drag-to-scroll now works on BOTH top header bars, not only below them. Everywhere
else a drag scrolls - `.board-canvas.dragscroll` on a board, `<body>` / `#content`
on the whole-page layouts - but the two header bars were dead, and on a phone they
are a large share of what is on screen. They cannot simply be tagged `.dragscroll`:
that class scrolls the element carrying it, and neither bar is a scroll container -
`#header` sits outside `#content` and outside the board canvas. So a new module,
client/lib/headerDragscroll.js, forwards the drag to whatever actually scrolls: a
scroller inside the header first (the starred-boards list is overflow-x:auto), then
the board canvas, then the page scroller. Both bars are `.nodragscroll` so the
page-level dragscroll does not scroll a second time from the same gesture. Mouse and
touch are both handled - a phone sends no mouse events, and the dragscroll library is
mouse-only and element-bound. A tap is still a tap: scrolling starts only past a 4px
threshold, and only then is the click that ends the gesture swallowed, in the capture
phase, so dragging across the bar does not press whatever you let go over.
The second header bar on a phone now reads title, buttons, hamburger. The board title
is shown again - it was hidden by a `display: none !important` that predates this
work, which left the bar with nothing but icons, so you could not tell which board you
were on. A board name is how you know where you are, so it wraps rather than
truncating. The buttons start at the right of the title and drop to a second row as a
block when the space between the title and the menu button runs out; they are one flex
item, so they never split across the two rows.
The sidebar hamburger, with its divider to its left, is pinned in the TOP RIGHT
corner. It was lifted out of the `.right` group into its own flex item placed after
the title, because inside that group it could only ever wrap down together with the
other buttons - a flex line breaks in order. On a phone it is taken out of the flow
(position:absolute) and the bar reserves its width as end padding, so a long title or
a full row of buttons never runs underneath it; that reservation is board-only, since
the same bar on All Boards has no hamburger. On a wide screen `order: 1` puts it back
at the end of the bar, visually identical to before.
Lists and cards are full width in mobile mode on a DESKTOP browser too, not only on a
phone. Two causes, both from mobile mode being decided in two places that disagreed:
* Utils.isMiniScreen(), which drives the `mobile-view` class on each list, swimlane
and minicard, looked only at screen width and user agent. The explicit toggle was
honoured on iPhone only - and even there through a test that could never be false,
since getMobileMode() falls back to viewport detection and so always returns a
boolean. An explicit choice now wins on every device, via a new
getExplicitMobileMode() that can answer "never chosen"; the per-device branches
below it are the defaults for that case.
* `.mobile-mode .list { width: 100% !important }` was outranked by
`.js-swimlane .list[style*="--list-width"] { width: var(--list-width) !important }`
- both !important, and the second more specific. It never showed on a phone (no
inline --list-width is emitted there), only in mobile mode on a desktop window.
The override repeats those three selectors prefixed with body.mobile-mode, and
keeps the :not(.list-collapsed) exclusion so a collapsed list stays 30px (#5892).
Also adds tests/jadeCompiles.test.cjs, which compiles every .jade with the SAME
compiler the build uses. Nothing else caught a broken template: the other suites read
.jade as text and grep it, so a file the compiler rejects still passes them all. It
was written after a `<body>` inside an indented `//-` comment block broke the build
here - the comment text is still lexed, so the angle brackets opened a tag that never
closed. All 107 templates parse in ~0.2s.
tests/headerHamburger.test.cjs asserted the hamburger sits inside the `.right` group,
which is exactly what moved; it now checks the new wrapper, its divider, and that
`order` still puts it last on a wide screen.
Tests: 1309 passing.
Thanks to xet7 !
The second header bar in mobile mode had nothing but icons - you could not tell
which board you were on. The title was hidden by
/* Hide the board title in mobile mode to match mobile view */
.mobile-mode .header-board-menu { display: none !important; }
which predates this work; it was not lost in the recent header changes, the markup
still rendered it.
It fits now, and on two rows by design: the title takes the WHOLE first row and the
button group - one flex item since the earlier header change - wraps to the second
row entire. Sharing one row would squeeze the title down to a few characters, which
is presumably why hiding it looked like the lesser evil before.
A long board name wraps rather than truncating: the name is how you know where you
are, so it is worth the extra line.
The rest of what is absent from that bar on a phone is unrelated and unchanged:
edit / visibility / watch / star / sort are not rendered at all under
`unless isMiniScreen`, and reappear as icon-only buttons in the right group.
Tests: the title must not be hidden by any rule, it takes a full row and wraps,
the button group takes the second row, and the two rules stay in row order. The
suite reads boardHeader.css for these - the mobile rules live there, not in the
header.css it otherwise reads.
Thanks to xet7 !
The page ended at the bottom of the form with nothing to scroll into.
Two <br> were already there for exactly this, with a comment saying so - they
just did nothing. `body` is `display: flex`, so a <br> at the layout root becomes
a FLEX ITEM: it gets blockified, has no content, and collapses to zero height.
Adding more would have added more nothing.
It is a real element now, .auth-bottom-space, 96px tall and flex:0 0 auto so it
cannot be shrunk back to nothing. That gives room to scroll the bottom of the
dialog - and the language selector under it - clear of the window edge, and of the
on-screen keyboard on a phone.
The height is px, not vh: this is spacing, and spacing must not change with the
window (tests/noViewportSpacing.test.cjs, from the previous commit).
Tests: the spacer exists, has a fixed height and is not shrinkable, and no bare
<br> sits at the layout root. Scoped to the root on purpose - the <br> nested
inside the h1 when the logo is hidden is in normal flow and works fine, so the
check must not condemn it.
Thanks to xet7 !
Reported on /sign-in and /sign-up: making the window taller made every element
taller and every gap wider; making it shorter shrank them. That is what vh does -
`padding: 3vh 3vw`, `margin-top: 6vh`, `min-height: 4.5vh` - the box is a
percentage of the WINDOW, so the page reflows continuously as you drag the edge
and the same layout looks different on every screen.
It was not only those two pages. 355 such values across 24 stylesheets, on
padding, margin, gap, height, line-height, font-size, border-radius and
box-shadow. They are now the pixel sizes they rendered at on the window they were
tuned for (1vh -> 9px, 1vw -> 14px), so each page looks as it did at that size and
stays that size everywhere else.
Two of them were documented bugs already: minicard.css carries two comments
explaining that the global `.viewer { min-height: 2.5vh }` "reserves a big empty
band under a one-line title, so half of every minicard was white space" on tall
screens. That floor is 22px now, and the modal body's 20vh is 180px.
Viewport units are still right for three things and are kept: a full-viewport box
(100vh/100vw), a CAP that stops content overflowing a small screen (min(), max(),
clamp()), and max-/min-width limits. 274 such uses remain, all deliberate.
The conversion was a token substitution - it cannot move or delete a rule - and
brace balance was asserted unchanged for every file before writing it.
Tests: tests/noViewportSpacing.test.cjs scans every stylesheet under client/ and
fails on any size or spacing measured in vh/vw, while still permitting the three
legitimate shapes (it checks both directions). It blanks block comments first, so
the two minicard.css comments ABOUT this bug are not reported as uses of it. One
existing test pinned the literal `2.5vh` global floor; it now pins a px floor, and
the dependency it documents - that the minicard override compensates for a global
floor - is unchanged.
Thanks to xet7 !
A handler left registered on a removed template threw at module load, which
stopped every later module in the client bundle - including the one that
registers the passwordInput template - so both password fields rendered as
nothing on Sign In and Register.
Thanks to xet7 !
My own regression, and a bad one: the login form had no password input.
When the Accounts pane was removed from Admin Panel / Settings - its three
settings having moved to Email and Login - its save handler was left registered on
the template that went with it:
Template.accountSettings.events({ ... }) // accountSettings no longer exists
That throws at MODULE LOAD, and because it throws, no module after it in the
client graph runs. client/features/users.js never executed, so passwordInput.jade
was never registered, and useraccounts logged
[UserAccounts] Warning no template passwordInput found!
then rendered nothing for the two fields that use it - password and
password_again. One dead reference in the Admin Panel took out the login form for
everyone.
The handler moved to Template.setting, which renders the Login pane its button
lives in.
Why nothing caught it: the file parses, every unit test passed, and the failure
only ever appears in a browser console. So the guard is new -
tests/templateHandlersExist.test.cjs walks every .js under client/components and
asserts each Template.X.events/helpers/onCreated/onRendered/onDestroyed has a
matching template(name="X") in some .jade. It ignores commented-out code (there is
a Template.cards.events() in a comment in minicard.js) and package-provided
templates. It fails on the pre-fix file.
Diagnosis notes, since "password field is missing" points nowhere near the Admin
Panel: the field was correctly registered - removeField returns the field object
and it is in addFields - and the compiled passwordInput template WAS in the served
bundle. What it was not was executed. The console error naming
Template.accountSettings is what tied the two ends together.
Thanks to xet7 !
It was a top-level Admin Panel page with its own shell, its own left menu and its
own route. It is one entry in the Settings menu now, between Accessibility and
PWA.
The whole page template had to become the pane, not just its table. The state that
feeds the table - the subscription, the search, the infinite scrolling, the count -
lived on Template.translation, and Template.translationGeneral reads it from
there. Moving only the table would have left it looking up state on a parent that
no longer renders it, and the pane would have shown an empty table with no error.
So Template.translation became Template.translationSettings, keeping its
onCreated, helpers and events together with the markup that needs them.
Two things it no longer needs: its own left menu (Settings provides one) and the
menu handler that toggled translationSetting - a pane is either rendered or not.
The /translation URL still resolves. It redirects to Settings rather than being
deleted, so an admin with a bookmark lands where the pane now lives instead of on
a template that no longer exists.
Tests: it is an entry in the Settings menu and Settings renders the pane; the
top-level tab and its active-helper are gone; the state moved with the markup
(Template.translation must no longer exist); and the route redirects rather than
rendering the removed template. The leftMenu suite no longer counts Translation as
a page with a menu of its own - it is one entry in another page's menu now.
Thanks to xet7 !
The last loose end of the People conversion. Its search box, its show-filter
dropdown, its "Unlock all users" and "Add / Remove Teams" buttons and its user
count lived in the PAGE HEADER, a different template from the table they act on.
They are the shared controls row now - the same slots this design gained FROM
People a few commits ago, finally used by it.
Its separate Search BUTTON is gone. Every table page searches on Enter, and a
second way to search is exactly the divergence this design removes.
Three things had to change with them, not just move:
- The search term is STATE (peopleSearchTerm) instead of being read back out of
$('#searchInput') - that id lived in the other template and no longer exists, so
filterPeople() would have searched for undefined.
- "Unlock all users" was a handler BODY. It is an instance method now, called by
the shared action handler via data-action, because the button is no longer
identified by its own id.
- The filter reset on render poked $('#userFilterSelect').val('all'). The shared
row renders the select from userFilterType, so it sets the state instead; the
old code would have silently done nothing.
All three handlers are scoped to the open pane, like the pager: every People pane
renders inside one template and they all carry the same shared classes.
Tests: none of the five removed ids survives in the header, the filter and actions
are declared to the shared row, the search term is state, the reset sets state,
and each of the three handlers is scoped to people-setting.
Thanks to xet7 !
Locked users is a form of numeric lockout settings with a Save button, Roles is a
checkbox list, and Shared templates is a checkbox list of scopes. None has a
paginated set of rows, so this design does not apply to them - forcing it would
only wrap a form in a table. They are listed with that reason so the next person
does not read the code to find out, or convert them by mistake.
That completes People: all FOUR of its table panes - Domains, Organizations,
Teams and People - render through the shared table page, and its three non-table
panes are documented as out of scope. The old entry asking "what converting it
would take" is answered and replaced.
One loose end stays recorded, as wiring rather than design: People's search box,
filter dropdown and two action buttons still live in the page header rather than
the shared controls row. The slots for all three exist - they were added to this
design FROM People - and its separate Search button should go when they move,
since every table page searches on Enter.
Tests: the three panes are listed with "not tables" as the reason, and none of
them renders a table page in the code - so the doc cannot drift from what is
there, in either direction.
Thanks to xet7 !
Fourth and last of People's table panes. Interactive rows again (rowTemplate) and
two template headers - the new-user row and the select-all checkbox. Its
.people-pagination rules are gone from both stylesheets, so NO People pane keeps a
pager of its own any more; all four use the shared, themed one.
The page of users is now one query. peopleDocs() is shared by the table context
and the old peopleList helper, instead of the same find() being written twice, and
it still must not re-slice: the 'people' publication already applies limit/skip
sorted createdAt:-1, and re-slicing it is what once left page 2 showing a single
stray doc - the admin's own user record, always in minimongo - with later pages
empty. A test pins both.
The Add/Remove Teams panel stays outside the table page: it is a panel this pane
opens, not part of the table.
All four table panes now share ONE scoped pager pair, switching on the open pane -
the only shape that works here, since every pane renders inside the same template
and duplicate keys in one event map would overwrite each other.
Remaining: Locked users, Roles and Shared templates. The last two still do not
look like tables at all - Roles is a checkbox list with a Save button - so they
may belong in the "does not use this design" list rather than converted.
Not yet moved: People's search box, its filter dropdown and its two action buttons
still live in the page header rather than the shared controls row. The slots for
them exist; wiring them across is the remaining step for this pane.
Thanks to xet7 !
Same shape as Organizations, so the same two slots: a rowTemplate for its
interactive rows and three headerTemplate columns for the select-all pairs. 1857
characters of its own table markup gone, plus its .team-pagination rules from both
stylesheets. Its three feature headers share ONE template parameterised by
feature, as Organizations' do.
Teams gains a working PREV button. It had one in its markup and no handler behind
it - paging backwards was silently dead - and folding both panes into a single
scoped handler pair fixed that on the way past.
That folding was forced, not chosen: every People pane renders inside the same
template and the shared page gives them all the same control classes, so a second
handler for the same selector would be a duplicate key in one event map and simply
overwrite the first. One pair now switches on the open pane.
Tests: Teams renders the shared page and keeps no table markup, uses both slots,
pages backwards, and there is exactly ONE prev handler. The uiDensity guard that
pins these headers as compact icon links was updated for the team half the same
way as the org half - it matches the parameterised markup and separately checks
all three features still have a header.
I ran the full suite BEFORE committing this time. The previous commit went in red
because I chained the run and the commit in one command; that guard's team half
was the failure it hid.
Four panes remain: People, Locked users, Roles and Shared templates.
Thanks to xet7 !
It pinned the org select-all links by their LITERAL data-feature values. The three
copies of that markup are now one shared header template parameterised by feature,
rendered through the table page's headerTemplate slot, so the literal match could
not hold. The intent - compact icon links, never full-text ones - is unchanged: it
now matches the parameterised markup and separately checks all three features still
have a header, so a dropped column would still fail.
This should have been in the previous commit. I committed it before reading the
full-suite result; the suite was red for one commit.
Thanks to xet7 !
Organizations could not be expressed as a column spec: its rows carry inline
checkboxes and edit links, and three of its headers carry a select-all pair. The
design gains two slots rather than those panes staying outside it:
- rowTemplate + docs - the page supplies a template and one data context per row,
and owns its <tr>. It is then responsible for matching the column count: the
guarantee that a row can never be shorter than the header holds for the CELLS
form only, and the doc says so.
- headerTemplate + headerData on a column - the <th> still belongs to the shared
template; only its contents come from the page.
Everything else stays shared either way: layout, paging, search, the themed pager,
the total. The doc says to prefer the column spec and reach for these only when a
pane is genuinely interactive.
Organizations now renders through the shared page - 1826 characters of its own
table markup gone, plus its .org-pagination rules from both stylesheets, since it
uses the shared pager. Its three feature headers share ONE new template
parameterised by feature, instead of three copies of the select-all pair.
One thing the conversion forced: all of People's panes render inside the SAME
template, so a handler bound to a shared control class fires for every converted
pane at once. The org pager is scoped to the open pane via activeMenuId - Domains
was unaffected because its handlers live on its own child template.
Tests: the two slots exist and the plain column path is unchanged; Organizations
renders the shared page, keeps no table markup, uses both slots, and scopes its
pager. Two doc/test pairs updated to say "Domains and Organizations".
Five panes remain: Teams, People, Locked users, Roles, Shared templates.
Thanks to xet7 !
First of People's seven panes converted to docs/Design/Page/Table.md. Its own
controls row, pagination markup and table - 891 characters of jade - became one
+tablePage(tablePageData) plus a two-column spec, and 56 lines of pane-specific
CSS are gone: the layout comes from tablePage.css and the pager colours from
paginationControls.css, like every other pager.
Its separate Search BUTTON is dropped, as the design says: every table page
searches on Enter, and a second way to search is exactly the divergence this
design removes. The handlers keep their behaviour but move to the shared control
classes, so the pane needs no markup, no CSS and no pager rules of its own -
.domain-pagination and .domain-page-info had no users left and are removed from
the shared pager stylesheet.
The pane also gains the result total for free: it is one of the controls-row
features adopted from People itself a few commits ago.
Docs: the "Pages that do not use this design" entry now reads "People - six of
its seven panes" and records that Domains is converted; Domains is listed among
the pages that DO use the design.
Tests: the entry must say Domains is converted, and that pane must render the
shared template and keep no markup of its own - so the doc cannot claim a
conversion that did not happen, nor stay silent about one that did. A test that
listed Domains among the panes with their own themed pager was updated; it caught
the now-dead CSS, which is what it was for.
Six panes remain: Organizations, Teams, People, Locked users, Roles and Shared
templates.
Thanks to xet7 !
Two follow-ups from the Admin Panel / Settings reorganisation, recorded with
their reasons so whoever picks them up knows the scope:
- The docs and the website still describe the OLD layout - the Layout pane (now
PWA), the Accounts pane (removed), the previous homes of about a dozen settings,
and the two renames (Boards visibility -> Visibility, Registration -> Login).
The settings moved and are tested; only the prose is behind.
- docs/Features/ does not mirror the current menu, so a menu path cannot be
mapped to a docs path. Restructuring it is a rename-and-relink sweep: the design
docs under docs/Design/Page/ link into those folders and their tests assert the
links resolve, so both have to move in one commit.
Thanks to xet7 !
The pane keeps what makes an instance installable - the custom head tags, the web
app manifest and assetlinks.json - and everything else moves to where it belongs:
- branding to Visibility: product name, hide logo, login logo image/link, text
below the login logo, the three top-left corner logo fields, the custom help
link and the automatic linked URL schemes;
- the OIDC button text to Login, with the rest of the sign-in configuration.
PWA is an acronym, not a translated string, so the menu entry and the pane header
use a LITERAL label - the same support the shared left menu grew for the Sandstorm
entry in Attachments. No i18n key was invented for it.
js-save-layout is gone with its button. Its fields are written by the panes that
now show them, each only when its input is actually rendered, so no pane can blank
a setting it is not displaying. The product name still retitles the page.
This redoes, correctly, the work I reverted after corrupting this file: the block
extractor now works on LINE ranges bounded by the template end, instead of slicing
to "the next li" - which ran past the template and dragged the announcement pane's
markup into Visibility. The 16 top-level blocks are enumerated with their exact
boundaries before anything moves, and the template count is checked afterwards.
Tests: the pane is pwaSettings and keeps exactly the four PWA blocks; branding and
sign-in settings are NOT in it; PWA is a literal label with no i18n key; the
branding group is in Visibility with a guarded save; and js-save-layout is gone
entirely, so no handler is left reading inputs that now live elsewhere.
Thanks to xet7 !
"Display Authentication Method" (Yes/No) and the default-method dropdown move to
Login, where the rest of the sign-in configuration now lives. "Wait Spinner"
moves to Visibility.
The empty-value guard travelled with the dropdown. Its value can be '' when
nothing is chosen, and writing that over the REQUIRED defaultAuthenticationMethod
string fails validation silently - which is why resolveDefaultAuthenticationMethod
falls back to the stored method. Left behind in the Layout save it would have
protected nothing.
Wait Spinner is a text field, so it carried the erase-on-save trap: the Layout
save read $('#spinnerName').val() || '', which is '' once the input is elsewhere.
Both new homes write only what is actually on screen.
One of my own tests was wrong rather than the code: it sliced the Layout handler
'up to the next handler', which swallowed the following handler whole and made
'Layout no longer writes X' fail on the pane that legitimately does write X. It
now slices a handler's own body, and a new check sweeps every field that has left
Layout in this series.
Thanks to xet7 !
- Support -> Visibility. All of it: the /support link, the "Support page enabled"
toggle AND the content editor that toggle controls (public flag, title, text,
its own Save). Moving only the two visible rows would have left the editor
behind in Layout, controlled by a checkbox on another page.
- Email domain name -> Email.
- Custom legal notice page URL -> Visibility.
The two text fields carried the same trap as the earlier moves, in a worse form.
The Layout save read them with
($('#mailDomainNamevalue').val() || '').trim()
Once the input is not in that pane, .val() is undefined, the fallback makes it
'', and pressing Save on Layout would have written an EMPTY string over the
stored domain name and legal notice URL - silently erasing both. Those reads and
their $set keys are removed from the Layout save, and their new homes write each
field only when its input is actually on screen.
Support needed no handler change: js-toggle-support saves on click and
js-support-save reads inputs that moved with it.
Tests: each item is in its new pane and gone from Layout, the whole Support
feature moved together, the Layout save no longer touches either text field, and
both new saves guard on the input existing.
Thanks to xet7 !
"Allow Email Change" moves to Email; "Allow Username Change" and "Allow users to
self delete their account" move to Login. All three were in the Accounts pane.
The helpers move with them. A radio is bound to {{#if allowEmailChange}}, and a
helper the HOST template does not have renders as false - the setting would show
as "No" whatever its stored value. They are one shared object now, registered on
Template.email and on Template.setting (which hosts the Login pane).
Saving is split the same way: Email's existing Save takes allowEmailChange, and
Login gets a Save for the other two. Both write only what they actually found on
screen - the same guard as the earlier moves, so a radio that is not rendered can
never be written as false.
That left the Accounts pane with nothing but a Save button, so the pane, its menu
entry, its state, its helper and its pane header are removed rather than left as
an empty page. The accountSettings SUBSCRIPTION stays: the settings still live in
that collection, only where they are shown changed.
Tests: each setting is in its new pane, each host pane has a Save that reaches it,
the empty pane and every reference to it are gone, the helpers are registered on
both host templates, the saves skip a radio they did not find, and the
subscription remains.
Thanks to xet7 !
The pane holds the whole sign-in configuration - default authentication method,
password login, self-registration, forgot-password - so "Registration" described
only part of it.
Uses the EXISTING "login" key ("Login"), as asked: every language that already
translates it is covered and there is no new string to translate. The pane id
stays registration-setting, so nothing inside the pane loses its translations.
That is the same rule the "Visibility" rename followed one commit ago, for the
opposite reason: no key meaning "Visibility" existed, so a new one had to be
added rather than editing tableVisibilityMode in place, which is translated in 141
languages as "Boards visibility".
Tests: both renames are pinned - the entries point at keys that exist in
en.i18n.json, and the pane ids are unchanged.
Thanks to xet7 !
"Don't show the board activities on all boards" was a BUTTON in the Layout pane
that called setAllBoardsHideActivities(), which bulk-set showActivities:false on
EVERY board document. That was wrong twice over: it overwrote each board's own
value for good, so it could never be undone, and it did nothing at all for boards
created afterwards.
It is now one global setting - Settings.hideBoardActivitiesOnAllBoards - with its
own pane, Admin Panel / Settings / Hide board activities on all boards, saved as
Yes/No like the other instance-wide switches. The activity feed reads it ONCE, in
_showActivities(), before any per-board or per-card value: when it is on, no board
shows activities; when it is off, every board's own setting applies again,
unharmed. Boards are never written to.
The server method is removed rather than left callable. It was unreachable from
the UI after this change and its only effect was the destructive write.
Also, per the follow-up: the pane previously labelled "Boards visibility" is now
just "Visibility". The label points at a NEW i18n key rather than changing the
value of tableVisibilityMode, because that key is already translated into 141
languages as "Boards visibility" - editing the English source in place would have
left every one of those translations silently saying the old thing. en.i18n.json
had no key meaning "Visibility", so one was added; the pane id and its own key are
untouched, so the pane's contents keep their translations.
Tests: tests/boardsVisibilitySettings.test.cjs now also covers the activities
move - its own pane exists, the Layout button and its handler are gone, the save
writes ONE global setting and never a board document, a missing radio is skipped
rather than saved as false, the schema field exists, and the read side consults
the global flag BEFORE any per-board value. Plus the pane label check follows the
rename.
Thanks to xet7 !
"Hide card counter list on All Boards" and "Hide board member list on All Boards"
were in the Layout pane, which is about logos, links and head tags. They are about
what All Boards SHOWS, which is what the Boards visibility pane is for - its i18n
key is tableVisibilityMode, but the label admins see is "Boards visibility". Both
settings now sit there, saved by that pane's Save button.
The move had a trap. The Layout save read them as
$('input[name=hideCardCounterList]:checked').val() === 'true'
Once the radios are no longer in the Layout pane, :checked matches nothing,
.val() is undefined, the comparison yields FALSE, and pressing Save on Layout
would silently turn BOTH settings off - a data change from a pane that no longer
shows them. So the reads and the two $set keys are removed from the Layout save,
not just the markup.
The new save guards the same class of mistake from the other side: it writes each
flag only when its radio was actually found, and sends no update at all when it
found neither. The two flags live in Settings while the pane's own
allowPrivateOnly lives in TableVisibilityModeSettings, so this is a second,
separate write.
The i18n keys are untouched - the strings only moved - so no translation is lost.
Tests: tests/boardsVisibilitySettings.test.cjs pins that the pane it targets is
really the one labelled "Boards visibility", that both settings are in it and
gone from Layout, that the Layout save no longer writes them (the trap), that the
new save is guarded against writing a value it did not find, and that the i18n
keys are unchanged. It fails on the pre-move code.
Thanks to xet7 !
The last of the seven. 2525 characters of menu markup became one
+leftMenu(menuItems); Attachments already tracked the open pane in activeSection,
so nothing had to be derived, and its single click handler is untouched - the
shared template puts js-attachments-menu on every entry alongside the shared
class.
One template addition: the Sandstorm entry is a proper noun, not a translated
string, so an item may now carry a literal `label` where the others carry a
`labelKey`. The Sandstorm-only condition survives as data, a null the builder
drops, rather than markup wrapped in `if isSandstorm`.
All seven Admin Panel pages now render the same menu from a data list. Across
them: 8393 characters of duplicated markup gone, 44 entries described as data,
and 19 near-identical click handlers collapsed to 7 - one per page.
Tests: a check that ALL seven render the shared menu and none keeps .side-menu
markup of its own - the design is only worth having if nothing is left outside it
- plus the Sandstorm entry and the literal-label fallback.
Remaining: People's seven pane tables still need converting to Table.md.
Thanks to xet7 !
Sixth page converted to docs/Design/Page/Left-Menu.md. 1067 characters of menu
markup became one +leftMenu(menuItems), and the seven near-identical
'click a.js-<pane>-menu' handlers became one 'click .js-left-menu-item'.
People tracked the open pane by toggling a DOM class, which is why it was left
until now: it needed an active id first. switchMenu already derived all seven
pane booleans from the clicked data-id, so the id was there - it just was not
kept. It is now this.activeMenuId, starting at 'org-setting', which is the pane
orgSetting already started true for, so the page opens exactly as before.
With the active row rendered from that state, the manual removeClass/addClass is
gone - it would have fought the next re-render - and the "already open" guard
compares ids instead of reading a DOM class. data-id is resolved from the anchor
rather than event.target, which may be the icon inside it.
The per-pane extras survive the collapse: switching to Organizations, Teams or
People still resets that pane to page 1 and refreshes its total.
Same styling: Locked users keeps the red lock it always had, through the coloured
icon wrapper the shared template supports for exactly this case.
Tests: the page renders the shared menu, keeps no .side-menu markup, builds its
entries through the shared helper, has none of the seven old handlers and exactly
one new one, still runs the three per-pane refreshes, holds the open pane in
state, and keeps the red lock.
Remaining for Left-Menu.md: Attachments. Remaining for Table.md: People's seven
pane tables.
Thanks to xet7 !
The three features that kept Admin Panel / People off this design are now part of
it, and they are ON by default - there is no enabling flag. A page that supplies a
filter or an action gets it rendered, and the total is shown whenever the page
knows one:
filters: buildFilters([{ id, labelKey, options: [{ value, labelKey }] }], current)
actions: buildActions([{ id, labelKey, icon, cls }])
total: <number> (+ optional totalLabelKey)
They are general - a Boards or Cards report wants a filter and a total as much as
People does - so they belong in the one template rather than in a per-page copy.
The controls row now reads: search, filters, actions, total, pagination.
A page identifies which control was used by its data attribute (data-filter,
data-action), so this adds no new handler pattern: the same one-handler-per-page
rule as the search and the pager.
The option matching `current` is selected as STRINGS, so a numeric filter value
still selects. The total sits with the controls, not in the table, because it
counts the whole result set rather than the page, and inherits its colour so it
stays readable on a dark theme.
Tests: the two new helpers (including junk input - a filter with no options
renders an empty select rather than crashing), that the four parts appear in
reading order between the search field and the pagination, that there is NO
opt-in flag, and that the doc says so.
One earlier guard needed fixing rather than the code: "the table page stylesheet
does not restate button colours" sliced the CSS by POSITION, so the new rules
landed inside the slice and tripped it. It now matches by selector, which is what
it always meant.
NOT done: People itself still renders its own markup. Its seven panes
(Organizations, Teams, People, Domains, Locked users, Roles, Shared templates)
are seven tables with their own columns and handlers, and converting them is a
larger piece of work than adding these features was. The blocker recorded in
Table.md is now gone, so that conversion is unblocked - the "Pages that do not
use this design" entry stays until it is actually done.
Thanks to xet7 !
A page with a paginated table that is not built from this design is a gap. Left
unwritten, the next person re-derives the answer by reading the code - or worse,
copies a few of this design's classes into it and leaves it half-converted, which
is exactly how the ten report pages drifted apart before.
People (Admin Panel / People) is the one such page. It predates this design and
has its own controls and table markup, one set per pane - Organizations, Teams,
People, Domains, Locked users, Roles, Shared templates - so it is several tables
on one page rather than one. It also carries four things this template has no
slot for: a filter dropdown (all / locked / active / inactive / admin), action
buttons ("Unlock all users", "Add / Remove Teams"), a result count beside the
controls, and a separate Search button where a table page searches on Enter.
The entry also records what People ALREADY shares, so the remaining work is not
overstated: it pages server-side with limit/skip exactly as this design requires,
and its prev/next buttons are themed by the shared pager stylesheet through the
.people-pagination class, so it already follows the per-user theme and the WeKan
default. What is missing is on this side - optional slots in the controls row for
a filter, extra actions and a total, rendered only when a page supplies them.
Those are general enough for a Boards or Cards report to use, so they belong in
the shared template rather than in a per-page copy.
Tests: the section must exist, must come before the pages that DO use the design,
must list People with a reason that actually explains, and - so the entry cannot
quietly go stale - People must still have none of this design's markup. If it
ever gains it, the test fails and the page moves to the other section.
Thanks to xet7 !
Four more pages converted to docs/Design/Page/Left-Menu.md. Their menus are data
now, not markup: 1956 + 724 + 189 + 184 characters of hand-written .side-menu
blocks became one +leftMenu(menuItems) each.
Same styling: all four kept the icon shape they had. Settings and Features pass
emoji:true, which renders the empty span.emoji-icon they always had before the
icon; Translation and Info render the bare i.fa they always had.
Settings needed one derivation. It tracks the open pane with eight separate
ReactiveVars rather than an active id, so activeSettingId() maps them to the id
the menu highlights - no behaviour change, and the menu still cannot highlight two
rows. Its Sandstorm exception survives as data: the e-mail entry is a null the
builder drops, instead of markup wrapped in `unless isSandstorm`.
Each page keeps its own single click handler, so their behaviour is untouched -
the shared template puts both js-left-menu-item and the page's own class on every
entry.
Tests: tests/leftMenu.test.cjs checks all four render the shared menu, keep no
.side-menu markup of their own, build through the shared helper and keep their
handler class; and that Settings still has its Sandstorm exception and maps every
one of its eight panes to an id (an unmapped pane would never highlight).
Remaining: People and Attachments. Both track the open pane by toggling a DOM
class rather than in state, so they need an active-id var first.
Thanks to xet7 !
First page converted to docs/Design/Page/Left-Menu.md. Its thirteen entries were
six lines of markup each plus, for twelve of them, an identical click handler.
They are now a data list:
{ id, icon, labelKey } and { separator: true }
built by buildMenuItems() and rendered by the one leftMenu template. 1895
characters of markup in adminReports.jade became a single +leftMenu(menuItems).
Same styling, deliberately: the shared template reproduces all three icon shapes
the Admin Panel pages already used, so a conversion changes no pixel - an empty
span.emoji-icon before the icon (Settings, Features), the icon inside a coloured
span.emoji-icon (People / Locked users), or a bare i.fa (Problems, People,
Translation, Info). Problems uses the bare shape it had.
The twelve 'click a.js-report-<name>' handlers, all of which called switchMenu,
are one 'click .js-left-menu-item'. switchMenu no longer toggles the active class
by hand either: the active row is rendered from activeReport, so the manual
removeClass/addClass would have fought the next re-render. Its "already open"
guard now compares ids instead of reading a DOM class, and it resolves data-id
from the anchor rather than event.target, which may be the icon inside it.
Three suites looked for the menu ids in adminReports.jade; the menu is DATA now,
so they read the .js. Same intent, right file.
Tests: tests/leftMenu.test.cjs gains the conversion checks - the page renders the
shared menu, keeps no .side-menu markup of its own, builds its entries through
the shared helper, has exactly one menu handler and no manual active-class
toggling, and the three icon shapes are reproduced.
Still to convert: Settings, People, Features, Attachments, Translation and Info.
Settings, Features and the two single-entry pages are the same mechanical swap.
People and Attachments additionally need an active-id reactive var, because they
track the open pane by toggling a DOM class rather than in state.
Thanks to xet7 !
docs/Design/Table-Page.md -> docs/Design/Page/Table.md, with every reference
updated: the three design docs that link to it (History, CPU-usage, Recovery),
the code comments in the shared template, stylesheet and helpers, and the four
test suites that read it. Its own link to History.md is re-based, since the file
is one level deeper now.
docs/Design/Page/Left-Menu.md is the second page design: the menu beside the
content on every Admin Panel page. It records what those seven menus share, which
pages use it, the entry shape, and how a page adds one.
Which side it is on is part of the design, not an accident of the markup: for a
left-to-right language the menu is on the LEFT with the content to its right; for
a right-to-left language the whole panel MIRRORS - the menu is on the right, the
content to its left, and inside each entry the icon and label mirror too. That
works only through the document direction plus logical CSS, so the doc says to
never write left/right/margin-left/padding-left for this menu.
Checking that turned up two places where the current CSS did exactly that:
- .side-menu had `box-shadow: inset -0.2vh ...`. An inset shadow offset on the X
axis is a PHYSICAL direction and does not mirror, so it shaded the wrong inner
edge once the menu moved to the right. The X offset is dropped.
- the entries used `padding: 1.3vh 0 1.3vh 1.3vw`, i.e. padding-LEFT, so under an
RTL language the indent stayed on the left - the outer edge of a right-hand
menu. Now padding-block + padding-inline-start.
Theme: the menu was entirely hard-coded greys. Most of it stays neutral on
purpose - it is chrome, and tinting the whole card would fight the content beside
it - but the entry you are ON now takes the per-user theme accent (Member
Settings -> Change color sets --theme-accent on :root), with `inherit` as the
fallback so the WeKan default look is byte-for-byte unchanged when no colour is
chosen. No brand colour is hard-coded in the menu.
The shared pieces are in place: client/components/settings/leftMenu.jade renders
the menu from an item list, and models/lib/leftMenu.js turns (items, activeId)
into it - marking exactly ONE entry active, dropping conditional holes, and
supporting group separators.
Tests: tests/leftMenu.test.cjs is the one suite for this design - the pure
helpers, the template, the mirroring, the theming, the shared narrow-window
stacking, and that every path in the doc's related-files table exists.
NOT done yet: the seven Admin Panel templates still render their own copy of the
menu markup. Converting them to +leftMenu is the next step; the design, the
template, the helpers and the tests it will be checked against are ready.
Thanks to xet7 !
tests/adminReportsPagination.test.cjs asserted against the same pages as
tests/tablePage.test.cjs from a second file - the same split this change removed
from the app code, and written when each report still had its own markup,
controls row and stylesheet. It is merged into tests/tablePage.test.cjs, which is
now the one suite for the design: the pure helpers, the template, the layout, the
themed pager, the server-side index-backed paging, and the doc.
Its last three checks cover the OTHER pagers (People/Org/Team/Domain, the board
Table view, Translation). Those are not table pages, but they share the themed
pager stylesheet the design lists, so a change there reaches them too - they are
kept, next to what they depend on.
Deduplicated on the way in: the merged "pagination controls use
var(--theme-accent)" was a weaker copy of the check above it, which already pins
all five button states; its two unique assertions were folded in and the copy
dropped. 10 + 22 checks -> 31, no coverage lost.
Two guards were pointed at the wrong file after the refactor:
- fileNameDisplay's "the invisible-character filter is fully removed" read only
adminReports.jade, which no longer holds ANY report markup - so it passed no
matter what. It now reads the shared template too.
- Table-Page.md's related-files table still listed the deleted test. The suite's
own "every path in this table exists" check caught it; the row now describes
the combined suite.
Thanks to xet7 !
Checking how the table page's buttons are themed turned up two problems.
First, a bug I introduced with the shared table page: tablePage.css restated the
pagination button colours itself, and only for the base state, :hover and
.disabled. WeKan already has ONE stylesheet for every prev/next pager in the app,
client/components/main/paginationControls.css, and it spells out :hover, :focus,
:active AND :active:hover deliberately - because the global button rules in
forms.css set those same states from --theme-accent with a BLACK / dark-grey
fallback, at equal or higher specificity:
button { background: var(--theme-accent, #000) }
button:focus { background: var(--theme-accent, #222) }
button:active { background: var(--theme-accent, #111) }
button:active:hover { background: #e6e6e6 }
A partial copy looks right until the button is CLICKED and then loses: pressing
"next" on a table page would have left a black button sitting there until it lost
focus - exactly the regression that stylesheet was written to prevent.
.table-page-pagination / .table-page-page-info are now listed in it, and
tablePage.css carries layout only.
Second, trimming adminReports.css in the previous commit removed the
.admin-report-controls layout, which Archived boards also used - so its search +
pagination row lost its flex layout. Archived boards now uses the shared controls
classes (its js- handlers are unchanged), which restores the layout and gives it
the same themed pager. .admin-report-pagination / .admin-event-pagination had no
users left afterwards and are gone from the pager stylesheet.
So a table page never invents a colour: the buttons and the "3 / 42" counter
follow the per-user theme (Member Settings -> Change color sets --theme-accent on
:root) and fall back to the WeKan default blue #01628c when no custom colour is
chosen, and the counter uses color: inherit so it stays readable on a dark theme.
Docs: Table-Page.md gains a Theme section saying exactly that, with the forms.css
specificity trap written down so the colours are not copied back into a page
stylesheet, and paginationControls.css + forms.css are added to the related-files
table.
Tests: the shared pager must cover the table page class in all five states with
the accent + WeKan-blue fallback; tablePage.css must not set background, color or
border on the pager; and the design doc must document the theming.
Thanks to xet7 !
A File Path / File Type / Description table of all sixteen files that make a
table page work: the shared template, stylesheet and pure helpers; the Admin
Panel wiring; the client import list (a file that is never imported is simply not
loaded, which is its own class of bug); the six report publications and their
count methods; the event-log model behind the Security / Speed / Tests / CPU
streams; and the two test suites.
The old two-column "Where the code is" section at the bottom listed a subset of
the same files and is removed rather than kept in parallel - a reference table
that exists twice is one that goes out of date once.
Tests: tablePage.test.cjs checks the table has those three columns, that every
path it lists exists on disk, that the shared implementation is among them, and
that no file is listed twice. A renamed or moved file now fails the suite instead
of leaving the page quietly pointing at nothing.
Thanks to xet7 !
Upgrading a Snap from 6.09 to 10.37 migrated successfully and then served 503
until the admin ran `snap restart wekan` by hand. WeKan sat in its startup loop
printing "MongoDB not ready yet, retrying in 5 seconds..." against a MongoDB the
migration had just shut down for good.
mongodb-control ends with `exec bash $SNAP/bin/migration-control`, so
migration-control IS the wekan.mongodb service process. The switch to FerretDB
ran, in this order:
snapctl start --enable <snap>.ferretdb
snapctl restart <snap>.ferretdb
snapctl stop --disable <snap>.mongodb <- stops the service THIS script is
snapctl restart <snap>.wekan running in: SIGTERM, dead here
so the restart that hands WeKan over to FerretDB never ran. The reporter's log
shows it exactly: "Migration succeeded. Switching to FerretDB (SQLite); MongoDB
will be shut down." at 13:15:12, systemd stopping snap.wekan.mongodb.service and
"[migration] Interrupted (snap refresh, stop or reboot)" one second later, then
minutes of wekan.wekan waiting for a MongoDB that was gone. The comment above
that block already noted the service can terminate us - the restart just needed
to be on the other side of it.
WeKan is now restarted onto FerretDB BEFORE MongoDB is stopped, and the stop is
the last command in the switch. The traps are disarmed just before it, so being
stopped there no longer logs "Interrupted (snap refresh, stop or reboot)" after a
migration that in fact SUCCEEDED, nor runs cleanup for a finished run.
The restart must not be the only way out of that loop either, since it is the
last act of a script being killed: wekan-control's MongoDB wait now re-reads the
live `database` setting each round and re-execs itself when it has become
ferretdb. A migration that finishes while WeKan waits therefore recovers on its
own within five seconds, with no admin action.
mongodb-control's equivalent switch ("a completed FerretDB migration exists")
already had the correct order; a test now pins that too.
The high FerretDB CPU right after migration is a separate matter and is expected:
WeKan creates its indexes on first start against the new database, and in this
report WeKan never reached FerretDB until the manual restart, so that work had
not even begun when the reporter looked.
Tests: tests/snapMigrationSwitchOrder.test.cjs pins the ordering, that no snapctl
command may follow the self-terminating stop, that the traps are disarmed first,
that the pre-switch verification still comes before any of it, and the
wekan-control self-recovery. It fails on the pre-fix scripts.
Thanks to S0QR2 and xet7 !
Fixes#6525,
Files, Rules, Boards, Cards, Impersonation, Recovery and the four event streams
(Security, Speed, Tests, CPU usage) were ten copies of the same page: the same
title + search + prev/next markup, the same currentPage/totalPages helper pair,
and the same click/keydown handlers, retyped with a different js- prefix each
time. They had drifted apart, and any layout fix had to be made ten times.
They now render through ONE template and differ only in a column list:
{ label | labelKey, value(doc), align, nowrap, cls, userId(doc), data(doc) }
- client/components/settings/tablePage.jade - title, optional status row,
controls, table. The row ORDER is defined here once.
- client/components/settings/tablePage.css - the layout.
- models/lib/tablePage.js - pure pageInfo() / buildRows() / buildHeader() /
columnWidthPercent(), unit-tested without a browser or a database.
adminReports.jade 349 -> 112 lines, its CSS 134 -> 53, ten templates -> four,
twelve page/total helpers -> none, twenty-four control handlers -> four.
Layout fixes, now made once and reaching every page:
- The table is width:100% with table-layout:fixed, so every column gets the SAME
percentage of the width and the table can never grow wider than the panel. With
the default auto layout one long id or file name widened the table past the
panel and pushed its right-hand columns outside the browser window.
- Cells wrap: overflow-wrap:anywhere breaks even an unbroken id, URL or file name
inside its column. Datetime columns opt out with nowrap.
- .table-page has min-width:0 / max-width:100% so it can shrink inside the flex
.main-body instead of setting a min-content floor; only the table's own wrapper
may scroll sideways, never the page.
- At <= 800px the side menu goes full width on top and the table sits BELOW it.
This deliberately overrides the older "always side by side, even on narrow
windows" rule, which on a phone left the table a few dozen pixels wide with its
right-hand columns unreachable. Above that width the menu keeps its place and
the table sits beside it.
- Rows top to bottom: title, status (the live CPU figure on the CPU usage page),
controls, table.
Paging still loads only the current page - the publications apply limit/skip -
and loadReport now takes that window from the SAME pageInfo() call that renders
"page X / N", so what is fetched and what is displayed cannot drift apart.
Docs: the shared design moves out of the History design doc into
docs/Design/Table-Page.md, which lists every page that uses it (table name, menu
path, description) per group. History.md, CPU-usage.md and Recovery.md now link
to it and keep only what is specific to them.
Tests: tests/tablePage.test.cjs (18) covers the pure helpers - including a page
that no longer exists clamping to a real one, and a short row never shifting the
columns - plus the layout rules the doc promises and the "one implementation"
guarantee. Four existing tests that pinned the old per-report markup were updated
to the new mechanism, same intent.
Thanks to xet7 !
`./pull-security-reports.sh` reported OK for every endpoint and then wrote empty
split files and blank counts:
Counts (open / closed):
CodeQuality/StandardFindings: / -
Dependabot/Vulnerabilities: / -
`gh api --paginate --slurp` returns ONE ARRAY PER PAGE, so a list endpoint arrives
as [[alert,...],[alert,...]]. Nothing flattened that, so `.[]` yielded PAGES, not
alerts, and every `select(.state == "open")` was applied to an array. jq failed,
its error went to /dev/null, and the `>` redirect left a 0-byte file - which is
not valid JSON, so every later step on it failed too and printed nothing. A
security report that quietly claims there is nothing to see is worse than one
that fails, so:
- fetch() now concatenates the pages into a single list, but only when EVERY
element is itself an array; endpoints returning one object (/repos/{o}/{r},
the SBOM, default-setup) are slurped to [ {...} ] and are left alone, because
their renders index .[0].
- split() writes through a temp file, keeps a valid empty ARRAY and the jq error
on failure, and warns in the summary instead of truncating the destination.
- the secret-scanning redaction validates the redacted copy before deleting the
file that still holds live secrets - it used to write nothing and delete the
source anyway - and now removes that file on the failure path as well.
- count() always prints a number, so the summary can no longer show a blank
column, and the closed column starts at "-" rather than an empty string.
The same shape also broke the newest-analysis lookup (`sort_by | last | .id`
over pages) and the codeql-databases dump; both come right with the flatten.
Verified offline with the fake-gh harness the README documents, replaying the
real fixtures from the failed run: code scanning 4 pages -> 392 alerts,
Dependabot 1 page -> 86, analyses 152 pages -> 15118, advisories -> 22, and the
splits land as 2 open code scanning / 386 closed and 2 open Dependabot / 83
closed, with no zero-byte file anywhere in the run.
Tests: tests/securityReportScript.test.cjs guards the flatten, the non-truncating
split, the redaction ordering and the count helper, and - when jq is installed -
runs the actual filters, including a check that select() on an array-of-pages
still fails, so the guard cannot quietly stop being what protects the split.
Thanks to xet7 !
Both are in test helpers, so neither is reachable by an attacker, but both are
genuinely wrong string handling and CodeQL rates the rule High.
Alert #428, tests/boardHeaderOneLine.test.cjs: the rule bodies were split with
`rule.split('{')` and the trailing brace removed with `body.replace('}', '')`,
which strips only the FIRST '}'. The block is now matched with a single regex
that captures selector and body as separate groups, so no brace ever ends up in
the text and there is nothing to strip. Verified the check still catches a
non-margin declaration in a button rule, and still ignores the h1's padding.
Alert #427, tests/testsAreRegistered.test.cjs: a file name was spliced into a
RegExp after escaping only dots (`stem.replace(/\./g, '\\.')`), leaving every
other metacharacter - the backslash above all - able to change the meaning of the
pattern. It now goes through an escapeRegExp() that escapes the full set
including the backslash itself.
Thanks to GitHub CodeQL (code scanning alerts #427 and #428) and xet7 !
brace-expansion 5.0.7 -> 5.0.8 (PR #6523) fixes CVE-2026-14257 / alert #119, High,
CVSS 7.5: expand() bounds the NUMBER of results but not their LENGTH, so chained
brace groups keep the count under the 100000 cap while every result grows one
character per group, and a ~7.5 KB input kills the Node process with a fatal,
uncatchable out-of-memory error. Unlike the postcss alert this one is a RUNTIME
dependency, reached transitively through minimatch.
postcss 8.5.15 -> 8.5.22 (PR #6522, already merged as 10af0bc2a) fixes
GHSA-r28c-9q8g-f849, High, CVSS 7.5: a path traversal in previous-source-map
auto-loading disclosed arbitrary .map files. Dev-only, via css-loader.
Both lock edits were checked against the npm registry (tarball integrity and
resolved URL match), and the brace-expansion one was reproduced locally with
`npm update brace-expansion --package-lock-only`, which produced a byte-identical
diff to the Dependabot PR. 5.0.8 also narrows engines.node to "20 || >=22"; WeKan
builds and ships on Node 24, so that is a no-op here.
elliptic (alert #55, CVE-2025-14505) stays as recorded in v10.14: no fixed version
exists upstream (latest is still 6.6.1, advisory patched version None). Noted here
that it is additionally unreachable - a dev-only polyfill under
@meteorjs/rspack -> node-stdlib-browser -> crypto-browserify, no WeKan client
module imports node crypto, and the built client bundle contains no elliptic,
secp256k1 or crypto-browserify code at all.
Thanks to xet7 !
On iPad landscape with a long board title, the controls were split across both
rows: the title kept the left group (edit, visibility, watch, star, sort) beside
it and only the right group (Filter / Search / view / dependencies /
multi-selection / hamburger) wrapped underneath.
That is what separate flex items do. The title, the left group, the centre group
and the right group were four children of the #header-main-bar flex row, so the
row filled with as many of them as fit and broke wherever it ran out - between the
left and the right group. The three button groups now live inside ONE wrapper,
.board-header-btns-group, so the row has just two items: the title and the
buttons. Either the buttons fit beside the title or the whole set moves down
together, under the title, which is what the report asked for.
A short title is unaffected: the wrapper's flex-basis is auto, so it measures as
its content width and only moves down when it genuinely does not fit - title and
buttons still share one line exactly as before. The wrapper keeps flex-wrap: wrap
so the groups can still break among themselves at widths where even the buttons
alone do not fit. The h1 gains min-width: 0 / max-width: 100% / overflow-wrap so a
title longer than the whole bar wraps inside the title instead of overflowing the
viewport (a flex item cannot shrink below min-content without min-width: 0).
The template change is a re-indent: every content line is unchanged, only its
indentation, plus the new wrapper and its comment.
exportHTML.js removed '#header-main-bar .board-header-btns' when exporting a board
to HTML; it now removes the wrapper as well, so the export is not left with an
empty div where the buttons were.
Tests: tests/boardHeaderOneLine.test.cjs gains checks that all three groups are
nested INSIDE the wrapper (by indentation, since sibling groups are exactly the
bug), that the title stays a sibling of the wrapper so the row can break between
them, that the wrapper's flex-basis stays auto (with `flex: 1 1 0` it would
measure as zero width, never move down, and the split would come back), that the
h1 can shrink and wrap, and that the export still strips the whole button area.
Thanks to xet7 !
On iPad landscape the board bar wrapped onto two rows: board title, edit,
visibility, watch, star and sort on the first, Filter / Search / view /
dependencies / multi-selection / hamburger on the second.
Measured from the report at a 1180 CSS px viewport, the two rows needed ~613px +
~691px = ~1304px on one line, about 124px more than the viewport. Nearly all of
that is per-button CHROME rather than text: every .board-header-btn carries 12px
side margins (24px), its icon another 10px per side (20px) and a 10px gap after
the label - roughly 54px of empty space around a ~60px icon+label. So nothing has
to be hidden at this width; halving the chrome between 801px and 1400px frees
~295px, which fits the bar on one line at 1180px with room to spare for languages
whose labels are longer than the Finnish ones. Only empty space shrinks - icon
and label sizes are untouched, so the buttons stay comfortable to tap.
Tablet PORTRAIT (iPad 820px) cannot fit ~1009px of icons+labels even halved, so
between 801px and 1000px the labels drop to icons only, the same treatment the
phone block already gives below 801px. Titles, tooltips and popups are unchanged,
so nothing becomes unreachable. Bounded at 1400px so wide desktops, which never
wrapped, look exactly as before; 1400px still covers iPad Pro 12.9" landscape
(1366px), and phones at 800px and below keep their existing 44px touch targets.
Tests: tests/boardHeaderOneLine.test.cjs guards the arithmetic, not just the
presence of the rules - it reads the base and override margins out of header.css
and asserts the halving frees more than the measured 124px deficit (with 2x slack
for longer translations), that button rules in the tablet block change only
margins so the #6419 touch sizing cannot be shrunk back, that the phone block is
untouched, that the overrides come after the base rules they override (a media
query adds no specificity, so source order decides), and that every control on
the bar is a .board-header-btn so the rules actually reach it.
Thanks to xet7 !
On iPad Safari the full-screen "Uncaught runtime errors: ERROR Script error."
panel appeared after login and again when the Safari Share sheet was opened on
All Boards to add WeKan to the home screen.
That panel is webpack-dev-server's error overlay, shipped by the rspack DEV
server (the stack frames are in /__rspack__/client-rspack.js, a path that only
exists when isDevEnvironment; a production build has no dev server and no overlay
at all). Its catchRuntimeError handler opens the overlay for every window 'error'
event, including ones that carry no information: a browser sanitises an error
thrown by a CROSS-ORIGIN script to the bare message "Script error." with a null
error object and no stack, and iOS Safari raises those from its own machinery and
from content blockers / extensions - which is why opening the Share sheet
triggered it.
Such an error cannot come from WeKan's own code: the bundle is served same-origin
(WeKan sets no CDN_URL), so a real WeKan error always reaches the overlay with
its actual message and stack, and WeKan registers no visibilitychange / pagehide
/ blur handlers that the Share sheet could run. There is nothing to act on in
"Script error.", so the overlay now ignores exactly that message and keeps
showing every other runtime error, plus all compile errors, as before.
devServer.client.overlay.runtimeErrors takes an (error) => boolean filter that
webpack-dev-server serialises with toString() and rebuilds in the browser with
new Function(), so the filter is self-contained.
Tests: tests/devOverlayRuntimeErrors.test.cjs round-trips the filter exactly the
way the dev server does (encodeURIComponent(fn.toString()) -> new Function),
checks real errors still open the overlay and malformed input never throws, that
devServer stays out of production/server configs, and - because the base config
puts devServer.client.webSocketURL there on a remote ROOT_URL - that the merge
deep-merges instead of dropping the WebSocket URL.
Thanks to xet7 !
The rows of changeAvatarPopup / adminChangeAvatarPopup rendered the delete link
and the file name INSIDE the a.js-select-avatar anchor. An <a> inside an <a> is
invalid HTML: the browser closes the outer anchor, so the file name and the
"Delete" link fell out of the row's flex layout and rendered as bold text
floating at the right edge, and a click on Delete also selected that avatar.
Delete and the file name were also only rendered for the avatar currently in
use, so no other upload could ever be removed, and an empty p.sub-name added a
stray block in the middle of the row.
Each row is now one flex line: thumbnail, file name (ellipsis-truncated, with the
full name as a tooltip), a green check when it is the avatar in use, and a delete
button that is a SIBLING of the select link - so deleting never also selects, and
every uploaded avatar can be deleted. The row in use is highlighted like the
other pop-over lists, the initials row shows its "Default avatar" sub-label under
the name, and the upload hints (max filesize / allowed filetypes / invalid file)
are grouped into one muted paragraph above the upload button.
Deleting the avatar that is in use left profile.avatarUrl pointing at a file that
no longer existed - a broken image everywhere - which is now much easier to hit
since any avatar can be deleted. Both popups reset the avatar to the initials
when the deleted file is the one in use. The admin popup also passed
userData= to userAvatarInitials, which reads this.userId, so its initials
rendered empty; it now passes userId.
Tests: tests/changeAvatarPopup.test.cjs source-guards the row structure (delete
never nested in the select anchor, never inside `if isSelected`), the reset to
initials and the row CSS.
Thanks to xet7 !
This is the actual cause of the failing "#5592/#5627 copying a board copies its
webhooks and rules" test (all three browsers) — surfaced now that the copy route
returns 500 + logs the stack instead of masking it as 200. The server log shows:
Error: update is not available on the server. Please use updateAsync() instead.
at ensureDefaultSwimlaneId (models/boards.js)
at getDefaultSwimline (models/boards.js)
at Swimlanes.copy (models/swimlanes.js:202)
swimlane.copy() (server, async) called the SYNC getDefaultSwimline() on the source
board to detect its default swimlane. When the board has no pickable swimlane that
getter self-heals via a synchronous Swimlanes.upsert(), which Meteor 3 rejects on
the server, aborting the whole board copy. It now calls the existing
getDefaultSwimlineAsync() (same pick + idempotent upsertAsync self-heal) and awaits
it, preserving the previous null-safety.
The same sync getDefaultSwimline() is still called from other server paths
(models/cards.js, server/models/lists.js, server/rulesHelper.js, swimlanes.js:365);
they only throw when a board has no usable swimlane and are not hit by the current
tests, so they are left for a separate, tested change.
Thanks to xet7 !
Renames rebuild-wekan.sh -> build.sh, rebuild-wekan.bat -> build.bat, and the
guard test tests/rebuildWekanDevServer.test.cjs -> tests/buildDevServer.test.cjs,
and updates every reference across the repo: the docs (Build-from-source, Windows,
Sandstorm, Raspberry Pi, virtual-appliance, Debugging, Developer-Documentation,
FerretDB, OpLog, Rclone, Emoji, Multiverse roadmap, Security remediation, Tests),
README.md, CONTRIBUTING.md, CLAUDE.md, package.json (test:unit:node), the release
scripts (release-all.sh, fix-changelog-hashes.sh, node-update.sh), the disabled
playwright workflow, playwright.config.js, the REST spec comment, tools/forge-mirror.js,
and the CHANGELOG. The menu and every option are unchanged; only the filename and
its references. The website has no references.
Thanks to xet7 !
The last WebKit test run left 8 core dumps in tests/playwright/ — all of WebKit's
WPEWebProcess renderer, one readable dump terminating with SIGTRAP (a deliberate
abort) from the Mesa llvmpipe software-GL stack on this ARM (Apple Silicon / Asahi)
host. A renderer that aborts mid-test makes the next click/navigation time out, so
these surfaced as false WebKit-only failures (05-admin-users, 12-checklists,
20-rules, 39-allboards-sort), not real WeKan bugs.
playwright.config.js now defaults WEBKIT_DISABLE_DMABUF_RENDERER=1 (unless already
set) — the standard fix for WPE WebKit aborting in headless / containerized / VM /
software-GL environments. Playwright passes process.env to the launched browser, so
this covers every run path; it is harmless for Chromium/Firefox, which ignore it.
.gitignore now ignores core dumps (core.<pid>) so a crashing test browser never
leaves untracked multi-MB files that could be committed by accident. The 8 existing
dumps are removed.
Thanks to xet7 !
The Playwright test "#5592/#5627 copying a board copies its webhooks and rules"
regressed (passed 2026-07-23, failed 2026-07-24 in all three browsers): the copy
returned HTTP 200 whose body was an object instead of the new board id string.
Cause of the MASKING: `POST /api/boards/:boardId/copy` did
`catch (error) { sendJsonResult(res, { data: error }) }`, and sendJsonResult
defaults the status to 200 when no `code` is given — so a copy that THREW was
reported as 200 with the error object as the body, looking like a success. The
catch now returns 500 with the message and logs the stack, so a failing copy is
a clean error (and diagnosable in the server log) instead of a wrong 200.
Also hardens board.copy() itself: the custom-field remap did
`card.customFields.map(...)`, which throws for a card whose customFields is
absent (the schema defaults it to [], but a card copied via `.direct` or seeded
raw can lack it), failing the whole copy. It now skips cards with no
customFields, matching the `!Array.isArray(this.customFields)` guard already used
elsewhere in the model.
The copy code and the card/swimlane/list models are unchanged in the regression
window, so the underlying throw comes from an infra change in that window; the
500 + server-side log above make the exact error visible on the next run.
Thanks to xet7 !
Appends item 11 recording that the Per-Swimlane Lists model was reverted to
board-wide shared lists and its migrations removed (#6521), and that data is
still shown without slow migrations via merge-per-swimlane-lists + repairBoardData.
Thanks to xet7 !
The per-swimlane-lists model was reverted (its migrations were removed in #6521);
lists are board-wide and the same lists appear in every swimlane. Update the docs
to say so:
* Features/Lists/Lists.md and Features/Board/Swimlanes.md now state plainly that
lists are shared across swimlanes (a card belongs to one list and one
swimlane), and that per-swimlane lists were an experiment that was reverted.
* The docs/Databases/Migrations/ writeups (MIGRATION_SYSTEM_IMPROVEMENTS,
MIGRATION_SYSTEM_REVIEW_COMPLETE, CODE_CHANGES_SUMMARY, SESSION_SUMMARY,
verify-migrations.sh) describe the old cron-driven migration system and the
per-swimlane-lists migration, both removed; each now carries an OBSOLETE banner
pointing at the current board-wide model and the live repair paths
(merge-per-swimlane-lists + repairBoardData).
The dated PerUserDataAudit2025-12-23 snapshot is left as-is: it already observed
that lists are board-wide, and it is a point-in-time record.
Thanks to xet7 !
New Setup menu action in both rebuild-wekan.sh and rebuild-wekan.bat that makes
the working copy current in one step: git fetch --all --prune, git pull --rebase
--autostash onto origin/<branch>, then repoint any CHANGELOG commit links the
rebase made stale, then show git status. It never commits; if the hash fix
changed CHANGELOG.md it says so and leaves it for review.
The commit-link repair that used to live inline in releases/release-all.sh is
extracted to releases/fix-changelog-hashes.sh so there is ONE implementation,
called by both release-all.sh (before a release) and the new Update-git option.
Behaviour is unchanged: only the unreleased section is touched, stale links are
repointed to the same-subject rewritten commit, unresolved links warn and never
abort, and it always exits 0.
The Windows .bat calls the shared bash script via Git Bash (bundled with Git for
Windows) and degrades gracefully with instructions when bash is not on PATH.
changelogCommitLinks.test.cjs now guards the shared script plus the fact that
both callers reuse it and release-all.sh keeps no duplicate copy.
Thanks to xet7 !
The v10.34 version bump rebased the post-release work, so the header follow-up
and the #6521 migration-removal bullets linked hashes that no longer exist on the
branch (33ca42a32 -> e28181734, 88a076561 -> 52d68be75). Matched by commit
subject and repointed. Only the not-yet-released Upcoming section is touched.
Thanks to xet7 !
The v10.34 release commit renamed the Upcoming section to v10.34 while the header
follow-up (display:contents) and the #6521 migration removal were committed just
after it. Their CHANGELOG entries had landed inside the now-released v10.34
section (and had rewritten v10.34's mobile-header bullet). Restore v10.34 to what
it shipped and put both post-release bug fixes under a new "Upcoming WeKan ®
release" section instead.
Thanks to xet7 !
#6521: after upgrading toward 10.33 a board grew a new "Restored Items" column
full of cards that looked empty but were not. That column, and the card moves
behind it, came from obsolete board migrations that fight the CURRENT data model:
* restoreLostCards - created a "Lost Cards" swimlane and a "Restored Items" list
(i18n lost-cards / lost-cards-list) and moved cards into them. It called a card
"orphaned" when its list was merely ARCHIVED (archived lists are excluded from
the set it checks) and "lost" when its swimlaneId was '' - which is NORMAL for a
board-wide shared card - so it dragged real, fine cards into "Restored Items".
* comprehensiveBoardMigration / fixMissingListsMigration - converted today's
board-wide SHARED lists (swimlaneId '') back into per-swimlane DUPLICATE
columns, i.e. the exact damage the startup schema step merge-per-swimlane-lists
now UNDOES.
* restoreAllArchived - un-archived every swimlane/list/card at once.
All four had NO callers left - their admin migration dashboard was already
removed - so they were dead code exposed only as admin-callable Meteor methods, a
footgun that could re-corrupt a board if invoked. They are removed, along with
their imports and the stale commented-out imports in 00checkStartup.js.
The legitimate paths remain and are correct: the board-open self-heal
(repairBoardData) assigns a genuinely missing swimlaneId / relinks orphaned cards
to the board's real first list/swimlane, and the startup schema step
merge-per-swimlane-lists merges any per-swimlane duplicate columns back into one
shared list while cards keep their swimlaneId. It still keys off the era's board
markers (fixMissingListsCompleted / comprehensiveMigrationCompleted) in existing
data, so removing the code that once wrote them changes nothing for already-migrated
boards.
Adds tests/obsoleteBoardMigrationsRemoved.test.cjs so these cannot come back.
Thanks to hmeunier95 and xet7 !
Fixes#6521,
Two follow-ups to the phone All Boards header.
The section icon still sat alone on row 1 with the Multi-Selection / Sort
buttons stranded on row 2. Those buttons and the search box are wrapped in a
`.path-right` element, so giving that wrapper `flex` only made IT wrap as a
two-line block below the icon. On a phone `.path-right` is now `display:
contents`, which dissolves the wrapper so its buttons and search field become
direct items of the header's flex row; the header then wraps them itself - the
section icon and buttons on row 1, the full-width search box on row 2.
The workspace NAME on the narrow left menu could spill over the "bars" workspace
menu button to its right, so the hamburger looked like it was drawn on top of the
name. The earlier min-width floor on the name caused it: in the narrow menu it
stopped the name shrinking, so its box overflowed onto the menu. The floor is
removed and the name's box (js-select-space) is clipped, so the name truncates
with an ellipsis and can never cover the menu; the menu button and count never
shrink.
Thanks to xet7 !
#6520: the Problems "Status" page showed "Board data-repair — 146/146 boards"
running forever (plus a matching "Migration or repair" login warning), and the
CPU area showed dozens of "new problems" on an idle server.
Board repair stuck at "running": getInProgress() trusted the raw `running` flag.
The startup repair DOES write running:false on completion, but its progress
callback also fired a NON-awaited running:true write when boardsDone ===
boardsTotal; being fire-and-forget, that write could land AFTER the awaited
completion write and pin the doc at "running, 146/146". A process killed
mid-repair leaves running:true too. Both now clear:
* the startup progress callback no longer writes the terminal boardsDone ===
boardsTotal update (the completion write owns the final state), closing the
race at the source;
* getInProgress() now asks the new pure isStatusActive() instead of reading
`running` directly - a doc is "in progress" only while running AND not in a
terminal phase (completed/error/done) AND not already finished by count
(done >= total) AND updated recently (a running flag with no recent progress
write is a crashed run). This also heals docs already stuck on an instance,
and fixes the same class of stale flag for the text migration. Because the
login "Migration or repair" warning keys off getInProgress(), it clears too.
CPU "57 new problems" on an idle server: the count in eventLogProblemAreas
counted every unacknowledged row in a stream. The CPU monitor writes one
'detected' row when a high-CPU period starts and several severity:'info' rows
('remediated' when it ends, 'rate-limited' for mitigation, FerretDB governor
chatter), so each brief, already-over spike looked like several "new problems".
The count now excludes severity:'info' rows (via the new newProblemsSelector) -
notices that a problem was handled or cleared are not problems. Rows with no
severity are still counted, so nothing unclassified is silently dropped.
Both decisions are pure, unit- and negative-tested (statusActive.test.cjs,
eventLogProblems.test.cjs), and registered in test:unit:node.
Thanks to Alishara and xet7 !
Fixes#6520,
`tx push -s` failed with `parse_error: Duplicate string key` because
en.i18n.json had two `cpu-cores` keys: the existing "CPU Cores" (already on
Transifex with human translations) and a second "cores" added by the CPU-usage
feature. A JS JSON parser silently keeps the last, so the app never noticed, but
Transifex rejects duplicates - and the collision also meant `cpu-cores` resolved
to "cores" everywhere.
The feature's string needs a different value ("N cores"), so it moves to a new
unique key `cpu-cores-suffix`; the pre-existing `cpu-cores` "CPU Cores" is left
untouched, matching every other language file, so no human translation is
disturbed. Only the one template that used it (Admin Panel / Problems / CPU
usage) is repointed.
Thanks to xet7 !
This developer-tooling change (registering five never-run mocha suites, two of
them *bleed security regression suites, plus the testsAreRegistered guard, and
deleting responsiveFixes.css and the empty backgrounds tombstones) was committed
after v10.33 but had no CHANGELOG entry. Every other post-v10.33 commit is
already covered, individually or as a consolidated fix series.
Thanks to xet7 !
On a phone the All Boards path header put the section icon alone on a wasted
first line while the Multi-Selection and Sort buttons sat on the next line. The
section icon and those buttons now share ONE row (path-left becomes flex 0 0
auto and stays on the buttons' row), and the Search box takes a full-width row
of its own beneath them (flex-basis 100% forces the wrap).
The blue Sort button showed as an empty blue square: its icon was the wrapped
`fa-sort-alpha-asc`. It now uses the plain `fa-sort` glyph as a direct `i.fa`
child, matching the Multi-Selection button beside it whose icon renders, so the
button always shows a sort icon.
On the narrow left menu each workspace name now keeps a small floor of width
(min-width, with the trailing menu button and count shrinking first) so at least
the first few characters stay visible and a workspace can be told apart while it
is dragged. An unnamed workspace still shows just its icon.
Thanks to xet7 !
HTML5 drag-and-drop never fires from touch, so the board-icon reorder (and the
other HTML5-DnD spots) only worked with a mouse. This adds
client/lib/dragDropTouch.js: a long press on a `draggable="true"` element starts
a synthetic drag that dispatches REAL, bubbling
dragstart/dragenter/dragover/dragleave/drop/dragend DOM events with a
dataTransfer shim - so every existing delegated handler works from a finger with
no change to the reorder logic, the workspace drag-to-share, or the card/rule
drags.
Chosen to be safe alongside the existing touch scrolling:
* LONG PRESS (250 ms) to start - a quick swipe on a draggable tile still
scrolls; only a deliberate hold-then-move begins a drag, and preventDefault
is called ONLY once a drag is under way.
* It fires a `mousedown` on the pressed element first, so the board reorder's
handle gate (which records the mousedown target) works from touch too.
* setDragImage is honoured, so the ghost is centred on the finger exactly as it
is on the cursor for a mouse.
* It excludes form fields and jQuery-UI sortables (lists/swimlanes/cards
already get touch via touch-punch), and coexists with dragscrollTouch.js,
which already skips the `.nodragscroll` board tiles and handle.
Loaded globally (via pageDragscroll / boardBody, and imported in boardsList).
Adds tests/dragDropTouch.test.cjs pinning the properties above.
This is Option A from the discussion - it keeps every mouse fix and every other
HTML5-DnD feature, rather than rewriting reorder onto jQuery-UI-sortable.
Thanks to xet7 !
You had to drag a board icon to the LEFT edge of the target for the gap to open
there. The reason: HTML5 dragover fires for whatever is under the CURSOR, but an
icon is grabbed off-centre (often at the move handle on the right), so the ghost
sat beside the cursor - when the ghost looked like it was over the target, the
cursor was actually over the neighbour, and the gap opened for the wrong icon.
The drag image is now centred on the cursor (setDragImage at the icon's centre),
so "ghost over the target" and "cursor over the target" line up. Combined with the
whole-icon insert-before from before, dropping the ghost onto a target icon now
opens the gap at that icon regardless of where on it you grabbed the dragged one.
Thanks to xet7 !
The dragged board icon stayed put in its slot during the drag, so the grid had
one extra tile and the live gap appeared one slot to the LEFT of where the board
would actually land - dropping "Eikun" onto "juuppa" showed the gap beside juuppa
instead of at it.
The dragged icon is now taken OUT of the grid flow while dragging
(`display: none`, added on a timeout after dragstart so the drag image is already
captured, removed on dragend). The other icons reflow as if it were gone, so the
gap sits exactly where the icon will land and "juuppa" moves aside to show the
drop slot.
The order computation already skips the dragged id, and the "is this the last
tile?" check now ignores the hidden (still-in-DOM) dragged tile, so reordering the
last board still works.
Thanks to xet7 !
The live gap used a left/right-half threshold on every board icon: the left half
inserted before, the right half after. So to land a board in a given slot you had
to aim the LEFT half of the icon occupying it, which was fiddly.
Now hovering anywhere on a board icon opens the gap AT that icon's slot (insert
before it), so dropping a board onto an icon puts it in that icon's place - drop
where it should stay, no half-aiming. The only exception is the LAST icon, whose
trailing half still inserts after it, so the end of the order remains reachable.
Thanks to xet7 !
The section icon left of the Multi-Selection button was a Unicode emoji
(⭐📋📂🗂️), which does not match the left menu, where Starred / Templates /
Remaining / Workspaces use Font Awesome glyphs (fa-star, fa-clipboard, fa-folder,
fa-folder-open). currentMenuPath now also returns a `faIcon` for the current
section, the header renders `i.fa` with it, and it is coloured #4d4d4d and sized
like the menu icons - so the header icon is the same glyph and colour as the
matching left-menu item.
Thanks to xet7 !
Reordering a board within a workspace (or any view) put it back where it started.
The `drop .js-board` handler only fires when the pointer is released over a BOARD
tile - but the gap the user aims at is the placeholder `<li>`, which is NOT a
`.js-board`, so releasing over it hit no drop handler and the optimistic move
reverted.
The drop now reads the intended order straight from the DOM using the gap's real
position (every board id in list order, with the dragged id taken from its old
slot and put where the placeholder sits), and there are `dragover`/`drop`
handlers on `.js-board-placeholder` so releasing over the gap itself works. Both
the tile-drop and gap-drop paths share one persist function, and it no-ops when
the visible order did not change.
This removes the earlier before/after target math (computeReorderedSortIndex) in
favour of the DOM position, which is exactly what the user sees, so the persisted
order always matches the gap.
The write itself was already permitted - the users allow rule accepts
`profile.*` and the schema field was added in the previous commit - so with the
drop actually firing, the reorder persists.
Thanks to xet7 !
Replaces the fixed "drop at the end" placeholder with the standard sortable feel:
while a board is dragged, an empty dashed gap opens up before or after the tile
under the cursor, showing exactly where the board will land - anywhere in the
current view (Starred / Templates / Remaining / a workspace), not only at the
end.
How it works:
* `dragover .js-board` computes which side of the tile the cursor is on
(inline-centre, RTL-aware) and inserts a placeholder `<li>` there. The
placeholder is a plain DOM node, inserted next to the Blaze-managed tiles and
removed on dragend, so it never fights Blaze's reactive list.
* `drop .js-board` reads that side and reorders with the pure
computeReorderedIds(..., after), which now inserts on the target's leading OR
trailing side and returns null for a no-op (including a drop back into the
board's own slot). Dropping past the last tile reaches the end, so the
separate end target is gone.
The placeholder is a real grid cell, so the surrounding tiles flow around the gap
as it moves. Unit tests cover the new before/after side and the own-slot no-ops.
Still mouse-only: HTML5 drag-and-drop does not fire from touch (the jQuery-UI-
sortable + touch-punch move noted before is what would add finger dragging).
Thanks to xet7 !
The header showed the current folder's icon AND its name ("Starred", "Remaining",
a workspace name) just left of the Multi-Selection / Sort / search controls. The
name was redundant - the folder icon already indicates the section, the left menu
highlights it, and the "My Boards" bar names the page - and it crowded (and on
narrow widths overlapped) those controls.
The `.path-text` is now visually hidden rather than removed, so a screen reader
still announces which folder is shown; the icon alone has no text alternative.
Thanks to xet7 !
Dropping one board onto another can only place it BEFORE that board, so the last
slot in the order was unreachable by drag. A dashed "drop here to move to the
end" tile now sits after the last board (only in the manual "custom" sort mode,
where drag-reorder applies) and accepts a drop that moves the dragged board to
the end.
The move-to-end order math is the pure computeReorderedSortIndexToEnd in
models/lib/boardSortReorder.js (a no-op when the board is already last); the
dragover/drop handlers mirror the board-tile ones and light the placeholder with
the same `.board-reorder-over` highlight.
Thanks to xet7 !
Dropping one board onto another to reorder threw INVALID [400]. setBoardSortIndexes
writes `profile.boardSortIndex` from the client via Users.updateAsync, and the
user `profile` object ENUMERATES its subfields in the schema (it is not blackbox)
- but `profile.boardSortIndex` had no schema entry, so SimpleSchema rejected the
update with a 400.
Added the entry next to the analogous `profile.autoWidthBoards` /
`profile.fixedListWidthBoards` (type Object, defaultValue {}, blackbox, optional).
The #6439 drag-reorder now persists instead of erroring.
Thanks to xet7 !
A finger tap on "+ Add workspace" often did nothing while the larger menu rows
(Starred, Remaining, a workspace name, the workspace menu button) worked fine. It
was a ~20px "+" link with `padding: 2px 8px` - well below the 44px minimum touch
target, so a finger usually landed just outside it. On a touch-capable layout it
is now a 44x44 target with the "+" centred. The click handler (opens the
add-workspace popup) is unchanged.
Thanks to xet7 !
With drag handles ON, dragging the handle did nothing (mouse or finger). The gate
that restricts the drag to the handle checked
`dragstart.target.closest('.board-handle')` - but in Chrome and Firefox the
dragstart event's `target` is the DRAGGABLE element itself (the whole
`li.js-board`), not the sub-element the pointer was on. So the closest() was
always null, the gate treated every handle drag as "not on the handle", and
cancelled it.
The press location is now recorded on `mousedown .js-board` (which does fire on
the handle), and dragstart reads that flag instead. The flag is reset on dragend
so a later drag that starts elsewhere is not wrongly allowed. Mouse drag from the
handle now reorders; a drag that starts on the rest of the tile is still
cancelled so that area stays free.
Touch is unchanged and still does not reorder: HTML5 drag-and-drop does not fire
from touch at all, which needs the separate jQuery-UI-sortable + touch-punch move
noted before.
Thanks to xet7 !
Dragging a board tile to reorder used the tile's HTML5 drag (draggable="true" +
the dragstart/dragover/drop handlers). Two things on the same tile were stealing
the mouse drag before that native drag could start:
* the board list <ul> is a `.dragscroll` element, so the mouse dragscroll
library pans it on mouse-drag - and the tiles were not `.nodragscroll`, so
grabbing a tile panned the list instead of starting the board drag;
* `a.js-open-board` is a link, and a link is draggable by default, so grabbing
the board title dragged the URL rather than the board.
`li.js-board` is now `.nodragscroll` (dragscroll leaves the tile alone) and the
inner link is `draggable="false"` (the tile's own drag starts instead; the link
still navigates on click). Star/unstar and "+ Add Board" are clicks, so they are
unaffected. Vertical scrolling of the list still works natively.
KNOWN, NOT fixed here: reordering by FINGER on a touchscreen. Board reorder uses
HTML5 drag-and-drop, which browsers do not fire from touch at all - so touch
needs a polyfill or a move to jQuery-UI-sortable + the touch-punch this app
already bundles (what lists/swimlanes use). That is a larger change and is called
out separately rather than half-done here.
Thanks to xet7 !
The board list had two FIXED-column layouts, and both stretched the tiles wider
as the window grew instead of fitting more per row:
* desktop: `float; width: 20%` - a fixed 5 columns (4 after margins);
* mobile-view: `grid-template-columns: repeat(2, minmax(0, 1fr))` - always 2.
That is why widening the window alternated "nice square tiles" and "few very
wide tiles" instead of steadily adding columns.
Both are now `repeat(auto-fill, minmax(..., 1fr))`, which fills each row with as
many tiles of a steady size as fit, so more width = more boards per row:
* desktop `minmax(200px, 1fr)` - ~3 columns at 1000px up to ~11 at 2500px;
* mobile-view `minmax(min(46%, 200px), 1fr)` - the `min(46%, ...)` keeps ~2
columns on a narrow phone board-column while a wider one (a laptop in mobile
mode) gets more, capped at a 200px tile.
The 8px grid `gap` replaces the per-tile 8px margins (now 0), and the float on
the list items is reset since grid places them.
Phones are unaffected: the `max-width: 800px` / device-iPhone media queries still
pin `repeat(2)` there, and on a phone `.board-list.mobile-view` (higher
specificity) resolves to 2 columns anyway.
Thanks to xet7 !
The zoom %, notification bell and user/avatar menu are the last items in the
quick-access bar. When the starred-boards list in the middle is shown it fills
the gap with `flex: 1` and pushes them to the end - but that list is
`display: none` on a phone, so with nothing filling the middle the group bunched
at the START (left in LTR) with empty bar to its right.
`margin-inline-start: auto` on the first item of the group (the zoom control)
pushes the whole group to the end. Being a LOGICAL margin it is the right edge in
LTR and the left edge in RTL automatically, which is the requested behaviour. An
auto margin an earlier small-width rule had put on the user bar is cleared, so
there is exactly ONE auto in the row - two would split the free space and
separate the group. The rule is last in the file, so it wins on source order.
Thanks to xet7 !
At wider (laptop) widths the board tiles merged - "Just" and "juuppa" ran
together into one blue block with no gap, and the tiles lost their proper width.
The equal-height/equal-width work done earlier for the phone had six rule groups
whose selector lists included a BARE `.board-list ...` variant alongside the
intended `.board-list.mobile-view ...` one, so they also applied on desktop where
`.mobile-view` is absent. Two of them broke the desktop float layout:
.board-list li.js-board { margin: 0 !important } /* killed the 8px gap */
.board-list li { padding-inline-end: 0 } /* and other geometry */
removing the spacing that `.board-list li { width: 20%; margin: 8px }` relies on,
so adjacent coloured tiles touched and read as one block.
All six groups are now `.board-list.mobile-view` only, so the desktop float
layout (untouched `width: 20%`, `margin: 8px`) is restored and the phone layout
is unchanged. Verified that no non-media, non-mobile-view rule sets
`margin: 0 !important`, `width: auto` or `height: 4rem` on a board tile.
Thanks to xet7 !
iPhone landscape is ~844px CSS-wide - above the 800px breakpoint but still an
iPhone, so the device-width media query (`max-device-width: 932px and
-webkit-min-device-pixel-ratio: 3`) applies while the plain `max-width: 800px`
rules do not. That split caused all three symptoms:
1. The left menu was `minmax(140px, 42%)`. 42% of 375px is 158px (fine in
portrait), but 42% of 844px is ~354px - a very wide column, and because each
menu item is `justify-content: space-between` with a `flex: 1` label, the
count chip was flung to the far edge, ~250px from its label. The column is now
`minmax(140px, min(42%, 210px))`: portrait is unchanged (158px is below the
cap), landscape is capped at 210px.
2 + 3. The count now sits right after its label (mobile only: `justify-content:
flex-start`, non-growing label, `gap`), so there is no large empty band even
at 210px, and the desktop 260px menu is left alone.
4. The folder header ("Remaining" + multi-selection buttons + search) stacked
onto rows only at `max-width: 800px`, so at 844px it stayed a single row and
the buttons overlapped the "Remaining" title. Its stacking media query now
carries the same device-width branch as the grid layout, so it stacks in
landscape too.
Thanks to xet7 !
Dragging the header bars scrolled the page but dragging the grey content area did
not. The header sits OUTSIDE #content, so the fact that it scrolls proves the
BODY is the real scroller. The previous commit had made #content its own
`overflow-y: auto` scroller - and in the content area that TRAPPED the touch:
#content caught the gesture and, having nothing of its own to scroll, did not
pass it on to the body, so a finger over the text did nothing while the same drag
over the header still worked.
#content is a pass-through again: `overflow: visible` so it does not catch the
touch, and `flex: 0 0 auto; min-height: auto` so it takes its content's full
natural height instead of being squeezed to the viewport by the default
`flex: 1`. The body's content is then taller than the body, so the body scrolls -
one scroller, reachable by a finger anywhere.
The body keeps `100dvh` (bottom tracks Safari's toolbar, not the large `100vh`),
`overflow-y: auto`, and `overscroll-behavior: contain` (no pull-to-refresh). Still
scoped with `body:has(.wrapper.global-search-wrapper)`, so only this page changes.
Thanks to xet7 !
Every earlier attempt treated the wrapper; the bottom stayed unreachable in both
orientations because of #content, not the wrapper.
#content is a flex child of the body flex-column, and a flex child defaults to
`min-height: auto` - it refuses to shrink below its content, so it grows to fit
and NEVER scrolls. Content past the fold just overflowed out of reach. `min-height:
0` is what lets it become a real scroller. That was the missing piece the whole
time.
The other half was the iOS toolbar: `body`/#content were `100vh`, which on iOS is
the LARGE viewport (toolbars hidden), so the scroller's bottom sat behind the
toolbar. `100dvh` - the dynamic viewport, which shrinks when the toolbar shows -
keeps the last line above it, in both portrait and landscape.
So on this page #content is the single scroller: `min-height: 0; overflow-y:
auto`, inside a `100dvh` body, with `overscroll-behavior: contain` to stop the
drag chaining out to the document (which fired pull-to-refresh in landscape). The
wrapper goes back to plain content so its full height feeds #content's scroll
range.
All of it is behind `body:has(.wrapper.global-search-wrapper)`, so it applies
only when the search page is shown and no other page's #content is changed. :has,
dvh and overscroll-behavior are all supported on the iOS Safari and Firefox
versions in question.
Thanks to xet7 !
Scrolling reaches the end now, but the last line still sat under Safari's bottom
toolbar. The page's scroller `#content` is sized `calc(100vh - 48px)`, and on iOS
`100vh` is the LARGE viewport (toolbar hidden), so the scroller's bottom edge is
behind the toolbar when it is shown - the final bullet ("By default archived
cards are not searched.") ends up under it with nothing able to scroll it clear.
The wrapper's bottom padding is raised from 24px to
`calc(120px + env(safe-area-inset-bottom, 0px))`. That empty scrollable space
after the content lets the last real line scroll up above the toolbar; the
safe-area inset covers the home indicator, and the fixed 120px covers the toolbar
itself, which the inset does not include. Empty trailing space is harmless - it
only extends the scroll range.
Thanks to xet7 !
The last fix un-clipped the page by making its wrapper its OWN scroll box
(`min-height: 100vh; overflow-y: auto`). That box is taller than its parent
`#content`, which is itself a scroller in mobile mode - so BOTH scrolled. On iOS
Safari, reaching the bottom of the inner box handed the scroll off to `#content`
and then rubber-banded back to "Differing operators", which is the reported jump.
Fairphone Firefox does not rubber-band, so it just reached the end - the same two
scrollers, only one of them visibly misbehaves.
The clip is now released WITHOUT adding a second scroller: `.wrapper` for this
page is `height: auto; overflow: visible`, so it grows to its real content height
and neither clips nor scrolls. `#content` (the page's existing scroller, and what
a finger scrolls natively on touch) is then the single scroller, and a single
scroller cannot fight itself - no jump, and the last line
("By default archived cards are not searched.") is reachable on both phones.
The override is `.wrapper.global-search-wrapper` (0,2,0), which beats the
boardsList `.wrapper` clip (0,1,0) regardless of stylesheet order.
The `.dragscroll` class is dropped from the wrapper: with `#content` scrolling
natively there is nothing for dragscrollTouch.js to do, and native touch
scrolling already works on a normal vertical page.
Thanks to xet7 !
The previous commit gave each panel its own `max-height: calc(100vh - 120px)`
scroll box. That did not work: the panels start BELOW the search form, so their
bottoms - and their scrollbars - ended up past the bottom of the wrapper, which
is clipped at `height: 100vh; overflow: hidden`. The result was text cut off
mid-character after "Notes" on iPhone, and the list ending at "Differing
operators ... red label." on Fairphone 4, with no way to scroll to the rest.
The page now has exactly ONE scroll container instead of nested ones. This page's
wrapper is tagged `global-search-wrapper` and, at phone widths, is
`height: auto; min-height: 100vh; overflow-y: auto` - at least a screen tall and
growing with its content - while the panels inside go back to plain content with
no height of their own. Nothing can be clipped between two scrollers because
there is only one, and 24px of bottom padding keeps the last line clear of the
browser's bottom bar.
`.dragscroll` moved to that wrapper and was REMOVED from the panels, which is
required rather than tidying: dragscrollTouch.js takes the NEAREST `.dragscroll`
ancestor and gives up if that one cannot scroll - it does not keep walking up. A
`.dragscroll` class left on a panel that no longer scrolls would therefore have
disabled finger dragging on the whole page.
Thanks to xet7 !
Three problems, one root cause each.
1. Label Colors ran off the right edge into the invisible area. The palette
already has `flex-wrap: wrap`; it could not help, because its container
`.global-search-page` is `width: 40%; min-width: 400px` - sized for a desktop
column - so on a 375px phone the block itself was already wider than the
screen and there was nothing to wrap into. At small width the page block is
simply as wide as the screen, and the wrappers with their own desktop minimums
are released too so they cannot re-create the overflow one level down.
2. The page could not be scrolled down AT ALL. `.wrapper` - the GLOBAL layout
element - is given `height: 100vh; overflow: hidden` by the All Boards
stylesheet at this width. That is fine for the boards page, which provides its
own scroll container, but it applies to every page, and this one had none, so
everything below the fold was unreachable. The help panel and the results list
now have a bounded height with `overflow-y: auto`.
(The deeper issue is that a page-specific `.wrapper` rule lives in
boardsList.css and affects every page at this width. Fixing that properly means
scoping it to the boards page; this commit does not, because every other page
currently depends on the behaviour one way or another.)
3. Dragscroll did not work with a finger. client/lib/dragscrollTouch.js scrolls
the nearest `.dragscroll` ancestor that can actually scroll - and no element on
this page had the class. The help panel and the results list now carry it, and
with (2) they are scrollable, so both conditions the handler needs are met.
The query form shares the `.global-search-page` class but is a short fixed
header, so it is explicitly excluded from becoming a scroll box of its own.
Thanks to xet7 !
Admin Panel / Version needed a horizontal scroll to read a value that easily fits
on screen: "WeKan Version" sat at the left edge and its version number about a
thousand pixels away.
The cause is deliberate, and applies to EVERY admin table:
.setting-content .content-body .main-body table { min-width: 1200px !important }
.setting-content .content-body .main-body table td { white-space: nowrap }
with the comment "Force tables to always trigger horizontal scrolling". That is
reasonable for the wide data tables, but a two-column table like Version is
pushed to 1200px for no reason, and nowrap cells can never use a second line.
At small width the table is now allowed to be as wide as the screen and no wider,
and cells may use as many lines as they need; long unbroken values (version
strings, paths, URLs) break instead of pushing the table wide again. The label
column keeps a 45% share so it does not collapse to one character per line beside
a long value. Horizontal scrolling still works where a table genuinely cannot
fit - it is simply no longer forced on tables that would fit comfortably.
The override is last in the file and repeats the same selectors, so it wins on
source order at equal specificity.
Thanks to xet7 !
Clicking "+" beside Workspaces called window.prompt(). A browser is free to
refuse that: iOS Safari offers "don't allow further prompts" for a page and then
suppresses every later one, so the button did nothing at all and no input field
ever appeared - which is exactly what was reported.
It now opens a normal WeKan popup with a text input and a submit button, the same
pattern every other create flow here uses (workspaceActionsPopup already has an
identical "add subworkspace" form). Submitting with an empty field keeps the
popup open and refocuses the input rather than closing silently, which is what a
cancelled prompt() used to look like.
Adds the addWorkspacePopup-title i18n key; the field label and button reuse the
existing allboards.add-workspace-prompt / allboards.add-workspace strings.
This was the only window.prompt() left in the client.
Thanks to xet7 !
The setting governed swimlanes, lists and cards on a board, but board TILES on
All Boards always showed their drag handle and were always draggable from
anywhere, so turning handles off did nothing there.
The handle markup is now behind the same helper as everywhere else, in both
places it appears (a normal board tile and a template-container tile).
The drag source follows it as well, which is the half that matters: with handles
ON the handle is the ONLY place a board drag may start, so the rest of the tile
stays free and a finger dragging across it scrolls the board list instead of
picking the board up - the same contract cards and lists follow. With handles OFF
there is no handle to grab, so the whole tile drags, exactly as before.
Boards use HTML5 drag-and-drop rather than jQuery sortable (the sortable code is
commented out in this file), so this could not be done by swapping a `handle`
option. The `li` keeps `draggable="true"` either way - a drag can only start from
a draggable element, and moving the attribute onto the handle would drag the
handle rather than the board - and `dragstart` instead cancels the drag unless it
began inside `.board-handle`.
With no handle rendered, the tile's title also reclaims the 28px that was
reserved for it.
Thanks to xet7 !
Forcing "Remaining" and the search onto one row was the wrong half of the fix: on
a 375px phone the title was ellipsised down to "R.." and the search box still had
barely any width, while a wide screen has room for both side by side.
They stack again - title first, search under it - but without what made stacking
look wrong before. The old two-row layout separated them with a tall empty band
because `.path-right` was free to grow; now each part takes exactly one
full-width row (`flex: 1 1 100%`) with a fixed 6px `row-gap`, so the search sits
directly under the title. The search still needs `min-width: 0` to share its row
with the multi-selection buttons: a flex item defaults to `min-width: auto` and
otherwise refuses to shrink below its content width.
Thanks to xet7 !
Two things made them differ, in opposite directions.
Width: the previous commit had "+ Add Board" span both grid columns, which was
the earlier request but not this one - identical tiles is what a wide screen does
and what was asked for. It is one cell again, like any board tile.
Margin: `.js-add-board` carries `margin: 8px !important` and `.js-board` carries
`margin: 8px`, both outside any media query. Zeroing only the add tile - which is
what the first attempt at this did - would have made IT the odd one out instead.
Both are now `margin: 0` at small width: the grid already puts an 8px gap between
cells, so a margin on top of that only shrinks the tiles, and unevenly if the two
do not match exactly.
Height was already 4rem for both; that is now also pinned on the tile INSIDE each
li (`width: 100%; height: 4rem`) so nothing within can change it, and the li
itself is left to the grid (`width: auto; min-width: 0; max-width: none`).
Result at 375px: every tile is one 96px x 64px cell, add and board alike.
Thanks to xet7 !
Four fixes, all so the small-width layout matches what a wide screen already
does.
1. Board titles broke ONE LETTER PER LINE. The drag handle is a single ~26px
absolutely-positioned circle, but space for it was reserved THREE times on the
way down: 32px on `li`, 30px in the tile's padding, and 30px again on
`.details`. On a ~96px tile that is 92px of reservation, leaving about nothing
- so every character wrapped. An absolutely-positioned handle only needs the
innermost text container to keep clear of it, so it is reserved once, on
`.details`, leaving ~52px of text: the title reads left to right again.
2. "+ Add Board" now spans both grid columns, so it is twice the width of a board
tile and reads as an action rather than as another board.
3. The header wrapped onto two rows on a phone - "Remaining" on one, the search
box on another, with a tall empty band between - while a wide screen puts them
side by side. The search box would not shrink, because a flex item's default
`min-width: auto` refuses to go below its content width; `min-width: 0` plus
`flex: 1 1 auto` lets it take what is left beside the title, and the row no
longer wraps.
4. The "Search boards" placeholder is removed. The magnifier beside the field
already says what it is, and the label filled the whole box on a phone. An
`aria-label` replaces it, which is what a placeholder should never have been
standing in for.
Thanks to xet7 !
Board tiles still towered over "+ Add Board" after both were set to 4rem, for a
reason that had nothing to do with either tile's height: the mobile board list is
a GRID with a fixed height (`height: calc(100vh - 120px)`) and no
`align-content`, so it defaulted to `stretch` and its single row was stretched to
fill the whole column. "+ Add Board" showed a 4rem grey `.label` sitting at the
top of a stretched cell, while a board's `li.js-board` carries the board colour
itself and therefore painted the entire stretched cell blue - so one looked short
and the other several times taller.
`align-content: start` keeps rows at their content height instead of dividing the
leftover space among them, and `align-items: start` / `align-self: start` stop
each tile stretching to its row. The list still scrolls: the fixed height plus
`overflow-y: auto` is what makes it a scroll container, and that is untouched.
Also rebalances the two columns on mobile, in both places that declare them: the
left menu goes from `minmax(84px, 30%)` to `minmax(140px, 42%)`. At 30% of a
375px phone the menu was ~112px, so "Workspaces" and the counts wrapped and it
read as cramped, while the board column had more width than two 4rem tiles need.
42% gives ~158px of menu and ~209px of boards, which still fits two tiles of
~97px side by side.
Thanks to xet7 !
The previous commit set both to 4rem, but only the add tile actually shrank: a
board tile stayed 8rem, so on the Remaining tab one board icon towered over
"+ Add Board" instead of matching it.
Two selectors decide that height and they are not equally specific:
.board-list.mobile-view .board-list-item (0,3,0) height: 8rem
.board-list .board-list-item (0,2,0) height: 4rem <- lost
`.mobile-view` is put on the <ul> by the template from Utils.isMiniScreen(), so
it is present on a phone; the add tile escaped only because it is matched by
`.board-list .js-add-board .label`, which is also (0,3,0) and came later in the
file. Hence one tile shrank and the other did not.
Both `.mobile-view` shapes are now spelled out, so the rule ties on specificity
and wins on order.
The 8rem rule is also OUTSIDE any media query, while the 4rem rule was inside
`@media (max-width: 800px)`. Utils.isMiniScreen() weighs mobile MODE and the
device as well as width, so `.mobile-view` can be set on a wide screen, where the
media query does not apply and the mismatch would have come straight back. The
override is therefore repeated at the end of the file, outside any media query,
matching how the rule it overrides is written.
Thanks to xet7 !
On a phone a board tile was 8rem (128px) while the grey "+ Add Board" /
"+ Add Template Container" tile had no mobile height at all: it fell back to the
desktop `min-height: 72px` plus 42px of padding and then grew further around its
wrapped label. So the two were never the same height, and both wasted vertical
space on a screen that has little of it.
Both are now a flat 4rem (64px) with `box-sizing: border-box`, so the number IS
the rendered height rather than a floor that padding is then added to. The board
tile's 24px/18px vertical padding is cut to 6px, which is what made it tall; the
add tile centres its label with flex, so it only needs enough padding not to
touch the edges.
One rule covers every tab of All Boards - Starred, Templates, Remaining and
Workspaces all render the same `.board-list` tiles, and the add tile is itself an
`a.board-list-item.label`, with `.is-template-container` for the Templates tab.
NOTE on the request: "+ Add board at 1/2 and a board icon at 1/4 of current"
cannot also make them equal, since they start at different heights (128px vs
~114px declared, more as rendered). Equal height is the part that is
unambiguous, so both are set to 4rem - exactly half the board tile's previous
height. Say the word if they should be shorter still (2rem = 32px fits one line
of title).
Thanks to xet7 !
The avatar dropped to a second line even with space left beside the bell, because
a width-based rule forced `flex-wrap: wrap !important` on the quick-access bar -
added deliberately, with the comment "so ~7 items fit in two wrapped rows". An
!important wrap beats any nowrap, so the earlier one-row work never took effect
at small width; and a wrapping flex row breaks BEFORE the last item rather than
shrinking anything, which is why the avatar went down while empty space stayed
behind on row one.
Every flex-wrap rule on that bar is now nowrap (verified by listing all eight),
and the items are made to fit rather than the row made to grow. `overflow:
visible` is kept, so a long translation or a custom logo spills instead of
disappearing.
The username/full name beside the avatar is also hidden at small width, as
reported. The template already hides it `unless isMiniScreen`, but that is a
JS/Session decision - Utils.isMiniScreen() also weighs mobile mode and the device
- so it can be true while the bar is narrow, and a full name is easily 100px+ of
a 375px bar. Same bare-text-node situation as the home link: font-size:0 on the
link collapses the name, and the avatar keeps its own size (with a font-size
restored on the avatar wrapper so initials avatars, which have no size of their
own, do not vanish with it). The name stays in the DOM for screen readers.
Measured budget for an iPhone 12 mini is now 328px of 375px.
Thanks to xet7 !
The label was still visible on iPhone and Fairphone 4. The rule that was supposed
to hide it (added in the one-row commit) carried no !important, and ELEVEN other
rules in header.css set a font-size on that same link - most of them !important,
including three scoped to the All Boards page itself via `body:not(.board-view)`
/ `.wrapper ~`, and one setting `16px !important; /* Much larger text */`. Every
one of them beat it, so the label kept showing on exactly the page it was
reported on.
The fix is a block at the END of header.css that uses !important and repeats each
competing selector shape (plain, `.wrapper ~`, `body:not(.board-view)`, and the
three `.iphone-device` variants), so where specificity ties, source order decides
in favour of hiding. Enumerating every font-size rule that touches
`.home-icon a` confirms this one is last: the competing !important rules end at
char 36958 and this one is at 47542.
Keyed on WIDTH (max-width: 800px), which is what was asked for - all smartphones,
small width. The viewport meta is `width=device-width`, so an iPhone 12 mini
reports 375px and a Fairphone 4 about 360px; both match. The separate
`body.mobile-mode` rule still covers the explicit phone/desktop toggle at any
width.
Also trims the notification bell, which sat in 36px of margin around a 28px icon:
10px on each side of the button (notifications.css) plus 0.5rem on each side of
its `#notifications` wrapper from the mobile blocks. More empty space than icon,
and on a 375px bar it is space the other buttons need. Both layers now give 2px a
side, which takes the measured one-row budget from 342px to 320px of 375px.
Thanks to xet7 !
The previous commit hid it on a narrow VIEWPORT (a media query) and on
`.iphone-device`. Mobile MODE is a different thing: `body.mobile-mode` is set by
Utils.applyMobileMode() from the phone/desktop toggle in this same bar, it is a
deliberate user choice, and it applies at any width - so on a wide screen in
mobile mode the label was still there. That is what was asked for: mobile mode,
not a viewport width.
`body.mobile-mode #header-quick-access .home-icon a` (1,2,2) beats the base
`#header-quick-access .home-icon a` (1,1,1), so no !important is needed for this
path; the `.iphone-device` path already has its own override, appended after the
two competing `font-size: 1em !important` rules so the later one wins.
The label is a bare text node inside the link, not a span, so it cannot be
selected on its own: font-size:0 on the link collapses it and the icon's own
font-size brings the icon back. The text stays in the DOM, so screen readers and
the accessibility tree still announce "All Boards".
Thanks to xet7 !
On an iPhone 12 mini (375px) the bar wrapped to two rows: home + logo +
mobile/desktop toggle on the first, drag-handle toggle + zoom + notifications +
user menu on the second. The mobile CSS chose that on purpose - the comment said
a nowrap row overflowed and `overflow: hidden` clipped the right-hand items - but
it treated the symptom. The row did not fit because of what was IN it:
* the home link kept its full "All Boards" label, the single widest item in the
bar and longer still in most languages ("Kaikki taulut");
* the logo was allowed 120px of a 375px bar;
* TWO items had `margin-inline-start: auto` (zoom and the user bar). An auto
margin absorbs all remaining space on its line, so the first one filled row 1
and pushed everything after it onto row 2 - that alone forced the wrap;
* items carried 8px gaps and, on the `.iphone-device` path, 0.5rem margins on
BOTH sides: ~80px of margins across five items.
The row now fits instead of wrapping: the home link is icon-only, the logo caps
at 84x20, there is exactly ONE auto margin (on the user bar, so it still sits at
the end when there is room), gaps are 6px and per-item margins 3px. Measured
against the declared sizes that is 342px of 375px, leaving ~33px of headroom.
The home LABEL is a bare text node, not a span, so it cannot be selected
directly: `font-size: 0` on the link collapses it and the icon's own font-size
brings the icon back. The text stays in the DOM, so screen readers still announce
it.
Both paths had to change together. `.iphone-device` is added by boardBody.js, so
it is present on a board page and ABSENT on All Boards (the screen in the report),
and its rules set font-size and per-item margins with !important - without the
matching override the bar would have stayed two rows on a board page and changed
height when navigating between the two screens.
Thanks to xet7 !
The dev-server option added in the previous commit stripped the scheme off the
answer and always appended the listen port, so "https://wekan.example.com" became
"http://wekan.example.com:4000". Behind a reverse proxy that is wrong twice over:
Caddy serves https://wekan.example.com on 443 and forwards to localhost:4000, so
the public URL has no port and is https, and nothing is listening on
wekan.example.com:4000 at all. Meteor builds absolute URLs from ROOT_URL, so
every e-mail link, OAuth redirect and attachment URL would have pointed there.
The listen port and ROOT_URL are now treated as the different things they are.
The port is appended ONLY when the dev server is browsed directly:
<empty> -> http://localhost:PORT (port appended)
wekan -> http://wekan.localhost:PORT (port appended)
https://wekan.example.com -> used EXACTLY as given (no port, https
kept, an explicit port kept if there is one)
wekan.example.com -> https://wekan.example.com (no port; a
dotted name is assumed to be proxied)
A trailing slash is stripped so built URLs do not double up, and the prompt now
says which answers are local and which are public. WEKAN_DEV_ROOT_URL is the
non-interactive form (WEKAN_DEV_HOST still works).
Verified by sourcing ask_dev_url for all eight cases, including the reported one:
port 4000 + https://wekan.example.com now yields exactly
ROOT_URL=https://wekan.example.com with Meteor listening on 4000.
Thanks to xet7 !
The Dev server menu could only run on localhost:3000, on the current IP, or on a
custom IP:PORT. There was no way to run on a different local port with a
different ROOT_URL host without editing the script.
The new "CUSTOM PORT + SUBDOMAIN" entry asks for both and uses them. ROOT_URL is
not cosmetic: Meteor builds absolute URLs from it (e-mail links, OAuth redirects,
attachment URLs), so a subdomain setup has to be told about it or those links
point back at localhost.
The host answer takes either form:
<empty> -> localhost
wekan -> wekan.localhost (a BARE label becomes a subdomain of
localhost; browsers and systemd-resolved resolve
*.localhost to 127.0.0.1 with no /etc/hosts entry)
wekan.example.com -> used AS-IS, with a note that it must resolve here
A pasted URL is reduced to its host (scheme, path and any port stripped), a
non-numeric or out-of-range port falls back to 3000 with a message, the chosen
port is freed first with kill_meteor_on_port like the other dev options, and
WEKAN_DEV_PORT / WEKAN_DEV_HOST skip the matching prompt so the option can be
scripted.
Verified by sourcing ask_dev_url against fake input for all seven cases above.
Adds tests/rebuildWekanDevServer.test.cjs as a source guard for this and for the
inotify watch-limit check added earlier in the same script - that it runs before
the menu, never exits, is overridable, and no-ops on macOS/BSD.
Thanks to xet7 !
"Show desktop drag handles" did nothing on a touch screen. The rule was
isTouchScreenOrShowDesktopDragHandles() = isTouchScreen() || preference
so on touch the OR was already true and the toggle could never hide the handles.
Every place that decides whether to render a handle - minicard, list header,
swimlane header - and every sortable handle selector goes through that one
helper, so the setting was inert on exactly the devices that show handles.
The setting is now THREE states, not two: on, off, and never-chosen. An explicit
choice always wins (including OFF on a touch screen); only when the user has
never chosen does the device decide, and then a touch screen still gets handles
by default, because a finger needs something to grab. The rule lives in the pure
models/lib/dragHandles.js so it can be unit-tested, and the toggle now stores a
real `false` instead of removing the setting - that is what lets "turned off" be
told apart from "never chosen". toggleDesktopDragHandles takes the explicit new
state from the client (which alone knows whether this is a touch device) and
still accepts no argument for older clients.
Handles also decide what a DRAG MEANS, and that half was broken too: `.minicard`
and `.list-header` carried `nodragscroll` unconditionally, so with handles ON a
finger dragging across a card neither moved the card (only the handle does) nor
panned the board (dragscroll was opted out) - it did nothing. They now opt out
only when handles are OFF, i.e. only when the element IS the drag source. With
handles on, the card body pans the board, which is the whole point of having
handles.
And the handle has to be reachable with a finger: it was a 20-28px icon in the
bottom-right corner, a mouse-sized target that is close to unusable on a
wall-mounted infoscreen. On a coarse pointer it becomes a 48px full-height strip
down the leading edge (the Material minimum, and the easiest edge to thumb), with
the card content padded to match. A mouse keeps the compact corner handle, since
`pointer: coarse` does not match a mouse.
Tab order: the keyboard card/list move buttons are focusable but `opacity: 0` and
sit at the START of the card content, so tabbing went card (visible focus) ->
invisible -> invisible -> next card and the focus ring kept vanishing and
reappearing where it looked like it had gone backwards. They are now revealed
while focused, the same pattern the skip-to-content link already uses.
Adds tests/dragHandles.test.cjs: the three states, that an explicit OFF hides
handles on touch (the reported bug), that an explicit choice always beats the
device default, and that a corrupt stored value falls back to the device default
rather than leaving a finger unable to drag.
Thanks to xet7 !
Meteor's file watcher takes ONE inotify watch per DIRECTORY, and the limit
(fs.inotify.max_user_watches) is per USER, shared with every other watcher that
user runs - an editor is usually the other big consumer. On a stock kernel it is
8192 or 65536, which a WeKan checkout can reach on its own. When it runs out,
Meteor fails with a message that blames the disk and sends people looking in the
wrong place:
Failed to start watcher for <repo>: [Error: inotify_add_watch on '<path>'
failed: No space left on device]
ENOSPC from inotify_add_watch means the WATCH LIMIT is exhausted, not that the
disk is full.
ensure_inotify_watches() now runs on every invocation, before the menu. If the
limit is below 524288 (the value VS Code documents for the same problem) it
raises it with sysctl for this boot and persists it to
/etc/sysctl.d/60-wekan-inotify.conf so the next boot does not go back to failing
builds. It also raises fs.inotify.max_user_instances from the low stock 128 to
1024, since each watcher process needs an instance and editors + Meteor +
chokidar add up. Each watch costs ~1 KB of kernel memory only while in use, so a
high ceiling is a limit, not a reservation.
It never aborts the script and never fails a build:
* already high enough -> silent no-op, the conf file is not touched
* root, or passwordless sudo -> applied without prompting
* sudo with a TTY -> prompts once
* no root and no usable sudo -> prints the exact two commands to run by hand
* WEKAN_INOTIFY_WATCHES=0 -> skipped entirely (any value overrides 524288)
* macOS/BSD -> returns immediately, there is no inotify there
Verified against a fake /proc + fake sysctl/sudo for all six paths above.
Thanks to xet7 !
`meteor` failed with
Failed to start watcher for /home/user/repos/wekan: [Error: inotify_add_watch
on '.../.tools/node-v24.18.0-linux-arm64/include/node/openssl/archs/
BSD-x86_64/asm_avx2' failed: No space left on device]
ENOSPC from inotify_add_watch means the per-user inotify WATCH LIMIT is
exhausted, not that the disk is full - the disk is 64% used with 157 GB free.
Meteor's watcher takes one inotify watch per DIRECTORY, and this repo had 41,040
of them against a fs.inotify.max_user_watches of 65536 that is shared with every
other watcher the same user runs (editors included). Two trees that are not app
code accounted for 72% of that:
.tools/ 20,535 dirs, 4.1 GB - a full Node 24 install (headers for every
openssl arch), a Go toolchain with its module/build caches, build
logs and repro dirs
FerretDB/ 9,148 dirs, 3.4 GB - the FerretDB v1 fork checkout, a complete Go
project plus its docs
Both are already in .gitignore, but the watcher only honours .meteorignore, so
Meteor kept walking and watching them. Nothing in WeKan imports from either (the
FerretDB binary is downloaded from its GitHub releases at build time), so there
is no reason to watch or scan them.
Excluding both takes the watched directory count from 41,040 to 11,213, which
also leaves headroom for the editor's own watches.
Thanks to xet7 !
cpu-exec exists so that a binary needing an instruction-set feature the CPU does
not have (AVX masked by a hypervisor - QEMU/KVM/Proxmox, the reported #6458
environment - an old CPU, or ARMv8.0 on a Raspberry Pi) runs through bundled
qemu-user instead of dying instantly with SIGILL. With no features declared it is
a plain exec, so it is safe and free to route EVERY binary through it - which is
why the design is "route everything".
Two platforms were not doing that:
* Sandstorm SHIPPED cpu-exec and qemu-x86_64 (sandstorm-src/build-deps.sh) but
the grain launcher spawned all eight bundled binaries directly - ferretdb,
mongod 3.0 (twice), niscud, the legacy mongo CLI (twice) and node for the
bridge and the importer. So the safety net was in the package and unreachable,
on the platform with the LEAST control over its hardware: a grain runs on
whatever CPU the Sandstorm host has.
* The snap routed mongod (mongodb-control, migration-control) but not FerretDB
(ferretdb-control, both the external-DB and SQLite launches) and not node
(wekan-control: the main application start and both maintenance-page starts).
Both now route through cpu-exec, each with a direct-exec fallback so an older
deps image or snap revision still works. On Sandstorm the guard also requires
/bin/bash, since cpu-exec is a bash script; without it the binary runs directly
exactly as before. The snap's main start keeps its `ulimit -s 65500` - the limit
is set before the exec and inherited across it (verified by expanding the line).
Docker (releases/ferretdb/wekan-entrypoint.sh) and the bundle launcher
(releases/ferretdb/start-wekan.sh) already routed ferretdb and node, and were
checked for other unrouted launches - there are none.
tests/cpuExecWiring.test.cjs previously asserted only that the Sandstorm build
SHIPS cpu-exec, which is exactly how the gap survived: it now asserts that the
grain launcher routes each of the six bundled binaries, that no bundled binary is
spawned directly any more (/bin/sleep is a grain utility, not bundled, so it is
exempt), and that the snap routes FerretDB and node with their fallbacks intact.
Thanks to xet7 !
Five mocha suites sat in the tree looking like they were being run, and were not:
`meteor.testModule` points at client/lib/tests/index.js and
server/lib/tests/index.js, those indexes list their suites with explicit imports,
and these five were never added. server/lib/tests had 49 suite files but 48
imports.
Two of them are *bleed security regression suites - checklistbleed (cross-board
checklist/checklist-item move denial) and proxybleed (header-login trusted-source
and request-IP handling) - exactly the kind of test whose silent absence lets a
fixed vulnerability come back unnoticed. The other three are filenameTruncation,
alwaysShowCodeAsText and renderLinksPlainText.
All five are now imported by their index. Every symbol they import was checked to
still exist first: denyCrossBoardMoveByCard / denyCrossBoardMoveByChecklistItem
(server/lib/utils.js), getRequestIp / isTrustedHeaderLoginSource /
findOrCreateHeaderLoginUser (server/lib/headerLoginAuth.js),
truncateFilenameToBytes / sanitizeFilename (models/lib/filenameSanitizer.js),
getSecureDOMPurifyConfig / sanitizeHTML (imports/lib/secureDOMPurify.js) and the
Markdown export of the wekan-markdown package. They have never run in this state,
so they may still fail on their assertions - that is the point of running them.
tests/testsAreRegistered.test.cjs is added as a guard: it fails if any
*.tests.js file in either directory is not imported by its index, and names the
two *bleed suites explicitly so a future tidy-up cannot drop them again quietly.
Also deletes files that nothing loads:
- client/components/main/responsiveFixes.css (162 lines, imported by nothing, so
never in the bundle - package.json sets meteor.mainModule, which disables
Meteor's eager loading).
- models/backgrounds.js, models/backgrounds.server.js and
server/permissions/backgrounds.js - three empty tombstones whose only content
was a comment saying board backgrounds became board-level Attachments and the
file is "intentionally empty and no longer imported". The live paths
(server/boardBackgrounds.js, server/publications/backgrounds.js) are different
files and are untouched.
Thanks to xet7 !
The section had grown two 'and fixes the following bugs:' headers and both a
'developer-tooling fixes' and a 'developer-tooling addition' header, because each
new entry was added with its own heading. The subsection headers are meant to
read as ONE flowing sentence with each verb appearing once, so the nine bullets
are now grouped under: adds new features, fixes bugs, removes dead code, has
developer-tooling changes. No bullet was changed and all nine commit links are
still present.
Thanks to xet7 !
Every CHANGELOG bullet links the commit it describes, and those links are written
BEFORE the release. Anything that rewrites history in between - a rebase onto an
upstream change, an amend, a squash - changes the hashes, so every link in the
not-yet-released section points at a commit that no longer exists and 404s once
pushed. That just happened to all eight links of the current Upcoming section.
release-all.sh now checks them as its first local step, before the Upcoming
heading is renamed and before the release commit is made, so the repair is part
of that commit:
- a hash that is still an ancestor of HEAD is left alone;
- a stale one is resolved by reading the OLD commit's subject (the pre-rewrite
object is still in the clone, reachable from the reflog) and finding the commit
on this branch with exactly that subject - the rewritten copy of the same
commit - then repointing the link to it;
- the substitution is bounded to the section being released, so the same hash
quoted in an older, already-pushed entry is never touched;
- it works whether or not the "# Upcoming" heading has already been renamed,
falling back to the newest release heading;
- anything it cannot resolve is reported as a WARNING and left as-is. A broken
doc link is never a reason to abort a release, so the repair never exits
non-zero.
Verified by running the function against fixture CHANGELOGs in this repo, using
the real pre-rebase hashes: two stale links were remapped to their rewritten
commits, an already-correct link was left alone, an unknown hash was reported and
kept, the identical stale hash in an already-released section was NOT rewritten,
and the already-renamed-heading path was exercised too. Adds
tests/changelogCommitLinks.test.cjs as a source guard for those properties.
Thanks to xet7 !
The eight Upcoming entries still linked the pre-rebase commits, so every link
would have 404ed once pushed. Each hash was remapped by matching the commit
subject against the commits now on this branch.
Thanks to xet7 !
This app runs with the audit-argument-checks package, so any Meteor method that
RECEIVES an argument it never check()s throws
"Did not check() all arguments during call to '<method>'" - the call fails
entirely, no matter what the method would have done.
problemDetailReport(area) had that defect but nothing had ever passed it an
argument, so it went unnoticed until the new Admin Panel / Problems / CPU usage
header started polling problemDetailReport('cpu') every 5 seconds and the server
log filled with the exception.
Auditing every server method for the same defect found five more that ARE called
with arguments from the client, so these features were failing outright:
- unlockUser(userId) - Admin Panel / People, unlocking a locked-out user
- runBackup(opts, storageName) - Admin Panel / Attachments, running a backup
- restoreBackup(zipPath, mode) - restoring a backup
- saveBackupSchedule(schedule) - saving the backup schedule
- migrateTextDatabase(direction) - the MongoDB <-> FerretDB text migration
and one with no current client caller, getServiceConfiguration(service), fixed
for the same reason.
Each now check()s its arguments against the types its call sites actually pass
(the two optional ones use Match.OneOf(String, null, undefined)), and the three
files that had no check import got one.
Thanks to xet7 !
Nothing scheduled it and nothing rendered it, but every logged-in client still
paid for it:
- initializeCronJobs() (server/cronMigrationManager.js) was NEVER called, so the
SyncedCron.add() registrations and the 5s job-queue processor never started.
- boardMigrationDetector.start() sat behind a commented-out Meteor.startup hook,
with the note "Automatic migration detector is disabled - migrations only run
when opening boards".
- The Admin Panel had no Cron page at all: no route in config/router.js, no
button in settingHeader.jade, no template ever included, and every helper,
event and reactive var for it commented out in settingBody.js.
- Yet imports/cronMigrationClient.js WAS imported by client/imports.js, so every
client subscribed to three publications and polled cron.getMigrationProgress
every 10 seconds, forever, for a feature with no user interface.
Migrations already run - and are already reported - through the paths that work:
Admin Panel -> Attachments (database migration) and the on-board-open repair,
both driven by the shared migrationProgress overlay dashboard mounted app-wide in
defaultLayout, plus the in-progress list on Admin Panel -> Problems -> Summary.
Removed: cronSettings.jade/.css, imports/cronMigrationClient.js,
models/cronJobStatus.js, server/cronMigrationManager.js (28 admin-gated cron.*
methods that no UI called), server/cronJobStorage.js,
server/boardMigrationDetector.js and the three publications that fed only the
deleted client module (cronJobs, cronMigrationStatus, migrationProgress).
KEPT on purpose: server/cron/syncedCron.js, which is SyncedCron itself and is
used by the backup schedule (server/methods/backup.js) and scheduled rules
(server/scheduledRules.js).
getInProgress() in server/lib/systemStatus.js no longer reads cronJobStatus.
Leaving that check would have been worse than useless: a leftover
status:'running' doc from an older version now has nothing to clear it, so
Admin Panel -> Problems would report "Migration job X running" forever.
The 40 i18n keys that only the deleted template used are left in place - dropping
them from every language file would discard human translations for keys that may
be reused.
Thanks to xet7 !
After importing a Trello board and choosing to map users later, "Map to existing
user" listed only the admin: the picker offered nothing but the ACTIVE REAL
MEMBERS of the board, and right after an import the real people have no
membership at all - the placeholders do. There was no search box either, so on a
board whose only real member is the importing admin there was literally nobody to
pick.
The picker now has a search box that goes through the same permission-checked
`searchUsers` method the normal add-member typeahead uses, so the same board
membership check and the same #6116 same-org/team restriction apply. With the box
empty it still lists the board's real members (the common case, which changes no
roles at all); typing searches every real user and labels the ones who are not on
this board yet.
Mapping onto a user who is not a board member adds them to the board with the
PLACEHOLDER's OWN role - the role the import recorded for that person - never a
higher one, and only after passing exactly the checks inviting them would: the
Admin Panel "roles allowed to invite" setting, the same-org/team restriction, and
the refusal to add a deactivated account. Adding a member with a chosen role is
something the board admin doing the mapping can already do through the normal
add-member flow, so this grants no capability the caller did not have; an
existing active member is still left completely untouched, entry and role.
Also fixes sanitizeUserForSearch dropping `profile` from every search result: it
read the Mongo-style paths in its allowlist ('profile.fullname') as FLAT keys, so
the lookup was always undefined and both this picker and the add-member typeahead
showed a blank name with only the username in brackets. Dotted paths are now
copied into the same nested shape, still allowlisting exactly the listed leaves.
Adds positive and negative unit tests for the new planner contract, including
that a comment-only placeholder can never yield an admin, that reactivating an
inactive membership does not duplicate the entry, and that the invite policy runs
before any write.
Thanks to AmigaAbattoir and xet7 !
Fixes#6519,
The page listed only PAST high-CPU periods (the event rows written by the CPU
monitor), so it could not answer "what is the CPU doing right now?" at all - the
one question an admin opens that page to ask.
A live line now sits between the page title and the search box: the current
system CPU percentage, the core count, the 1/5/15 minute load average and the
coarse "what WeKan is doing" label, refreshed every 5 seconds and outlined in red
while the monitor considers the CPU sustainedly high.
The figure comes from getCurrentCpu() in the CPU monitor, which reads the same
sample the monitor writes its event rows from, so the header and the rows below
it can never disagree. It reads module state only - no sampling of its own - so
polling it is cheap. When the background monitor is disabled
(WEKAN_CPU_MONITOR=false) it would otherwise always read 0%, so in that case the
percentage is measured between calls using a SEPARATE baseline, which cannot
disturb the monitor's own delta, and `monitored: false` is reported alongside.
Thanks to xet7 !
The Summary page reported "Broken cards N" and told the admin to "open the board
to auto-repair, or run the repair migration", but there was no button anywhere to
run one - and worse, no repair in the app could actually clear that count.
countBrokenCards() counts every card missing a boardId OR a swimlaneId OR a
listId. repairAllBoards() walks only NON-ARCHIVED boards and only ever sets
swimlaneId, so three kinds of counted card could never be repaired by anything:
cards on an archived board, cards with a missing listId, and cards with no
boardId at all. The count sat there forever with nothing to press.
The new repairBrokenCards method (admin only) runs the standard per-board pass
and then closes those gaps: orphaned-swimlane cards on archived boards, and cards
missing a listId and/or swimlaneId on any board, are assigned to that board's
first usable list/swimlane (creating a default one if the board has none). Each
board resolves its default list/swimlane once rather than once per card. Cards
with no boardId cannot be placed on any board - guessing would drop a user's card
onto an unrelated board - so they are reported back as `unfixable` and left
alone, never deleted, and the result line says so instead of leaving a count that
never reaches zero unexplained.
What counts as broken now lives in one pure module, models/lib/brokenCardsRepair.js,
used by BOTH the count and the repair, so they can no longer drift apart and
leave the admin pressing a button that does not move the number. Progress is
persisted through setBoardRepairStatus, so a running repair shows up in the same
"in progress" list as the startup pass.
Adds unit tests (positive + negative) for the shared rule, including the
regression itself: every card the count reports as broken must be either
repairable or explicitly unfixable, never silently neither.
Thanks to xet7 !
The report already paginates server-side (25 rows per page via limit/skip), so it
never loaded all cards into the browser, but two things made it feel like it did:
1. The cardsReport publication sent WHOLE card documents - description,
customFields, vote/poker sub-documents, every date field - when the table
renders only six columns. A 25-row page could be hundreds of kilobytes on
boards with long descriptions. It now projects title, boardId, listId,
swimlaneId, members and assignees only.
2. Every prev/next click re-ran the report's count method as well as
re-subscribing. getCardsReportCount counts EVERY card in the database, and the
total cannot change just because you moved to the next page, so each click
paid for a full collection count plus a second server round trip. loadReport()
now takes a `recount` flag: opening a report and searching in it recount,
plain paging does not.
Both changes apply to the other paginated admin reports too (files, rules,
boards, impersonation, recovery), which share loadReport().
Thanks to xet7 !
client/components/settings/adminReports.css was not imported anywhere, and
package.json sets meteor.mainModule, which disables Meteor's eager loading - so a
CSS file that nothing imports is simply not in the bundle. None of the Admin
Panel report styling was applied, and the prev/next buttons fell through to the
global rule in forms.css:
button { background: var(--theme-accent, #000) }
which is BLACK when no custom theme colour is set. Import it from
client/features/settings.js next to the other settings stylesheets.
Also add client/components/main/paginationControls.css: one themed look for
EVERY prev/next control in WeKan (admin reports, people/org/team/domain, All
Boards, board Table view, cron tables). forms.css also styles button:focus
(var(--theme-accent, #222)) and button:active (#111 / #e6e6e6) at a specificity
equal to or higher than a plain `.some-pagination button` rule, so even a loaded
stylesheet lost as soon as the button was clicked: pressing "next" left it with a
dark grey or grey background until it lost focus. Every state is now spelled out
at a specificity that beats the global rules, all colours come from
--theme-accent with WeKan blue as the fallback, disabled is the same themed
outline faded rather than a grey block, and the "3 / 42" page info inherits the
surrounding text colour instead of a hard-coded #333 that vanishes on dark
backgrounds.
Thanks to xet7 !
pull-security-reports.sh saves every report GitHub exposes for a repo - open AND
closed - into a timestamped run directory with one subdirectory per category of
the GitHub Security tab (CodeQuality/StandardFindings, CodeQuality/AIFindings,
CodeScanning, Dependabot/Vulnerabilities, Dependabot/Malware, SecretScanning,
Advisories, DependencyGraph), each split into open/ and closed/, as raw JSON plus
readable per-rule / per-file / per-severity text summaries.
Each category is fetched ONCE with no state filter and split locally with jq, so
open + closed are a partition of one snapshot instead of two requests taken at
different moments. A failing endpoint (feature disabled, missing token scope) is
recorded in 00-summary.txt and skipped rather than aborting the run.
Two safety properties: the secret-scanning API returns the live credential in
.secret, which is deleted before anything is written, and the reports root gets a
.gitignore excluding everything - these files describe unfixed vulnerabilities in
a public repo.
Needed because the VSCode Flatpak sandbox has neither gh nor network access to
api.github.com, so the reports have to be pulled on the host and read from disk.
Thanks to xet7 !
A SHARED list (empty swimlaneId) renders under every swimlane. cardsCount()
scoped the count by `list.swimlaneId`, which is '' for a shared list, so every
swimlane showed the whole-list count while the cards rendered below were
swimlane-scoped — e.g. "5 Cards" over an empty second swimlane. The card body
already scopes by the container swimlane via listBody.jade `idOrNull ../../_id`;
cardsCount() now takes that same `../../_id` (passed from listHeader.jade) and
prefers it over the list's own binding, so the header count matches the cards
actually rendered in that swimlane. Still gated to swimlanes view (lists view
keeps the whole-list count), and both list.cards(id) and lazyListCardCount(id)
already scope by the passed swimlane id (incl. first-swimlane shared/orphaned
surfacing), so the count is correct in both eager and lazy (#6480) modes.
tests/cardsCountSwimlaneScope.test.cjs guards the wiring; the per-swimlane card
set is covered by server/lib/tests/selectAllSwimlane.tests.js.
Thanks to xet7 !
@wekanteam/dragscroll attaches its mouse handlers PER element inside reset(),
so reset() must be re-run after the set of .dragscroll containers changes. In
boardBody.js reset() ran in onRendered (once) and in one autorun whose only
reactive deps were the touch/permission reads, NOT the swimlanes/lists. So
when swimlanes/lists rendered after onRendered — adaptive lazy card loading
(#6480), the on-open data-repair adding a default swimlane (#6484), or a board
switch that reuses this template instance without re-firing onRendered (the
#4978 case) — the new containers never got mouse handlers, so mouse/touchpad
drag-scrolling was dead and lower swimlanes could not be reached by dragging
(touch still worked via the document-delegated dragscrollTouch). The reset
autorun now reads the board view + swimlanes + lists, so it re-runs and
re-attaches whenever the rendered containers change. The reads perform no DB
writes, so there is no autorun write loop.
tests/dragscrollReattach.test.cjs source-guards the reactive reads before
reset(). Runtime UI behaviour still needs confirmation in a browser.
Thanks to xet7 !
The OpLog ts index is now created best-effort on postgresql/mysql/hana
(with a MariaDB generated-column fallback), and the MariaDB-vs-mysql-backend
assessment is complete. What remains is live-EXPLAIN index-usage
verification on each engine, which the sandbox cannot do.
Thanks to xet7 !
Later subsections in a release now start with a lowercase "and ...:" instead
of repeating "This release ...:", so a multi-subsection release reads as one
sentence (matching v10.21's existing style): Upcoming, v10.30, v10.29, v10.22,
v10.14 and v9.99. The v10.23 security header now says "CRITICAL SECURITY
ISSUES" (the wording previous releases use) instead of "CRITICAL
VULNERABILITIES". CLAUDE.md documents both conventions.
Thanks to xet7 !
Records the remaining direct, no-service translation work (142 languages,
12254 strings) as deferred, since bug fixes are more important than
translations. The #6494 tooling that makes the fill safe is already committed.
Thanks to xet7 !
Removes the machine-translation service (machine-translate.mjs) that called an
external endpoint (LibreTranslate/DeepL) and needed WEKAN_MT_URL / WEKAN_MT_API_KEY.
It did not work and could put a machine string where a human translation belonged.
Now the strings still untranslated everywhere (equal to the English source after the
Transifex pull + merge) are translated DIRECTLY — the maintainer/assistant writes the
translation using that language's existing translations and general kanban terminology
as the reference. No external service, API, endpoint, key or password.
- releases/translations/fill-translations.mjs (new): --missing lists the per-language
count still untranslated; --list <lang> dumps the placeholder keys to translate;
--apply <lang> file.json writes translations ONLY into placeholder keys, so it can
never overwrite a human translation, and ignores any value still equal to English.
- releases/translations/pull-translations.sh: drop the WEKAN_MT machine-service hook;
after the pull+merge it now prints what remains to translate. The pull always fetches
the newest Transifex translations FIRST (tx pull -a -f) and merge-translations.mjs
keeps/restores the human ones, so a fetch is never omitted and Transifex human
translations are never overwritten (the two-way process #6494 asked for).
- releases/translations/verify-human-preference.mjs (new): pure-logic proof (10 cases)
that the pull-merge keeps/restores human translations and a fill only touches
placeholders. Filled strings stay local and are NOT pushed to Transifex.
- CLAUDE.md: document the no-service direct-fill workflow and the human-preference
guarantee in both pull and push directions.
Thanks to s2ldan and xet7 !
Fixes#6494,
Add the missing entries so the Upcoming section details all real changes
since v10.31: the jam:offline/method/pub-sub removal, the six pre-existing
unit-test fixes, and the exact-version rspack pin (its own dependencies
entry). The #6511 ES-module fix now links all three of its commits
(collectionHelpers export {} e62c77575, and the two conversion parts
8d1fae4f7 + d6908cf41). Verified all commit links resolve and are reachable
from HEAD. Housekeeping commits (version bump, changelog edits, the
package-lock rspack re-resolution) get no bullet, per convention.
Once the client boots (after the ESM-conversion fix), jam:offline runs its
startup sync and throws
`can't access property "remove", localCollections[name] is undefined`
(jam_offline.js sync -> _keep): the server returns a collection name to
reconcile that the client never registered, because WeKan registers NO
offline collections (no .keep() anywhere) and does not use jam:method /
jam:pub-sub (no createMethod / createPublication / meteor/jam: imports).
These three packages were already removed once (0dd924f14: "not used, and
they cause too much database usage") and re-added in bf5ca3d3e. Remove them
again. The offline warning UI uses Meteor.status(), not jam:offline, so it
is unaffected. Meteor reconciles the transitive deps in .meteor/versions on
the next build.
These failed before the ESM conversion and are unrelated to it:
- addBoardTileHeight: the .path-right slice window was 1600 chars but
js-board-search-input is at offset 2517 after the header grew; widen to 3000.
- listWidthDefaults: isValidListWidth(269) is TRUE (269 >= MIN 200, no upper
bound); drop 269 from the "invalid widths" list.
- uiDensity: the js-open-board-menu cog moved to sidebar.jade; read that file.
- exporterBackpressure: the leaky-pattern guard matched the pattern quoted in
an explanatory comment; strip // comments before matching.
- adminReportsPagination: a 6th report section was added; expect 6
.admin-report-controls, not 5.
- fileTypeCorrection (real fix): streamHeaderToTemp unlinked the partial temp
file fire-and-forget, racing the async write-stream open, so a caller could
still see the file after the rejection. Remove it only after the write stream
has closed, then reject.
Remaining known failure: rulesApiTriggerNormalize (#2674 $in-matching) — left
for a maintainer decision on the intended rule-normalization contract.
Update the entry to reflect the complete fix: not just collectionHelpers,
but a transitive conversion of every client-bundled module.exports helper
to export, plus the exact-version rspack pins.
A transitive walk from client/main.js found the remaining CommonJS
(module.exports) helpers that the rspack client build pulls into the ES
module graph and rejects: 3 client/lib helpers (cardDragGeometry,
inlinedFormManager, popupOffset), 4 imports/lib helpers (boardAutoScroll,
datePickerTime, fileNameDisplay, staleWhileRevalidate), imports/simpleSchema
(its meteor/aldeed:simple-schema require becomes a namespace import),
imports/i18n/loadHelpers, and 4 more models/lib helpers (cardLinkRedirect,
sandstormAutoOpen, securityCategories, securityLogFormat). All become
`export { ... }`; their .cjs unit tests use `await import(...js)`.
The only CJS files still reachable in the walk are server-only: the
server/lib/* files (Meteor never bundles server/ to the client) and the
fs-using models/lib file-storage helpers (reached only via the server-side
fileStoreStrategy; they would fail on require("fs") if they were actually in
the client bundle). Those correctly stay CommonJS.
Full tests/*.test.cjs suite: same 7 pre-existing failures, no new ones.
The rspack client build treats a `module.exports` file imported into the
client bundle as an ES module and throws
"ES Modules may not assign module.exports" at evaluation time, aborting
the whole client module chain (No such template: swimlane / notifications
/ boardButtons, blank board, missing top bar). This is not an rspack
version regression (the lockfile has pinned ~1.7.x since v8.40); it is
that WeKan added CommonJS helpers to the client bundle.
Convert the 42 client-reachable pure-logic models/lib helpers from
`module.exports = { ... }` to `export { ... }`, and calendarFilter's
internal require('./swimlaneFilter') to an import with a .js extension
(node ESM needs it; rspack/reify tolerate it). Server-only helpers that
use node built-ins (fs/path/child_process) stay CommonJS. The plain-Node
.cjs unit tests for these helpers now use `await import(...js)` (wrapped
in an async IIFE); a source-guard in importVirtualMembers was updated
from module.exports to export. Verified: the full tests/*.test.cjs suite
has the SAME 7 pre-existing failures as before this change and no new
ones.
Remove the caret ranges so a fresh npm install cannot silently drift the
bundler to a newer @rspack/core (e.g. ^1.7.11 -> 1.7.12, or the 2.x line)
that changes CJS/ESM handling and breaks the build. This is drift-prevention
hygiene; the lockfile already resolved these exact versions, so it does not
by itself change the current build.
Note: the v10.27+ "ES Modules may not assign module.exports (No such
template)" break is NOT an rspack version regression -- the lockfile has
pinned @rspack/core ~1.7.9-1.7.11 since v8.40, unchanged between the working
v10.17 and the broken v10.27. The cause is WeKan-side: CJS module.exports
files entering the client bundle. Fixed separately per file (collectionHelpers)
and, durably, by moving those client-imported models/lib files to ESM.
Add the rebuild-wekan.sh developer-tooling bullet (ss fallback so the dev
server can be stopped when fuser/lsof are absent), and expand the #6511
fix entry to also cover #6514: jullbo (plain Docker, no reverse proxy,
ROOT_URL=http://neptun:4001) and AmigaAbattoir confirmed the identical
"ES Modules may not assign module.exports: 43130" -> "No such template:
swimlane / notifications / boardButtons" failure, i.e. the same global
collectionHelpers module-format bug fixed by export {}. jullbo also
confirmed the #6515 listsUnbound fix works.
Close#6514 as a duplicate of #6511 (same root cause, same fix).
Thanks to jullbo, AmigaAbattoir and xet7 !
Close#6514,
free_tcp_port() killed the process holding a port only via fuser (psmisc)
or lsof. On a minimal Linux that has neither installed, it did nothing —
yet port_in_use() detects the port via ss, so the stop loop kept
reporting "still in use" and finally "ERROR: Port 3000, 8080 or 3001 is
still in use ... Stop it manually and retry", and the dev server could
not restart. Add an ss fallback: parse the owning pid from
`ss -ltnpH "sport = :PORT"` (works for your own process without root) and
kill it. ss is part of iproute2 and effectively always present on Linux.
The earlier #6512 fix covered only the useraccounts password/register flow
(onSubmitHook). OAuth / OIDC logins use the redirect login style and do not
go through onSubmitHook: after returning from the identity provider the user
is logged in but still on the sign-in route, which renders only the language
selector ("Vaihda kieltä") until a manual page reload.
Add a client Accounts.onLogin handler (fires for every login method after
Meteor.userId() is set) that navigates to All Boards when the current route
is an auth route. Guarded to auth routes so an auto-login on a deep-linked
board URL is not redirected away, and it is a no-op after password login
(onSubmitHook has already navigated).
Thanks to xet7 !
Fixes#6512,
v10.31 was released, so the #6511 fix (collectionHelpers.js: export {}
instead of module.exports = {}, which stopped the whole client module
chain aborting with "ES Modules may not assign module.exports" -> "No
such template") goes in a fresh Upcoming section above v10.31.
imports/collectionHelpers.js (a side-effect shim that patches
Mongo.Collection.prototype) ended with `module.exports = {}`. It also
references the Meteor pseudo-global `Package` BARE, which the client
rspack build - ProvidePlugin rewrites into an injected ESM `import`,
marking this file an ES module. An ES module that assigns
`module.exports` throws, at evaluation time,
`Uncaught Error: ES Modules may not assign module.exports or exports.*,
Use ESM export syntax, instead`. Because this shim is the FIRST import in
client/main.js, that throw ABORTED the whole client module chain: app
templates (swimlane, notifications, headerUserBar, ...) never registered,
so Blaze threw "No such template: swimlane" and the board stayed on the
maintenance spinner, the top user/settings bar was missing, and the login
form did not render - reproduced on Docker, Sandstorm and the official
boards.wekan.team (root domain), i.e. a global build bug, not infra. The
regression came from converting this shim to pure require()/module.exports.
Replace `module.exports = {}` with `export {}`: a clean ES module with no
CommonJS export, so no assignment throws, and it still works as a
side-effect import on the client and require() on the server. It exports
nothing, and no consumer reads its exports (both callers import/require it
only for its side effects).
Thanks to mueschel, jullbo, akshat-goel and xet7 !
Fixes#6511,
The #6512 (post-login redirect) and #6515 (per-swimlane list repair) fix
commits post-date the v10.30 release, so they were wrongly listed inside
the tagged v10.30 section. Move them into a new "# Upcoming WeKan ®
release" section above v10.30. v10.30 keeps only what was in Upcoming
before it was cut (the bundled FerretDB OpLog ts index and the #5623
test fix).
The official boards.wekan.team (root domain, correct ROOT_URL) reproduces
these, disproving the earlier sub-path/proxy and ROOT_URL-not-set
theories:
- #6511: the "No such template" cascade is a MODULE-FORMAT build error
("ES Modules may not assign module.exports: 43130") that aborts module
evaluation so templates never register — a real global rspack build
bug xet7 is fixing, not infra.
- #6512: fixed (post-login redirect race), removed from the backlog.
- #6514: reframed — the redirect-race (#6512) and module-format (#6511)
fixes are the real causes; ROOT_URL-not-set was at most contributory.
After a successful login/register, onSubmitHook navigated to the home
route immediately, but the home route sign-in guard (renderBoardList in
config/router.js) checks Meteor.userId() NON-reactively and bounces to
the sign-in page when it is still null. Right after login the client
userId lags the onSubmitHook callback by a tick, so the navigation
bounced the user straight back to the login layout — which shows only
the language selector ("Vaihda kieltä") — until a manual page reload.
The same non-reactive guard also stranded a RETURNING user on the
sign-in page during auto-login from a stored token (Meteor.loggingIn()).
- config/accounts.js: onSubmitHook now waits reactively for
Meteor.userId() before FlowRouter.go("/"), with a 5s timeout fallback
so a login that never lands userId still navigates.
- config/router.js: renderBoardList no longer bounces to atSignIn while a
login is in progress (Meteor.loggingIn()); the All Boards list fills in
reactively once userId lands.
This is the post-login-redirect part of the WeKan 10.30 login feedback;
the separate "No such template" board failure (#6511) is a module-format
build error being fixed separately.
Thanks to akshat-goel and xet7 !
Fixes#6512,
Two distinct core templates (swimlane #6511, notifications #6515
secondary) reported "No such template" at render time on different
proxy/sub-path deployments, both correctly defined in the main bundle —
so this is a client-bundle delivery / init problem on those deployments,
not a per-template source bug. Recorded so it is not mistaken for a fix
that can be made blind.
repairBoardsOnStartup ran the shared board repair over every board and,
via planBoardRepair, cleared swimlaneId to null on EVERY list that had
one -- treating any swimlane-bound list as #6484 corruption. But a list
with a swimlaneId is a legitimate PER-SWIMLANE list (rendered only in its
swimlane via swimlaneLists()), indistinguishable from a #6484-corrupted
board-wide list at the data level. So on upgrade to v10.26+ the routine
silently unbound every per-swimlane list (the reporter: listsUnbound: 24)
and all lists then rendered in every swimlane. Board open re-ran the same
repair, so even a manual swimlaneId restore in the DB was nulled again.
Remove list-unbind from the automatic plan (planBoardRepair.listsUnbind
is always empty; repairBoardData no longer issues the swimlaneId: null
write). The card repairs (missing-swimlane, orphaned) are kept. The
#6484 CODE bug that could wrongly bind a board-wide list is already
fixed, and an admin can still deliberately un-bind a specific board with
the explicit repairBoardWideLists method. Affected boards keep their
swimlaneIds now; a manual restore from a pre-upgrade backup will stick.
Tests: boardRepair.test.cjs updated to assert per-swimlane lists are
never auto-unbound and the applier no longer clears swimlaneId.
Thanks to jullbo and xet7 !
Fixes#6515,
Record the stale-test fix (50a7c8fe5) under Upcoming bug fixes so every
post-v10.29 change is reflected. The zh-TW translation update (1e73b1bef)
is covered by the standard "translators for their translations" footer,
per convention (per-language pulls are not individually bulleted).
The doubled-cards render fix (c90d6eaa4) changed
filterCardsByListAndSwimlane so shared/orphaned cards (swimlaneId
null / '' / missing / a deleted swimlane) surface ONCE, in the FIRST
swimlane, instead of in every swimlane: the first swimlane is signalled
by passing the OTHER swimlanes ids as the 4th otherSwimlaneIds argument
(what allCards() gets from orphanedCardsSwimlaneIds, which returns them
only for the first swimlane); a non-first swimlane gets no 4th argument
and returns only its own cards. That commit did not update this test, so
it still asserted the old behaviour (a bare swimlaneId returning own +
orphaned) and failed: expected [c1,c2,c5,c6,c7], got [c1,c2].
Update the test to the current contract: the FIRST-swimlane case passes
otherSwimlaneIds=[S2] and still expects [c1,c2,c5,c6,c7], and a new
NON-first-swimlane case asserts only [c1,c2]. Verified the assertions
against the exact helper logic.
Triaged all open issues created this year; none are confidently
already-fixed, so none are closed. Recorded the two not yet in the
backlog:
- #6509 (fresh v10.27 on FerretDB v2 + PostgreSQL, lists/cards not shown
until reload, undefined.remove() -- same Blaze ordered-diff class as
#6511; not closed because the identical-signature #6511 reporter says
it persists on 10.28).
- #6500 (Docker latest does not load, Connection reset by peer -- xet7 is
actively fixing the bundled FerretDB Docker startup; needs the running
Docker stack).
v10.29 was released, so this post-release note goes in a fresh Upcoming
section (not retroactively into the tagged v10.29): the bundled FerretDB
v1 fork now creates the OpLog ts index on the PostgreSQL, MySQL and SAP
HANA backends (not only SQLite), best-effort with a descriptive log if a
live engine rejects the syntax. See the FerretDB fork changelog.
Collect every real change committed after the v10.28 release into a new
"# Upcoming WeKan ® release" section above it: the snap external
PostgreSQL/MySQL/HANA FerretDB backend and the placeholder-only machine
translation step (new features), and the snap wekan.problems
settings-loading fix that makes ROOT_URL / LDAP checks read the real
config (bug fix, helps #6512 / #6514). Changelog-only housekeeping
commits (link repointing, TODO Later, version bump) are not listed.
The per-key merge (merge-translations.mjs) already guarantees a Transifex
pull never loses a human translation: it keeps the newest Transifex
translation, restores a committed human translation the pull reverted to
English, and leaves the English source ONLY on strings untranslated
everywhere. This adds the missing machine-translation step that fills
exactly those English placeholders — so machine translation can never
overwrite a human translation (a human string, value != English, is
never selected), and a language with no translation at all (every key a
placeholder) gets fully filled.
- machine-translate.mjs: placeholder-only selection (value === English
source, or key missing); pluggable LibreTranslate-compatible provider
(WEKAN_MT_URL / WEKAN_MT_API_KEY); English + en-* variants skipped;
--dry-run, --limit N (resume-friendly), --provider-check; preserves
en key order + 2-space indent + trailing newline. Machine output stays
local and is NOT pushed to Transifex.
- pull-translations.sh: run the machine step AFTER the merge, opt-in via
WEKAN_MT=1 or WEKAN_MT_URL, so a plain pull is unchanged.
#6514 and #6512 (login page shows only the language selector; header
renders empty with no user/settings menu after a 10.28 upgrade): the
reporter wekan.problems output shows ROOT_URL is not set even after
snap set root-url, which is the root cause -- a wrong/absent ROOT_URL
breaks DDP, so useraccounts never supplies the router content template
that userFormsLayout renders and currentUser stays null, while
jam:offline replays cached boards. Operational fix is to set ROOT_URL
and restart; the wekan.problems settings-loading fix in this release
already surfaces the real value. Recorded for live confirmation.
Also recorded the FerretDB v1 backend-parity in-progress work (oplog ts
index + declared-index usability across PostgreSQL/MySQL/HANA) with the
web-searched authoritative index syntax and the live-EXPLAIN
verification boundary, so the next session can resume.
The v10.28 card-sort _id tiebreaker addressed the first reported error
(Bad index in range.removeMember). The reporter now sees a different
console error, "No such template: swimlane", with the board still
showing no cards. That template is a core Blaze template compiled into
the main bundle and statically included as +swimlane in boardBody, so it
is not a lazy chunk that could 404 under a sub-path; Blaze nonetheless
reports it missing at render time. The deployment is on a /wekan
sub-path with wss .../wekan/sockjs/... 400 Bad Request plus wasm and
source-map errors, so the evidence points at the reverse-proxy WebSocket
upgrade / sub-path bundle delivery, not a WeKan source bug. Left for
live reproduction with the reporter proxy setup rather than guessing a
blind code change.
A rebase left 24 CHANGELOG commit links pointing at pre-rebase hashes
that no longer exist. Repointed each to the actual commit, matched by
subject (and, for the full-hash links, an exact issue-number anchor):
- 9 short links: template drag-to-share / GlobalAdmin REST / domain
sharing / auth-sync (#5850), snap Node.js-download 404 fix, LDAP-OAuth2
env-var docs, and the rebuild-wekan Playwright-Docker matrix.
- 15 full-hash links: #3185#3606#3624#4055#4236#4249#4394#4494#4653#4881#4946#4978#5439#5536 bug-fix entries.
Remaining older full-hash links were left as-is: an orphaned commit is
still reachable by full SHA on GitHub, and the ambiguous ones (generic
"Part 1/2" subjects, no issue anchor) need a human to confirm.
Part of bringing the non-SQLite FerretDB v1 backends to Meteor parity: let the snap run
FerretDB with a backend other than the embedded SQLite, against an EXTERNAL database the
operator hosts (the snap bundles no PostgreSQL/MySQL server).
New snap settings (snap-src/bin/config): wekan-ferretdb-handler (sqlite [default] /
postgresql / mysql / hana) and wekan-ferretdb-url (the connection URL for the external
backend). ferretdb-control now branches on the handler: for a non-sqlite handler it
execs FerretDB with --handler=<engine> --<engine>-url=<url> (the fork's binary already
exposes --postgresql-url / --mysql-url / --hana-url) and SKIPS every SQLite-file step
(rotating backup, restore, reset-oplog, corruption pre-open repair), which apply only to
the embedded SQLite file. The same wekan-ferretdb-oplog gate applies: the replica set /
OpLog is created only when opted in, otherwise standalone (polling) — and because the
OpLog/reactivity machinery is backend-agnostic, Meteor tails the OpLog on the external
backend when enabled.
snap set wekan wekan-ferretdb-handler=postgresql \
wekan-ferretdb-url="postgres://user:pass@HOST:5432/ferretdb"
Backend query correctness/performance still needs the FerretDB integration suite against
the live engine (see FerretDB ROADMAP.md).
Thanks to xet7 !
Reported: after `snap set wekan root-url="https://..."`, `snap run wekan.problems`
still showed "ROOT_URL is not set". Cause: the wrapper exec'd wekan-problems.mjs
WITHOUT the snap settings in its environment, so `process.env.ROOT_URL` (and
LDAP_ENABLE) were empty in that process and the login-page checks always reported
ROOT_URL unset — regardless of the snap setting. The DB-backed checks (broken cards,
migrations/repairs in progress) were correct; only the env-derived ones were wrong.
Source `$SNAP/bin/wekan-read-settings` (echo suppressed) before exec so ROOT_URL /
LDAP_ENABLE / DATABASE etc. are exported and the login-page checks see the same
configuration WeKan runs with.
Thanks to xet7 !
Follow-up to the #6508 import fixes: in the board view, clicking an imported
(placeholder) board member's avatar showed no "Remap User" action. The board member
popup gates it on isImportedMember(), which checks `authenticationMethod ===
'imported'` — but the board composite published board members' user docs with only
username / profile.fullname / avatarUrl / initials, WITHOUT authenticationMethod
(user-miniprofile, which publishes safeFields incl. authenticationMethod, is only
subscribed on the import screen). So the field was undefined on the client and the
action never appeared.
Publish authenticationMethod with the board members' user fields (it is already in
Users.safeFields, so this is consistent and not newly-exposed). The in-board "Remap
User" -> mapImportedBoardMember flow now works for imported board members.
Test: tests/importVirtualMembers.test.cjs guards the field is published.
Thanks to AmigaAbattoir and xet7 !
Fixes#6508,
The board card list is a Blaze {{#each}} over a LIMITED, ordered reactive cursor
sorted by `{ sort: 1 }`, which has TIES. When several cards share the same `sort`
value (or the same due date, etc.), their order is non-deterministic across
observe/poll cycles, so Meteor's diffQueryOrderedChanges computes an out-of-range
index and Blaze throws `Bad index in range.removeMember: 0`. That aborts the #each,
so the board renders NO cards (and cascades into the `undefined.remove()` teardown
error). An index-backed board card query (a recent fix) can change the tie order and
expose this.
New pure, tested helper models/lib/cardSortTiebreaker.js appends a UNIQUE `_id` key
as the final sort key (object and Meteor array forms; idempotent), making the total
order deterministic so the ordered diff is always well-defined. Applied in
client/components/lists/listBody.js (cardsWithLimit — the crashing #each, before both
the window subscription and the client cursor) and server/publications/cardsWindow.js
(the published limited window, so "first N cards" is stable between polls).
Test: tests/cardSortTiebreaker.test.cjs. Likely also resolves the same
range.removeMember "no cards" reports on other backends.
Thanks to mueschel and xet7 !
Fixes#6511,
The example config is correct, but a common mistake is proxying WeKan with
`proxy_set_header Connection "";` (or omitting the `map $http_upgrade
$connection_upgrade` / `proxy_http_version 1.1`), which stops the SockJS WebSocket
upgrade and surfaces as `WebSocket connection to 'wss://HOST/sockjs/.../websocket'
failed`. Add a Troubleshooting section explaining the symptom and the exact three
lines (and the http-context map) needed on every proxy hop.
Thanks to akshat-goel and xet7 !
Fixes#6510,
The login-page checks used affirmative titles ("ROOT_URL is set", "A migration or
repair is in progress"), so a FAILING one printed e.g. "[error] ROOT_URL is set:
ROOT_URL is not set" — confusing. Use neutral subjects ("ROOT_URL", "Migration or
repair") so the "[severity] <title>: <detail>" line reads correctly in every state.
Thanks to xet7 !
The comment-only feed (showActivities off) selected activities with
`$and: [{activityType:'addComment'}, {boardId/cardId: {$in}}]`. FerretDB v1 (SQLite)
does not push down a top-level $and, so the activities collection was full-scanned on
every poll — slow history on a big board. The two keys are distinct, so merging them
into one top-level object is exactly equivalent and lets both push down to the index
(same fix as the 10.22 card-window flatten).
Thanks to xet7 !
A) Import "map members": clicking a searched user threw
`TypeError: Cannot read properties of undefined (reading '_id')` at
`click .js-select-import`. The handler read `Template.currentData()._id`, which is
undefined when the click lands on a CHILD of the anchor (the avatar or the name
span). Read the WeKan user id from the anchor's `data-id` (event.currentTarget)
instead, and guard it — robust regardless of which inner node was clicked.
B) Admin Panel / People: saving an IMPORTED (placeholder) user as an active person
with an email threw `TypeError: Cannot read properties of undefined (reading '0')`.
The profile submit handler read `user.emails[0].verified` (and `.address`), but an
imported placeholder user (and some SSO users) have no `emails` array at all. Read
the primary email defensively (missing OR empty array) via a `primaryEmail` guard.
Tests: tests/importMapUserFixes.test.cjs; tests/importMemberMapping.test.cjs updated
for the data-id mapping.
Thanks to AmigaAbattoir and xet7 !
Fixes#6508,
The rebase rewrote eb80ee69f -> 0e0391f6c (#6506) and 00ef255b0 -> 72768e05f (#6507);
the old hashes were pre-rebase orphans that were never pushed, so their CHANGELOG
links would 404 on GitHub. Updated to the current on-branch hashes.
Thanks to xet7 !
On a fresh install (no Settings document yet, and Meteor.user() briefly null right
after the first admin logs in) the Admin panel would not open, the title bar
sometimes failed to load or showed "You are not authorized to view this page", and
the console looped `Uncaught (in promise) TypeError: Cannot read properties of
undefined (reading 'remove')` through a Tracker computation.
Root cause: ReactiveCacheClient.getCurrentSetting() and getCurrentUser() guarded
their DataCache with `!this.__x || !this.__x.get()`. Every other getter creates its
DataCache ONCE (`if (!this.__x)`), but these two ALSO rebuilt it whenever the cached
value was FALSY — so while the setting/user was absent (a fresh install, or any
transient null) a brand-new DataCache, and a brand-new Tracker.autorun, was
constructed on EVERY reactive read. That continuous create/teardown churned
computations across every app-wide template (header, admin gates) and raced Blaze's
view teardown, producing the infinite reactive loop and the removed-DomRange crash
(the same WebKit Blaze class the getBoard staleWhileRevalidate comment guards).
Fixed by creating the DataCache once, keyed on `!this.__currentSetting` /
`!this.__currentUser` only, like every other getter; the autorun already updates
reactively when the Settings document / user appears, so no rebuild is ever needed.
Returning a stable null until they exist is correct and loop-free.
Test: tests/reactiveCacheCurrentGetters.test.cjs.
Thanks to AmigaAbattoir and xet7 !
Fixes#6507,
Every board card query used `{ boardId: { $in: [board._id, board.subtasksDefaultBoardId] } }`,
and subtasksDefaultBoardId defaults to null. On FerretDB v1 (SQLite) a $in that
contains a non-string element (the null) does not push down at all, so the WHERE was
dropped and the whole cards collection was full-scanned + sjson-decoded on every
poll-and-diff cycle, across ~7 card cursors per board open. Lists and swimlanes use a
plain boardId equality (index-backed) and stayed fast — so on a big board the columns
appeared but the cards never did.
New helper models/lib/boardCardScope.js builds the scope WITHOUT null and prefers a
plain equality (index seek) when only the board itself is in scope, else an
all-string $in (which pushes down). Applied to every card-scope site in
server/publications/boards.js (8x), cardsWindow.js and cards.js.
Also flatten the lazy card-window selector (cardsWindow.js): the window was
`{ $and: [clientSelector, { boardId, archived }] }`, and FerretDB does not push down
a top-level $and, so boardId/archived were full-scanned too. Merge the board scope at
the top level (exactly equivalent when the client selector has no boardId/archived
key, which it does not — it is a per-list listId + swimlane selector; a collision
guard keeps $and otherwise), so boardId/archived push down.
The FerretDB fork side is hardened separately so a mixed $in (incl. null) also uses
the index. Test: tests/boardCardScope.test.cjs.
Thanks to xet7 !
Regression from c0a1a2784 (v10.12): it dropped `importMapMembers` from the import
wizard's `steps` array and hardcoded an empty membersMapping in finishImport, so the
map-users screen never rendered and every imported card/member/comment was assigned
to the importing user even when the person existed in WeKan.
Client (client/components/import/import.js):
- restore `steps = ['importTextarea', 'importMapMembers']` so the (auto-suggesting)
map-members step shows again;
- finishImport builds membersMapping from the members the user mapped
(member.wekanId), instead of sending `{}`. The step stays OPTIONAL — the Skip
button and the textarea "import without mapping" button still bypass it.
Server — unmapped members become virtual users instead of collapsing onto the importer:
- models/trelloCreator.js: new createPlaceholderUsers(board), run in create() before
the board is built, so it covers BOTH the Trello JSON import and the Trello API
(all-boards background) import. For each member not already mapped it maps to an
existing WeKan user by username / recorded importUsername, else inserts an inert
virtual user (loginDisabled, isActive:false, authenticationMethod:'imported')
reusing the Trello member id, so board membership and authorship keep the original
person;
- models/wekanCreator.js: createPlaceholderUsers no longer overwrites an explicit UI
mapping (skip members already in this.members) so a member mapped to a real account
is not clobbered by the identity placeholder.
A board admin can still map a virtual member to a real user later from the sidebar
(that feature is unchanged). Tests updated: tests/importVirtualMembers.test.cjs and
tests/importMemberMapping.test.cjs.
Thanks to AmigaAbattoir and xet7 !
Fixes#6506,
v10.22 was cut while these fixes were in flight, so the CRITICAL entries go in a
fresh Upcoming section above it.
Thanks to koyokr, GitHub CodeQL and xet7 !
stripExploitPatterns() looped a CHAIN of six replaces to a fixpoint. That is
runtime-safe, but CodeQL (correctly, as a local check) could not attribute the
fixpoint to the individual `<[^>]*>?` tag replace, so it kept flagging it as an
incomplete sanitizer that "may still contain <script".
Restructure to the proven-complete pattern already used by
client/lib/importDependencies.js stripHtml() (which cleared the sibling alert
#421): remove template/PI/CDATA tokens (looped), then strip HTML/XML tags with a
SINGLE `replace(/<[^>]*>/g, '')` looped to a fixed point, then drop any stray
angle bracket so an UNCLOSED tag (no '>', e.g. a trailing "<script") cannot
survive either. Behaviour is unchanged for every existing case.
Regression: tests/fileNameDisplay.test.cjs now asserts completeness for closed,
unclosed and spliced tags (no '<', '>' or '<script' in the output).
Thanks to xet7 !
A board member could store entity-encoded markup in a card title. It stays inert
on the live board (Blaze escapes it; the +viewer sanitizer neutralizes handlers
and keeps the entity payload as text), but the exported index.html embedded a
click handler that read the card title/body via .textContent — which DECODES HTML
entities — and then concatenated those values into content.innerHTML. That SECOND
parse revived the tag (e.g. `<img src=x onerror=...>`) and executed it when a
recipient clicked the card in the export, disclosing all data in that document
(including cards added after the attacker's board membership was removed).
The modal is now built with DOM nodes and the card title/body are assigned through
textContent, never innerHTML, so they are inserted as inert text.
Regression: tests/exportHTMLXss.test.cjs (title/body reach only textContent; no
titleText/allText flows into any innerHTML; a textContent assignment does not
revive an entity-decoded <img>).
(CWE-79 stored XSS, GitHub Security Advisory GHSA-8r5p-4q9j-f5jx.)
Thanks to koyokr and xet7 !
The 10.16-10.21 reports of the ferretdb process pegging ~2 cores for a long time
while node sat idle are the signature of an OpLog tail: Meteor holds a tailable
cursor on local.oplog.rs and FerretDB re-scans it server-side. wekan-control
already defaults to polling-only (it clears MONGO_OPLOG_URL), but ferretdb-control
passed --repl-set-name unconditionally, so FerretDB ALWAYS maintained the capped
OpLog (a second write per mutation, a once-a-minute cleanup, and a tailable cursor
for any stray MONGO_OPLOG_URL to spin on) even when WeKan would not tail it.
Gate --repl-set-name on WEKAN_FERRETDB_OPLOG (default false), matching
wekan-control: in the default polling-only mode FerretDB now runs STANDALONE, with
no OpLog at all; the replica set / OpLog is created only when the admin opts in with
wekan-ferretdb-oplog=true. Opting in is now also cheaper on the FerretDB fork side
(the {ts: {$gt}} tail filter is pushed down and the OpLog Timestamp indexed).
Docs: docs/Features/Admin-Panel/Problems/Migrations.md (FerretDB reactivity mode).
Test: tests/ferretdbOplogGating.test.cjs.
Thanks to xet7 !
The reporter confirms OIDC works again after updating to WeKan 10.21. The two
source parts (the raw i18n key `changeLanguagePopup-title` and the `oplog catching
up took too long` stalls) were fixed in v10.16+; the remaining dead OIDC/Register
buttons were a stale dynamic-import bundle cache on the snap after the refresh
(no source regression), which a clean >=10.16 build clears. Removed from the
TODO Later backlog.
Thanks to Alishara and xet7 !
Closes#6503,
The rebase onto origin/main rewrote the local commit hashes, so the Upcoming
section's commit links pointed at pre-rebase hashes that never reached the remote.
Update all six to the pushed hashes (doubled-cards, repairBoardWideLists, board-open
auto-detect, shared board data-repairs, #6504 card-move fix, Problems Status /
snap wekan.problems).
Thanks to xet7 !
docs/Features/Admin-Panel/Problems/README.md describes what Problems offers and
links the detailed pages (existing CPU/RAM/Disk/Recovery plus the new Repairs,
Migrations, Login-Problems and Snap pages). Snap.md documents `snap run
wekan.problems` and its sub-commands (migrations | login | broken-cards | cpu).
Repairs.md / Migrations.md cover the shared board data-repairs and the MongoDB <->
SQLite migration, when they run (board open, server startup, during migration) and
the progress dashboard. Login-Problems.md explains the "Must be logged in" /
"Loading, please wait" causes and fixes, tying them to a saturated ferretdb.
Thanks to xet7 !
Motivated by the 10.16-10.21 reports where, after an upgrade, the login page
showed "Must be logged in" or sat on the logo + "Loading, please wait." spinner,
pages took 5+ minutes, All Boards counts stayed 0 and i18n showed raw keys — the
FerretDB v1 (SQLite) process pegged ~2 cores for a long time under WeKan's poll
load, i.e. a migration/repair or a saturated backend, with no way to see it
without the Admin Panel.
Server-side, independent of any client / progress page:
- server/startup/repairBoardsOnStartup.js runs the shared board data-repairs once
(version-gated, background, 30s after boot) so corrupted data is fixed even if
no user opens a board and nobody watches a progress page.
- The MongoDB <-> SQLite text migration and the startup repair now PERSIST their
progress to the text_migration_status collection (models/textMigrationStatus.js),
so a separate process can see "a migration/repair is in progress" (an in-memory
object could not).
Status overview (server/lib/systemStatus.js), shown in Admin Panel / Problems ->
Summary and via the method systemStatusReport (admin-gated, server/methods/
systemStatus.js):
- everything in progress (text migration, board repair, recovery, cron migration,
attachment migration) aggregated from the persisted status collections;
- detected problems (broken cards; failing login-page checks);
- login-page "Must be logged in" / "Loading, please wait" cause checklist
(migration in progress, ROOT_URL, LDAP, Sandstorm) — models/lib/loginProblems.js;
- a CPU detail area that calls out a pegged ferretdb process and the mitigation.
Snap: `snap run wekan.problems` (snap-src/bin/wekan-problems[.mjs], snapcraft app
`problems`) prints the same overview as text — problems, migrations/repairs in
progress, login checks — so an admin with only server access can see it WITHOUT
Admin Panel access. Sub-commands: migrations | login | broken-cards | cpu | help.
Pure helpers models/lib/loginProblems.js and models/lib/problemsOverview.js are
unit-tested; tests/problemsStatus.test.cjs (14 checks) also source-guards the
server hub, method, startup pass, migration persistence and snap command.
Thanks to xet7 !
On the server ReactiveCache.getBoard() is async (returns a Promise). The
cross-board branch of Cards.helpers.move() called it without await, so `newBoard`
was a Promise: `newBoard.getNextCardNumber()` threw, and `oldBoard` being a
Promise silently dropped label carry-over. Await both getBoard() calls (same fix
as PR #6505).
Added tests/cardMoveAwaitBoard.test.cjs as a regression guard.
Thanks to ChristianMa97 and xet7 !
Closes#6505,
Fixes#6504,
The board-open self-heal is broadened from the #6484 list-unbind alone to a
shared repair set (models/lib/boardRepair.js planner + server/lib/repairBoardData.js):
- #6484: lists wrongly bound to a swimlane -> cleared back to board-wide, so the
list stops "disappearing" from the other swimlanes;
- cards with no swimlaneId (null/''/missing), which never render in the Swimlanes
view -> assigned to the board's first swimlane;
- orphaned cards whose swimlaneId points at a DELETED swimlane (invisible cards)
-> reassigned to the first swimlane. A card on an existing but archived swimlane
is NOT treated as orphaned.
The same repair set now runs in BOTH places:
- Board open: boardBody.js maybeRepairBoard -> boardRepairNeeded / repairBoardData
(server/methods/repairBoardData.js), once per board, admin-gated, fire-and-forget.
- MongoDB <-> FerretDB v1 (SQLite) text migration: migrateTextDatabase runs
repairAllBoards() on the live database BEFORE copying, so the migrated copy is
clean too. It reports a new "repairing" phase (boardsDone/boardsTotal/repaired).
Both flows drive ONE shared progress dashboard (migrationProgress), now:
- mounted app-wide (defaultLayout) so it shows for an Admin Panel database
migration as well as a board-open repair;
- fed from the DB-migration status poll (attachments.js driveMigrationDashboard);
- styled in WeKan blue (#2980b9) instead of the old purple/green;
- branded with the configured Product name (from the earlier commit).
Tests: tests/boardRepair.test.cjs (planner + server/migration/dashboard source
guards, 11 checks) and the updated tests/listUnbindRepair.test.cjs pass.
Thanks to xet7 !
When a board opens it now checks (boardListRepairNeeded) whether any list is
wrongly bound to a single swimlane (the #6484 corruption, which makes a list
vanish from the other swimlanes). If so, and the viewer is a board admin, it
runs repairBoardWideLists automatically while showing the shared
migration-progress modal, then completes. The check runs once per board,
fire-and-forget, and never blocks rendering; on error the board is unmarked so a
later open retries.
The migration-progress modal is now branded with the configured Product name
(Admin Panel / Settings / Layout / Product name, Settings.productName), falling
back to WeKan when none is set, via the pure models/lib/productName.js helper —
so the repair (and every migration reusing this modal) shows the admin's Product
name instead of the hard-coded WeKan brand.
Tests: tests/productName.test.cjs (helper + modal-branding source guards) and
the extended tests/listUnbindRepair.test.cjs (detection method + client
detect/repair/progress wiring) pass.
Thanks to xet7 !
The #6484 bug (nudging a board-wide list in swimlanes view bound it to one swimlane and moved its cards there, so it vanished from the other swimlanes) is fixed in code, but boards already hit keep the wrongly-set list.swimlaneId. New board-admin-gated method repairBoardWideLists(boardId) clears swimlaneId back to null for every swimlane-bound list on that board, restoring them to board-wide (rendered under every swimlane). Idempotent (lists already board-wide are skipped), scoped to the one board, and returns the count repaired. The list-selection is a pure, unit-tested models/lib/listUnbindRepair.js. Note: this repairs the LIST binding only; cards the bug moved into one swimlane are not restored (their intended swimlane is unknown -- recover those from a backup).
Tests: tests/listUnbindRepair.test.cjs (5 checks) covers listsToUnbind (selects bound lists, idempotent, invalid inputs, non-string swimlaneId) and a source guard that the method is board-admin-gated, uses the helper, clears swimlaneId to null, and is scoped to the board.
Thanks to xet7.
In swimlanes view a card with swimlaneId null/'' (a 'shared' / pre-migration card) was surfaced in EVERY swimlane: swimlaneMembershipSelector used { swimlaneId: { $in: [swimlaneId, null, ''] } } for non-first swimlanes, and filterCardsByListAndSwimlane matched null/''/missing there too. On a board with several swimlanes the same shared card therefore rendered once per swimlane -- the reported 'doubled cards/entries', which also bloats the DOM (contributing to the search hang / can't-scroll on big boards). A non-first swimlane now matches ONLY its own cards ({ swimlaneId }); shared and orphaned cards surface ONCE, in the FIRST swimlane (the $nin branch, unchanged), so a card is never shown in more than one swimlane. Still a single field clause, so the #6441 board-wide label-filter fix is preserved (verified in the tests).
Tests: tests/swimlaneFilter.test.cjs updated -- a non-first swimlane matches only its own cards; shared/orphaned cards appear once in the first swimlane and are still filtered by the active label filter; #6441 board-wide filtering for cards that HAVE a swimlaneId is unchanged. 18 checks pass.
Thanks to xet7.
Note that #6503 is partly fixed in v10.16+ (the raw i18n key via static-bundled English + timeout-bounded init, and the 'oplog catching up' stalls via the FerretDB polling-only default), while the remaining dead OIDC/Register buttons are not a source regression (login code identical 10.11->10.13) but a stale dynamic-import bundle cache on the snap, needing the reporter to confirm on a clean >=10.16 install with cleared cache, plus a browser console/Network capture if it persists.
Thanks to Alishara and xet7.
Add a 'Deferred pending a security decision' bucket for syntax/color highlighting of code blocks in the card +viewer (also asked in #5149): it is possible via MarkdownIt's highlight option + a highlighter like highlight.js, but the viewer's DOMPurify strips every class/id attribute for CSS-injection safety, so a highlighter's <span class=hljs-...> output would lose its classes and show no colour. Enabling it needs a tight allowlist of hljs-*/language-* classes on spans inside pre>code, a sanitizer relaxation xet7 has not decided on yet.
Thanks to xet7.
The copy-code-block feature existed but the reporter saw it 'work very sporadically (only a handful of items have it)' and lost after editing. Root causes: it ran ONCE in Template.editor.onRendered with a global document.querySelectorAll('.viewer > pre'), so it decorated only whichever viewers were on the page at that instant and never re-added the button after an edit re-rendered the viewer; and it copied the HTML-escaped innerHTML of the <pre>'s first child node (often the wrong content or undefined) via the deprecated execCommand. Now the decoration lives in Template.viewer.onRendered, so EVERY viewer (card description, checklist item, comment) gets a copy button and it is restored on every re-render; it is de-duplicated (skips a <pre> that already has its button) so re-renders never stack buttons; it copies the RAW code text (pre.textContent) via navigator.clipboard.writeText with an execCommand fallback; and the button title is translated (the existing 'copy-text-to-clipboard' i18n key) instead of a hard-coded English string.
Tests: tests/copyCodeBlock.test.cjs (5 checks) guards that the decoration is in Template.viewer.onRendered scoped to the viewer's <pre>, copies textContent (not innerHTML), de-dups, is translated, and uses the async Clipboard API with a fallback.
Thanks to C0rn3j and xet7 !
Fixes#5149,
A card URL is /b/:boardId/:slug/:cardId; after the card was moved to another board the link opened the OLD board and found nothing. The card route now resolves the card via the permission-checked 'card' publication (server/publications/cards.js, which only returns the card when the user may see its board) and, if the card's CURRENT board differs from the URL's board, redirects to /b/<currentBoard>/<slug>/<cardId> so the card opens where it now lives -- so a link stays valid across board moves as long as the viewer has access to the destination board (like Trello). When the user cannot see the card's new board (or it is gone) the probe subscription yields nothing and the URL's board is kept, and the redirect is guarded against a redirect loop (target board matches -> stop) and against firing after the user navigated away. The decision is a pure, unit-tested models/lib/cardLinkRedirect.js. (A toast telling the user 'this card was moved to a board you cannot access' in the no-access case is a possible follow-up.)
Tests: tests/cardLinkRedirect.test.cjs (6 checks) covers the moved-card redirect, the same-board no-op, missing/invalid card (stay put), the no-loop invariant, and a router source guard that it drives off the permission-checked 'card' publication.
Thanks to Robdebert and xet7 !
Fixes#4758,
#4043 ('Sometimes user get board invitation by mail without invitation code' — recipients got an email whose code the sign-up form rejected with 'The invitation code doesn't exist') is already fixed and shipped: the pure models/lib/invitationCodeEmail.js rules (normalizeInviteEmail lowercases the stored email so it matches the sign-up form, isInvitationCodeSendable refuses to mail a missing/invalid code, buildReinviteModifier overwrites a stale code with a fresh valid one on re-invite, and shouldRemoveInvitationOnEmailFailure only rolls back a code created by this very invite) are wired into server/models/settings.js sendInvitation and covered by tests/invitationCodeEmail.test.cjs (14 checks, incl. the settings.js wiring). It was mis-filed under 'Feature requests' in the CHANGELOG TODO Later; removed from there.
Thanks to Emile840 and xet7 !
Fixes#4043,
#6430 (~1s card flicker dragging on large boards — a drag/reactivity re-render; xet7 already reduced it in 2e7c4ed but it persists, needs a large board + browser to profile) under 'need the running app'; #5323 (due-date notification/webhook with per-board offset — the built-in NOTIFY_DUE reminder already exists and was improved in #3192, so the remainder is a feature) under 'feature requests'.
Thanks to xet7.
Explain what the '# TODO Later' section at the top of CHANGELOG.md is for (open issues investigated but not fixed here, each with a concrete reason), how it fits the 'Fix open issues' process (fix / close-if-already-fixed / else add to TODO Later with the reason), the category buckets (need infra/running-server, need the running app to reproduce, already-correct, feature/by-design, needs a maintainer decision), that entries use issue links (not commit links) since nothing was committed, and that fixed issues must be REMOVED from the list once their Fixes #NNNN commit closes them.
Thanks to xet7.
Continue triaging open issues that cannot be fixed/verified in this sandbox: #1942 (blank/frozen view opening a linked card the viewer has no rights to — runtime permission + reactive close), #1995 (edit fields on a linked card — feature/by-design, same class as #3748), #3001 (manipulated headers behind an Apache reverse proxy — a proxy-config concern needing the reporter's setup). #1972 and #2306 already carry Fixes commits and close on push.
Thanks to xet7.
#1158 (on a public read-only board an anonymous / not-logged-in user could still DRAG lists, which made mobile scrolling almost impossible even though the reorder was denied server-side) is already fixed by #5462: all three list sortables in client/components/swimlanes/swimlanes.js set disabled: !Utils.canModifyBoard(), and canModifyBoard() requires a current user who is an active, non-comment-only, non-read-only board member -- so an anonymous user (no currentUser) can never drag lists. Covered by the Playwright spec 35-list-sort-permissions.e2e.js; this adds a plain-node source-guard so the invariant (every list sortable gated by canModifyBoard, which is falsy for anonymous) cannot silently regress.
Thanks to GenericUK and xet7 !
Fixes#1158,
Remove entries that have since been fixed (they carry Fixes #NNNN and close on push): #4560/#4419/#4158 (LDAP, startup-upgrade batch), #4825/#4897, #4822, #3826, #5282/#5547, #3453/#3199/#3843, #4593 and #3037 — with a short note in the intro pointing at them. Add newly-triaged still-open issues with the reason each is not fixed here: #1094/#2445 (need a running server stack / environment), #1658/#1946/#5052/#5421/#761 (need the running app to reproduce/verify), and #5081/#1213 (feature/design proposals). Drops the now-empty 'LDAP security/config' and 'Incomplete report' buckets.
Thanks to xet7.
#3037 (moving a card between boards via the API bounced back to the old board when only the raw boardId/listId were edited) is already fixed: the edit-card handler (server/models/cards.js) normalizes newBoardId/newSwimlaneId/newListId via normalizeMoveParams, and when all three are present (isBoardMove) it validates the destination list+swimlane belong to the destination board and re-homes the card through cardMove(..., ['boardId','swimlaneId','listId'], ...) instead of a raw field update (Issue #5398/#5399). The pure helpers had only Playwright coverage; this adds a plain-node unit test (dynamic import of the ES helper) covering normalizeMoveParams (all-three => board move, a PARTIAL set is NOT a board move so a card is never half-moved, same-board move, empty/empty-string negatives) and computeTopSort, plus a source guard that the handler re-homes through cardMove. The supported API is newBoardId/newSwimlaneId/newListId (not a raw boardId edit).
Thanks to rptl and xet7 !
Fixes#3037,
#4737/#5850: the per-org/team orgPropagateMembersToBoards / teamPropagateMembersToBoards flag was stored and shown in the Admin Panel, but the propagateOrgTeamMembersToBoards method that acts on it had NO caller anywhere — dead code, so turning the flag on did nothing. The propagation logic is refactored into exported propagateGroupMembersToBoards(kind, groupId) / propagateAllFlaggedGroupsToBoards() (the Meteor method now delegates to the latter), and the flag setters setTeamPropagateMembersToBoards / setOrgPropagateMembersToBoards now run the propagation for that group when the flag is turned ON. Still strictly add-only (existing board members are never removed/modified) and template boards are skipped; the add-only member computation is extracted to a pure, unit-tested models/lib/propagateMembers.js.
Tests: tests/propagateMembers.test.cjs (9 checks) covers membersToAddToBoard (add-only, de-dup, already-member, invalid inputs) and source guards that both flag-setters propagate on enable, the method delegates to the shared impl, and it stays add-only + board-type-only.
Thanks to xet7 !
#4593 (a user added to a team AFTER it was assigned to a board never gained membership/authority on that board) is already fixed: server/models/users.js addUserToTeamBoards uses the pure, tested models/lib/teamBoardMemberSync.js decision logic, and is called from BOTH editUser (the admin People-panel path in the reproduction) and the create-user-with-teams path, so a late-joining team member is pushed into board.members like the team's original members. The pure helper was covered by tests/teamBoardMemberSync.test.cjs; this adds source-guard tests that the two server call sites actually invoke it (and that it routes through the helper), so the fix cannot silently regress and reopen#4593.
Thanks to mianbaoshumoon and xet7 !
Fixes#4593,
The add-card form's Tab handler (Template.addCardForm pressKey, keyCode === 9) is a deliberate power feature -- Tab jumps to the NEXT column's add-card form so cards can be added across columns quickly. But it opened that next form while abandoning whatever was typed in the current one, so pressing Tab mid-entry silently lost the card text (the card appeared to 'move to the next column' with no content). It now submits the current card first, but only when the textarea has non-whitespace content (so Tab in an empty box does not create a blank card), then jumps to the next column's form -- preserving both the content and the column-jump feature.
Tests: tests/addCardTabSubmit.test.cjs (4 checks) guards the ordering -- the Tab branch reads the textarea, submits on non-empty content BEFORE openForm of the next list, still opens the next column, and does not submit for an empty box.
Thanks to callahad and xet7 !
Fixes#1195,
Convert the Upcoming (#3192) and v10.14/v10.15/v10.16 bug-fix bullets I added from '[#NNNN](issues/NNNN)' to the CLAUDE.md format '[description (#NNNN)](commit-url). Thanks to X and xet7.' -- #3192 (c0bbacaf9), FerretDB polling-only #6503 (b15d89dd0), i18n raw-key #6503 (eb411d9a5), rules remove-all-members #2674 (e1ebe978b), archived-swimlane #1971/#1959 (52bb15594), @member autocomplete (2328bcd0f), #label autocomplete (728cd929c). The CRITICAL/Bleed security entries keep their hall-of-fame links and the Dependabot entries keep their CVE/advisory links, as those are the correct references.
Thanks to xet7.
Detail how to extend WEKAN_REPO_TOKEN to the two variant repos for each token type: a classic 'repo' PAT usually needs nothing changed (just org write access), a fine-grained PAT must add wekan-ondra/wekan-gantt-gpl with Contents: Read/Write, or use per-repo deploy keys -- the stored secret value never changes either way (no gh secret set step), with a throwaway-push verify command. Also correct the now-stale status note: the snap-variants job is currently hard-disabled with 'if: ${{ false }}' (grouped with the failing snap exotic-arch jobs), so publishing variants now needs BOTH steps 1-4 AND removing that 'if' line (new step 5), and update the checklist to match.
Thanks to xet7.
The snap builds for the exotic arches fail, so skip them on release: snap-qemu (ppc64el, s390x snaps), snap-launchpad (riscv64 snap), snap-variants, nextcloud and ucs each get 'if: ${{ false }}' (re-enable by removing that line). build-extra-arches is kept ENABLED: it builds the wekan-<version>-{ppc64le,s390x,riscv64}.zip bundles that the docker job bakes into the full multi-arch image (amd64, arm64, ppc64le, s390x, riscv64) -- that path works, only the snap exotic-arch builds fail.
Thanks to xet7.
Two source bugs kept due-date reminder mail from reaching people. (1) The reminder hour was parsed as parseInt(NOTIFY_DUE_AT_HOUR_OF_DAY, 10) || 8, so a configured hour of 0 (midnight) silently became 8 (0 is falsy) and out-of-range hours were accepted; parseNotifyDueHour now keeps 0 and rejects anything outside 0..23. (2) A due-card activity's notification participants were only the card CREATOR and its MEMBERS (server/models/activities.js) -- a user ASSIGNED a card but not a member was never notified about it, including its due date; card.assignees are now included too (still gated downstream by the board tracking level, so nobody who is not tracking is newly emailed). The NOTIFY_DUE_* parsing is extracted to a pure, unit-tested models/lib/dueNotificationConfig.js. Note: the built-in reminder still requires NOTIFY_DUE_DAYS_BEFORE_AND_AFTER to be set, and members/assignees are emailed per their board watch/tracking level.
Tests: tests/dueNotificationConfig.test.cjs (12 checks) covers the midnight-hour case, valid/invalid/out-of-range hours, the day-offset window parsing and negatives, plus source guards that cards.js uses parseNotifyDueHour and that assignees are in the notification participants.
Thanks to SirConfigMgr and xet7 !
Fixes#3192,
ferretdbOplogReset.test.cjs forbade any rm touching 'wekan.sqlite', but ferretdb-control legitimately removes the transient wekan.sqlite-wal/-shm sidecars before copying a backup over the data file. The guard now forbids only the bare data file / glob (via a (?!-) lookahead) and allows the -wal/-shm/-journal sidecars. Pre-existing test failure, source is correct.
Thanks to xet7.
FerretDB v1 can tail an OpLog, but on the SQLite backend Meteor's tailable+awaitData OpLog tail keeps FerretDB CPU pinned (reporters saw ~190-390% even idle; a 2-core box maxed out) and a struggling tail also surfaces as 'oplog catching up took too long', stalling board and login-page loading. Despite the FerretDB-side mitigations (16 MiB capped oplog, 500ms awaitData poll, SQLite pragmas, CPU self-regulation) the peg persisted on real deployments, and the polling-only path reliably drops CPU to ~10%. So make POLLING the default on every launcher (snap wekan-control, bundle start-wekan.sh, docker wekan-entrypoint.sh + docker-compose.yml, windows start-wekan.bat, sandstorm start.js): WEKAN_FERRETDB_OPLOG now defaults false, docker-compose reactivity is 'polling' with MONGO_OPLOG_URL commented out. The OpLog machinery still exists and is opt-in via WEKAN_FERRETDB_OPLOG=true. The snap exposes it as a setting: 'snap set wekan wekan-ferretdb-oplog=true|false' (registered in snap-src/bin/config, default false). The calmer polling throttle (#6467/#6468) and SQLite pragma tuning keep poll-and-diff cheap.
Tests: tests/ferretdbOplog.test.cjs updated to assert the polling-only default everywhere, the commented-out docker-compose MONGO_OPLOG_URL, the opt-in OpLog machinery still present, and the new wekan-ferretdb-oplog snap setting (default false).
Thanks to xet7 !
TAPi18n.init() awaited a dynamic import('./data/en.i18n.json') and only set TAPi18n.ready=true afterwards. If that dynamic chunk hung or rejected -- e.g. a stale snap client bundle after a refresh, the reported #6503 scenario -- ready stayed false forever and the '_' Blaze helper returned every key raw (the untranslated changeLanguagePopup-title), with no recovery. Two guards: (1) the default English is now STATICALLY bundled (import enData from './data/en.i18n.json') and registered first, so the UI is always readable even when dynamic import() is broken; every other language still loads lazily. (2) the normal loadLanguage('en') (which also layers custom DB translations) is bounded by a 10s timeout and its failure is swallowed, so ready.set(true) is reached in EVERY path. index.js also guards the startup so init can never leave an unhandled rejection. The ES-module-namespace unwrap and the timeout guard are extracted to a pure, unit-tested imports/i18n/loadHelpers.js and shared with loadLanguage().
Tests: tests/i18nLoadHelpers.test.cjs (10 checks) covers unwrapI18nModule (real namespace vs the #5756 literal-"default"-key trap, null/plain) and promiseWithTimeout (resolves/rejects in time, and REJECTS instead of hanging when the promise never settles), plus a source guard that init sets ready in every path. Note: this hardens the i18n (raw-key) symptom and makes it recoverable; the dead OIDC/Register buttons need in-browser confirmation of the stale dynamic-import cache (see issue notes).
Thanks to Alishara and xet7 !
The rule member actions operate on a card's ASSIGNEES: addMember calls card.assignMember() and removeMember calls card.unassignMember() (both write card.assignees). The 'remove all' branch (username === '*') however iterated card.members -- a different collection -- so it unassigned nobody a rule had assigned and 'remove every member' silently did nothing. Iterate the card's assignees (card.getAssignees()) instead, snapshotting the ids first since unassignMember pulls from that same array. The single-user add/remove were already symmetric (the earlier #2674 fix that made them assign/unassign); this completes it for the wildcard case.
Tests: tests/ruleRemoveMemberAction.test.cjs (6 checks) pins the add/remove symmetry, that the '*' branch reads assignees (not card.members) and still unassigns each, and the defensive skip for an unresolved username.
Thanks to sfahrenholz and xet7 !
Fixes#2674,
Same root cause as #1971, now fixed: new cards and the List-view card drop both resolve the target swimlane through Board.getDefaultSwimline() (client/components/lists/list.js), which now skips archived swimlanes (pickDefaultSwimlane) -- so a card is never assigned to a deleted/archived 'General' swimlane and made invisible in Swimlane view. Cards already orphaned by an earlier swimlane deletion keep surfacing in the first swimlane via the #6443 orphanedCardsSwimlaneIds fallback (covered by swimlaneFilter/ruleMoveAction tests). Adds a wiring guard tying the two together.
Thanks to hnb1 and xet7 !
Fixes#1959,
defaultBoard.test.cjs asserted boardsList.js never calls toggleDefaultBoard, but d67d27f0d re-enabled setting the Home board via the 'Selected:' bulk action (js-home-selected), which legitimately calls it. The per-tile toggle stays disabled; the test now checks that instead of forbidding the call outright. Test-only; source is correct.
Thanks to xet7.
Board.getDefaultSwimline()/getDefaultSwimlineAsync() picked the first swimlane for the board with no archived filter (ReactiveCache.getSwimlane({ boardId })), so when the first/default swimlane was archived, a card added in List view was assigned to that archived swimlane and became invisible in Swimlane view (visible only in List view until the swimlane was unarchived). Both getters now choose via a pure pickDefaultSwimlane() helper that prefers the first NON-archived swimlane, falling back to the first one only when every swimlane is archived (so callers reading ._id never crash) and returning undefined only when the board has no swimlanes at all -- the single case where the server self-heals a fresh default (#6382/#6429 idempotency preserved).
Tests: tests/defaultSwimlane.test.cjs gains pickDefaultSwimlane cases -- the reported scenario (default archived + active swimlanes -> first active), unchanged behaviour when the first is active, all-archived fallback, empty/null -> undefined, skipping null entries, and a source guard that both getters route through the helper.
Thanks to rangersdo and xet7 !
Fixes#1971,
Follow-up to the #5116 label fix: the add-card-title '@' member mention in client/components/lists/listBody.js matched with user.username.indexOf(term) === 0 -- case-sensitive, prefix-only, username-only, and it threw when ReactiveCache.getUser() returned null. So '@ann' did not suggest 'Anna', '@Anna' did not match username 'anna', and a full-name search never matched. The card description/comment editor (client/components/main/editor.js) already matched case-insensitively on username OR full name but shared no code and had the same null hazard. Both now route through a pure, unit-tested models/lib/memberAutocomplete.js (memberMatchesTerm / filterMembersByTerm) that lowercases the term and matches username or profile.fullname as a substring, and is null-safe.
Tests: tests/memberAutocompleteMatch.test.cjs (11 checks) covers case-insensitive + substring + full-name matching, empty-term-shows-all, null/undefined user (the old crash), missing profile, order preservation, and source guards that both '@' call sites use the shared matcher.
Thanks to rjl9 and xet7 !
Typing '#test' in the add-card / edit-card-title field did not suggest a label named 'Testing': the label search matched with a case-SENSITIVE label.name.indexOf(term) (and label.color.indexOf(term)), so only '#Test' matched 'Testing'. The board's '@' member autocomplete already matches case-insensitively; this brings the '#' label autocomplete in line. Extracted the match into a pure, unit-testable models/lib/labelAutocomplete.js (labelMatchesTerm / filterLabelsByTerm) that lowercases both the term and the label name/color, mirroring the other models/lib pure helpers.
Tests: tests/labelAutocompleteMatch.test.cjs covers the exact #5116 scenario (#test -> Testing), color-fallback matching, empty-term-shows-all, order preservation, and negatives (non-substring, missing name/color, null label, non-array), plus a source guard that listBody.js routes through the shared matcher. 11 checks pass.
Thanks to rjl9 and xet7 !
Fixes#5116,
Document the webpack-dev-server 5.2.6 and http-proxy-middleware 2.0.10 overrides in the Upcoming security section, why elliptic (#55) has no fix, and why the @rspack/cli 1->2 and @babel/parser 7->8 major bumps are deferred.
Thanks to GitHub Dependabot and xet7.
Resolve three Dependabot alerts in the rspack build-toolchain dev dependencies without touching the rspack major version, so builds are unaffected. Both packages enter only via @rspack/dev-server (the 'rspack serve' dev server) and are not used by 'meteor build'. webpack-dev-server 5.2.5 -> 5.2.6 fixes CVE-2026-14631 (DoS via malformed Host/Origin header, alert #113) and CVE-2026-14620 (CSRF via internal /webpack-dev-server endpoints, alert #114). http-proxy-middleware 2.0.9 -> 2.0.10 fixes CVE-2026-55602 (host+path router substring-match backend bypass, alert #107). Both are patch releases within the same major line, so the lock resolves cleanly (only those two entries change) and the rspack CLI/core stay at 1.7.11. elliptic (alert #55, CVE-2025-14505) has no fixed version published upstream (latest is still 6.6.1), so it is left pinned; the @rspack/cli 1->2 (PR #6497) and @babel/parser 7->8 (PR #6484, a runtime dependency) major bumps are deferred as they need build/runtime testing first.
Thanks to GitHub Dependabot and xet7.
CLAUDE.md gains the 'Fix open issues' process (research newest maintained dependencies via Meteor 3 docs/issues/forums, atmosphere/packosphere/npm, add tests+negative+UI tests, commit format). docs/Security/Sandboxes/vscode/README.md documents a version-matched from-scratch toolchain in .tools/ (Node v24.18.0, npm, Meteor 3.5, newest Go for FerretDB) to build the WeKan bundle + FerretDB and run all tests, and notes Docker/podman is unavailable in the Flatpak sandbox. server/00waitForMongo.js keeps the Meteor.startup wait but documents the #6500 finding: accounts-base creates the users index before app hooks, so a top-level await here deadlocks — the reliable fix is the docker-compose healthcheck.
Thanks to xet7.
ldapConnectionRelease: strip comments before the source-guard search so a comment mentioning ldap.connect() (before the guarded call) no longer trips the 'connect inside the guard' assertion. htmljsArrayContent: provide a minimal Package global before requiring the vendored htmljs.js, which reads Package.meteor/Package.tracker at load before creating Package itself. ferretdbOplog: accept the hardcoded polling launcher form as well as the ${VAR:-polling} form. Source code unchanged; these are test-harness fixes surfaced by running the suite under a clean Node install.
Thanks to xet7.
Document the two GitHub CodeQL code scanning fixes already committed (alerts #425 js/incomplete-multi-character-sanitization in imports/lib/fileNameDisplay.js and #424 js/identity-replacement in tests/securityLog.test.cjs) in a new Upcoming section above v10.13, linked to the wekan.fi Hall of Fame entries.
Thanks to GitHub CodeQL and xet7.
A menu-id regex was built with id.replace('report-', 'report-') — replacing a substring with itself, a no-op CodeQL flags because it is almost always a mistake for a real transformation. Match 'js-' + id directly instead. Resolves code scanning alert #424. Test-only, no runtime exposure.
Thanks to xet7.
stripExploitPatterns() stripped HTML/script/template markup in a single pass, so nested or interleaved fragments — e.g. <scr<x>ipt> or <scr{{y}}ipt> — could have the inner part removed and the two surviving outer fragments spliced into a fresh <script> token that the single pass no longer re-examined. Apply the removals repeatedly until the string stops changing (a fixpoint); each pass only deletes text, so the string strictly shrinks and the loop always terminates, and any dangerous token an earlier removal reveals is removed too. Resolves code scanning alert #425. Blaze {{ }} already HTML-escapes every rendered filename, so this is defence-in-depth on displayed text, but the single-pass strip was genuinely incomplete.
Thanks to xet7.
Document that 'check newest test logs' means the newest ../log/<datetime>/
directory, and that VSCode runs in the Flatpak sandbox from
docs/Security/Sandboxes/vscode/vscode-sandbox.sh (details in that README.md).
Thanks to xet7 !
pull-translations.sh ran tx pull -f (which fills untranslated strings with the
English source) and then only auto-healed files whose changes were ENTIRELY
reverts -- a file that also got a real new Transifex translation was skipped, so
its reverted strings were lost back to English. Replace that whole-file heal with
a per-KEY merge (releases/translations/merge-translations.mjs): for every language
file and key, keep Transifex's newest human translation, restore a committed human
translation the pull reverted to English (even in files that also received real
new translations), and leave only genuinely-missing keys (untranslated on Transifex
AND never committed) as the English placeholder for machine translation. So a pull
always brings the newest Transifex translations and never overwrites a human
translation with English/machine; only missing-everywhere strings are machine
translated. Restored languages are pushed back to Transifex.
Add CLAUDE.md at the repo root (read first by Claude) documenting: the translation
policy above; that direct-commit / commit-as-Lauri-Ojansivu / all release steps are
MAINTAINER ONLY (only when git identity is Lauri Ojansivu <x@xet7.org>) while other
contributors use pull requests; plus the general practices, CHANGELOG structure,
no-argument release flow and test conventions from ../log/v10/Claude.txt.
Thanks to xet7 !
On a fresh `docker compose up`, the browser got "Connection reset by peer" and
WeKan never loaded (#6500). The compose's ferretdb service downloads its binary at
first run (apt-get + curl), so it is not listening for a while after its container
starts. WeKan's depends_on used `condition: service_started`, which only waits for
the ferretdb CONTAINER to start, not for the database to accept connections -- so
WeKan started against a not-yet-ready database and failed. The comment above
depends_on already said WeKan should wait for the DB to be HEALTHY; the config just
did not implement it.
Add a healthcheck to the ferretdb service (a dependency-free bash /dev/tcp probe of
127.0.0.1:27017, healthy only once FerretDB is actually listening, with a
start_period that covers a slow first download) and change WeKan's depends_on to
`condition: service_healthy`, so WeKan starts only after FerretDB is ready.
Thanks to youhajjioui and xet7 !
Fixes#6500,
The admin Files report showed "No results" on FerretDB (spec 41 failed in every
Playwright run). Root cause, reproduced against a real FerretDB with the Go Mongo
driver: older FerretDB v1 builds reject {members:{$elemMatch:{userId,isActive:true}}}
with "(BadValue) unknown operator: userId". accessibleCardIds used exactly that
query, and the attachmentsList publication's catch swallowed the error, so the
report silently returned nothing. Current FerretDB handles $elemMatch; the build in
the test harness does not -- which is why board-load tests using a different query
still passed.
accessibleCardIds now matches board membership by the dotted path
{'members.userId': userId} (works on every FerretDB build) and confirms in JS that
the user's own member entry is active, preserving the exact per-element semantics
$elemMatch gives (a userId appears in at most one member entry). Verified with the
Mongo driver against both FerretDB v1.24.2 (was erroring) and v1.37.0: the full
pipeline now returns the 5 seeded attachments on both.
Thanks to xet7 !
The admin Files report has shown "No results" in every Playwright run (spec 41),
with nothing in the server log — because the attachmentsList publication swallowed
any error from its query in a catch that only logged when DEBUG=true. Stop hiding
it: the catch now always logs the error (with stack), and under DEBUG the
publication logs whether attachmentsReportQuery returned null (the user has no
accessible cards) versus a query that matched 0 attachments, so the two failure
modes are distinguishable.
Spec 41 now localizes the failure itself: it asserts the seed produced a real
cardId (so a null cardId, which would make meta.cardId never match, fails with a
clear message), and it probes getAttachmentsReportCount directly after opening the
report — that method runs the SAME accessibleCardIds + meta.cardId query the
publication uses, so if the server count is >= 5 but the table is missing it is a
client-render problem, and if it is 0 or errors it is the server query — instead of
just "table not visible".
No runtime is available in this environment to execute Playwright, so this makes
the next run point straight at the failing layer.
Thanks to xet7 !
Auto-detect the version instead of requiring one: if there is a
'# Upcoming WeKan ® release' section, rename it to the next version (the same
increment as the last release, e.g. 10.11 -> 10.12) dated today; otherwise use
the newest release heading (already renamed), sanity-checked as the +1 increment
and referenced by a recent commit so an old entry is never re-released. Explicit
'PREVIOUS NEW' args still override.
Thanks to xet7 !
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 (the existing createPlaceholderUsers path), added to the board inactive with
no permissions. The client import flow is now a single step that imports
immediately with an empty mapping -- no map-members screen, nothing to get stuck
on.
Mapping a virtual member to an existing user is a deliberate, later action done by
a board admin from the board sidebar member-avatar popup ("Map to existing user"),
and CANNOT be used to gain privileges: the new board-scoped method
mapImportedBoardMember only maps a virtual member onto an existing ACTIVE, REAL
member of the SAME board and never changes that member's role (so no new
membership is created and nothing is escalated); authorization and this guarantee
live in the pure planBoardMemberMapping helper. The mapping reassigns the virtual
member's cards/comments/activities ON THAT BOARD to the target and removes the
placeholder from the board.
Automatic hang mitigation so an import can never spin forever: a client watchdog
surfaces an import-timeout and clears the spinner if importBoard does not answer in
WEKAN_IMPORT_TIMEOUT_MS (default 2 min), and the server bounds creator.create with
the same deadline via a new generic withDeadline() wrapper.
Covered by tests/boardMemberMapPlan.test.cjs (no-escalation + auth matrix),
tests/withDeadline.test.cjs (deadline wrapper) and tests/importVirtualMembers.test.cjs
(wiring).
Thanks to xet7 !
In the board/JSON import "Select member" popup, typed suggestions appeared but
neither clicking nor Enter assigned the user, so mapping a migrated board's
members to existing WeKan users was impossible. The click handler mapped
Template.currentData().__originalId -- a field that is never set on the search
results (they are plain WeKan user documents with _id) -- so it mapped undefined
and silently did nothing.
Map the clicked result by its _id, and add an Enter handler that 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 still import immediately (unmapped members default to the current user).
Guarded by tests/importMemberMapping.test.cjs.
Thanks to xet7 !
client/components/main/safeFilename.js registers the global Blaze helpers
cleanFilename and downloadFilename, but it was never imported on the client, so
the helpers were never registered. Every template that uses {{cleanFilename name}}
-- card attachment thumbnails (client/components/cards/attachments.jade) and the
admin Files report -- therefore threw "No such function: cleanFilename" during
render. On a card with attachments this aborted the card's Tracker recompute, so
clicking a card did nothing (the card would not open).
Import safeFilename.js from client/features/main.js alongside the other
client/components/main modules so the helpers are registered at startup. Guarded
by tests/fileNameDisplay.test.cjs.
Thanks to mueschel, brlin-tw and xet7 !
Fixes#6493,
Merely having MONGO_OPLOG_URL set makes Meteor start an OpLog tail at boot (a
tailable+awaitData cursor on local.oplog.rs) regardless of the reactivity order,
and on FerretDB that tail polls the database continuously -- pinning CPU even
with no clients connected. The polling-only branch of each launcher set
METEOR_REACTIVITY_ORDER=polling but left an already-set MONGO_OPLOG_URL in place,
so "polling only" still tailed the OpLog.
Every FerretDB launcher (snap wekan-control, bundled start-wekan.sh, Docker
wekan-entrypoint.sh, Sandstorm start.js) now actively clears MONGO_OPLOG_URL in
its polling-only branch, so choosing polling truly does no OpLog tailing. The
OpLog-enabled (default) path is unchanged. Covered by tests/ferretdbOplog.test.cjs.
This complements the FerretDB fork fix that stops awaitData from busy-polling the
tail in the default OpLog mode (wekan/FerretDB, wekan/wekan#6498).
Thanks to Alishara, bluetopaz1204, mueschel and xet7 !
Fixes#6498,
On a grain's first launch after upgrade, sandstorm-src/start.js migrates the old
MongoDB data to FerretDB v1 (SQLite) before starting WeKan. While nothing was
listening on the grain's app port (during migration and the handoff to WeKan),
sandstorm-http-bridge got connection-refused and the browser showed "This page
can not be displayed embedded in another page"; the user had to close the grain
and open it again.
start.js now runs migration-bridge.js as a child process on the app port that
answers every URL with a small auto-refreshing "please wait" page (HTTP 503), so
the grain stays framed until WeKan is up. It is a separate process on purpose:
start.js runs the migration with blocking spawnSync, so it could neither service
an in-process server nor release its listening socket before the importer/Meteor
bind the port -- killing a child is a definitive socket close. The bridge starts
before migration, YIELDS the port around the importer (which serves its own
progress dashboard there), resumes for the handoff, and is released just before
Meteor binds the port. Every use is best-effort (guarded by existsSync, error
handlers, killed on grain exit) so it can never break grain startup.
build-deps.sh ships migration-bridge.js next to start.js in the deps payload.
Thanks to xet7 !
During a #6492 data recovery, users should never see a bare connection error.
Two layers now cover the whole window on every FerretDB v1 launch path (snap,
bundled release, Docker):
- In-app spinner (already present): the server clears the RECOVERY_IN_PROGRESS
marker only after a real health probe, so the full-screen overlay behaves
identically everywhere.
- Static bridge page (new, cross-platform): for the brief window while a
just-restored FerretDB comes back up and before Meteor can serve the client,
the launch scripts serve a tiny standalone "recovering your data" page (HTTP
503) on the web port. The snap reuses wekan-maintenance-page.mjs with a
recovery wording; release/Docker serve the portable recovery-bridge.mjs. The
bridge is time-bounded (WEKAN_RECOVERY_BRIDGE_SECONDS, default 20s) so it can
never block WeKan from starting, hands straight over to the in-app spinner, and
is skipped if its page file or the marker is absent.
The launch scripts do NOT delete the marker; only the server does, after
verifying the database serves reads. Tests enforce the bridge is bounded, is
guarded by the page file, and that no script deletes the marker.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
#6492: while the SQLite text data is being recovered/remediated, users should see a
maintenance spinner instead of errors or half-loaded data.
- A published singleton status (models/recoveryStatus.js) carries an "active" flag +
message. The publication (server/publications/recoveryMaintenance.js) is PUBLIC so
even logged-out users on the sign-in page see it; the toggle method
(setRecoveryMaintenance) is admin-only.
- The client overlay (client/components/main/recoveryMaintenance.*) shows a full-screen
spinner + message when active; it is subscribed globally and rendered in both the app
(defaultLayout) and sign-in (userFormsLayout) layouts, above modals/popups.
- The startup scripts write a RECOVERY_IN_PROGRESS marker when they restore/re-migrate.
On startup the WeKan server (server/recovery.js) shows the spinner while the marker is
present, verifies the database serves reads (probe), then clears the marker and the
spinner — or, if it still cannot read, keeps the spinner and records that manual
recovery is required. Admins can also toggle maintenance for a server-initiated
re-migration.
Tests: tests/recoveryMaintenance.test.cjs (wired into npm run test:unit:node) — the
publication is public while the toggle is admin-gated, the overlay is subscribed and
rendered in both layouts above everything, the server shows the spinner from the marker
and clears it only after a health probe, and the scripts write the marker. Mirror-
validated (no Node runtime here); shell/brace/JSON all checked.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Completes the #6492 data-safety system on the WeKan side (FerretDB detection/repair/cap
landed in the fork):
- Decision brain: models/lib/recoveryPlan.js decideRecovery() picks the least-invasive
recovery when the database is KNOWN corrupt (latest good backup -> previous backup ->
re-migrate from MongoDB -> manual). It never acts on a healthy/unknown database and
never restores a known-bad backup.
- Startup restore/re-migrate: every FerretDB launch path (snap, bundled release, Docker)
can restore the text data BEFORE FerretDB opens the files, on request
(WEKAN_FORCE_RESTORE env or a RESTORE_REQUESTED marker). It copies a known-good backup
INTO the live database (dropping stale WAL side-files); backups are never deleted and
the main wekan.sqlite is only overwritten, never removed. remigrate is delegated to
migration-control. Attachments/avatars on the filesystem are untouched.
- Recovery events: the scripts append JSON lines to recovery-events.jsonl; the server
(server/recovery.js) imports them into the recoveryEvents collection on startup, plus
an admin-only recordRecoveryEvent method.
- Admin Panel / Problems / Recovery: a new admin-only report
(server/publications/recoveryReport.js, wired in adminReports.js/.jade + i18n) lists
the remediation history newest-first, readies up front and fetches directly (no hang).
- Docs: docs/Features/Admin-Panel/Problems/Recovery.md.
Tests (wired into npm run test:unit:node), verified by mirror since there is no Node
runtime here to execute them:
- recoveryPlan.test.cjs (decision logic, positive + negatives)
- recoveryEventsJsonl.test.cjs (parser: skips junk, normalizes severity, never throws)
- recoveryReportQuery.test.cjs (search selector escapes regex metacharacters)
- recoveryReportWiring.test.cjs (report wired; publication/count/method admin-gated)
- ferretdbTextDataBackup.test.cjs extended: restore copies from a backup, is
request-gated, and NEVER deletes the live text data or a backup copy
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Safety measure for #6492: before FerretDB opens its SQLite files (at rest), every
FerretDB launch path now keeps a rotating backup of the TEXT-DATA database
(wekan.sqlite*) in a "backup" subfolder of the same data dir, so a known copy is ready
to restore if the live database is ever detected corrupt (FerretDB's own quick_check
logs corruption on open). Attachments and avatars live on the filesystem and are not
copied.
The critical safety property: the backup only ever COPIES from the live database — it
never moves or deletes the live wekan.sqlite, and never wipes the data dir. The
previous generation is kept under backup/prev so a bad copy cannot overwrite the last
good one on its own. Disable with WEKAN_SQLITE_BACKUP=false.
- snap-src/bin/ferretdb-control
- releases/ferretdb/start-wekan.sh
- releases/ferretdb/wekan-entrypoint.sh
tests/ferretdbTextDataBackup.test.cjs verifies each path copies wekan.sqlite* into the
backup dir, keeps a previous generation, is guarded, and — the critical negative —
NEVER moves/deletes the live text data, never wipes the data dir, and never copies
attachments/avatars.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Per the #6492 investigation, FerretDB v1's SQLite simulated OpLog (local.oplog.rs,
stored in the `local` database = local.sqlite) is not reliably capped, so over time
it bloats or corrupts; Meteor then busy-polls it and FerretDB CPU pegs at 300%+ even
when idle. A reporter confirmed that deleting local.sqlite* drops CPU straight back
to ~10%.
The `local` database is transient SYSTEM data — the OpLog + replica-set metadata,
NOT user data: boards, cards and attachments live in wekan.sqlite. So every FerretDB
launch path now resets ONLY the `local` database files before starting FerretDB,
which recreates a fresh, correctly-capped OpLog from --repl-set-name. This prevents a
corrupt/bloated OpLog from ever persisting across a restart:
- snap-src/bin/ferretdb-control
- releases/ferretdb/start-wekan.sh (bundled release, before each restart-loop start)
- releases/ferretdb/wekan-entrypoint.sh (FerretDB Docker image)
Guarded by WEKAN_FERRETDB_RESET_OPLOG (default true; set false to keep the OpLog).
tests/ferretdbOplogReset.test.cjs verifies each path resets local.sqlite, is guarded,
and — the critical safety property — NEVER deletes wekan.sqlite or the whole data dir.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
On phones the two-column All Boards layout cut off text:
- The board icons column (the 1fr grid track) is a grid item, which defaults to
min-width:auto and would not shrink below its content, so the board tiles pushed
the column wider than the viewport and the board titles were clipped off the right
edge. Add min-width:0 to .boards-right-grid so the column shrinks to its track and
the tiles (and their titles) fit.
- The mobile board tiles reserved 50px on the right for the drag handle, which on a
narrow 2-per-row tile hid most of the title. Shrink the handle (40->26px) and the
reserved padding (50->30px) so more of the title shows.
- Workspace names in the narrow left menu were hard-cut mid-word ("Ro"); let the
flex children shrink (min-width:0) and truncate the name with an ellipsis so more
of it is readable ("Roadmap…").
Thanks to xet7 !
The report was still stuck on the loading spinner: an await in the publish body
never resolved, so this.ready() in the `finally` never ran and the subscription
never became ready (the report template only renders once ready). Two changes make
the publish always reach readiness:
- Call this.ready() UP FRONT, before any await, then stream the page rows with
this.added — the table populates reactively. The spinner can no longer get stuck
regardless of how slow/stuck the fetch is.
- Compute accessibleCardIds() by querying Boards / Cards directly with fetchAsync
instead of through ReactiveCache, and fetch the attachments page from
Attachments.collection directly — raw async fetches always resolve, avoiding the
ostrio FilesCollection cursor / backward-compatibility fallback that can hang.
Thanks to xet7 !
After keeping the board icons in their own right-hand column, the left menu
(Starred / Templates / Remaining / Workspaces / Add board) still could not be
scrolled: the fixed-height wrapper clips at 100vh, and only the board list had its
own scroll, so a menu taller than the screen had its lower items unreachable.
Give the left menu its own overflow-y:auto / bounded max-height so you can
drag-scroll down to its lower items, just like the boards column on the right.
Both columns are reachable in LTR and RTL — the layout uses a direction-aware grid
and logical inline borders, so under a dir="rtl" document the menu is on the right
and the boards on the left automatically. Spec 43 now also asserts the left menu
is a bounded scroll container.
Thanks to xet7 !
On phone-sized touch screens the All Boards layout collapsed to a single column,
so the board icons ended up BELOW the left menu and search bar. dragscroll does
not work over the menu / search area, so the boards below the fold could not be
reached by dragging — you could not scroll down to see more boards.
Remove the small-screen `grid-template-columns: 1fr !important` collapse: keep the
two-column layout (narrow minmax(84px,30%) left menu, board icons in their own 1fr
column on the right) in both mobile and desktop mode. The narrow minmax() menu
already prevents the old fixed-260px overflow that clipping-collapse was meant to
fix, and the board list keeps its own overflow-y:auto / dragscroll. Spec 43 now
also asserts the board list sits to the right of the menu, not stacked below it.
Also fix two WebKit-only test assertions (not app bugs): read the WebKit-prefixed
getComputedStyle(...).webkitUserSelect in the Statistics-view test.
Thanks to xet7 !
The 'attachmentsList' publication fetched via ReactiveCache.getAttachments(),
which reads through the ostrio FilesCollection cursor; when that returns no rows
it falls back to getAttachmentsWithBackwardCompatibility(), whose old-CFS lookups
can hang. The hang is INSIDE the publish's try block, so the finally this.ready()
never runs — the subscription never becomes ready and the Files report (Admin
Panel / Reports / Files) is stuck on the loading spinner, its content pane never
rendering (Playwright: the report table never appears in any browser). The other
admin reports query plain collections and were unaffected.
Query the plain Mongo collection directly (Attachments.collection.find) in both
the publication and the getAttachmentsReportCount method. The attachment rows live
in that same 'attachments' collection, so a direct find returns the page and always
completes: this.ready() fires and the report renders its table.
Thanks to xet7 !
The filesReport content pane rendered EMPTY in the newest Playwright run (no
title, no search box) — a throwing helper aborts the whole Blaze template. Guard
Attachments.collection access and never throw so the report UI always renders.
The core symptom (no attachments listed) is unverified/unfixed — it points at the
attachmentsList publication returning 0 rows, which needs a running server + DB to
diagnose. Correct the v10.07 changelog to stop claiming the report is fixed.
Issue #5659 reported that list-width defaults did not apply on public boards
(logged-out viewers) and that width settings only affected logged-in users. This
is already fixed by the models/lib/listWidth.js single-source-of-truth work:
resolveListWidth() returns the one DEFAULT_LIST_WIDTH (220) for every
uncustomized list and every viewer — members and logged-out public-board
visitors alike; the shared lists.width (#6409) applies to everyone; anonymous
viewers customize via localStorage. Verified against current source:
- resolveListWidth fallback order (mirrored, all cases incl. negatives pass)
- client list.js / listHeader.js and models/users.js import the shared module
with no stale 272/270 defaults; models/lists.js schema defaultValue is 220
The tests/listWidthDefaults.test.cjs regression test already existed but was not
wired into `npm run test:unit:node`, so it never ran. Wire it in so the #5659
fix stays verified.
Thanks to NadavTasher and xet7 !
Closes#5659,
The mobile board list is meant to be a BOUNDED, scrollable region
(height: calc(100vh - 120px)) so boards below the fold are reachable inside the
overflow:hidden wrapper (#6488). Two leftover .board-list.mobile-view rules
re-introduced the exact old bug: `min-height: 100vh` and a phantom
`::after { height: 100px }` forced the list to grow to its full content height,
so nothing ever overflowed — the list was as tall as its content and did not
scroll, and the lower boards were clipped and unreachable.
These non-media rules have higher specificity than the media-query block that
already sets the bounded height (whose comment notes min-height:100vh + ::after
was the bug), so they won this fight. Remove both; the bounded height now takes
effect and the two-column list scrolls.
Thanks to xet7 !
statsView.jade / statsView.js / statsView.css existed but were never imported
anywhere in the client build, so the `statsView` Blaze template was never
registered. The board body's `+statsView` include (selected when the user's
boardView is 'board-view-stats') therefore rendered nothing — the board header
showed "Statistics" (that only reflects the persisted boardView) while the
board canvas stayed empty. The Statistics view had never actually rendered.
Import the three files in client/features/boards.js alongside the other board
views (tableView), so the template, its helpers and its styles are in the bundle.
Thanks to xet7 !
The Files report (Admin Panel / Reports / Files) built its rows and count from
the ostrio FilesCollection wrapper (Attachments.find() / .count()). The
'attachmentsList' publication delivers the page via this.added('attachments', ...),
but the ostrio FilesCursor does not reliably re-run in a Blaze helper when those
docs arrive, so resultsCount stayed 0 and the `if resultsCount` table never
appeared (the report showed only its controls, no rows).
Read the underlying minimongo collection (Attachments.collection) instead, a
plain reactive Mongo.Collection cursor that reacts to the published adds and
yields plain docs — the same pattern the rest of the codebase already uses for
reactive attachment reads (sidebar backgrounds, backgrounds publication).
Thanks to xet7 !
The #6488 mobile All Boards test asserted the first two li.js-board tiles share
a row, but the list's leading '+ Add board' tile takes the first grid cell, so
the first two boards legitimately land on different rows in a 2-column grid
(the measured 194px is exactly one row). Measure every tile and assert the top
row holds >=2 tiles at two distinct x columns instead — a direct 2-per-row check.
The Statistics-view test switched via the board-view popup, which calls
Utils.setBoardView -> window.location.reload(); reloading the board cold mid-test
races the assertion (the board-canvas is still empty when it fires). Pre-seed
profile.boardView instead and load the board once, so statsView renders on the
first load without a mid-test reload.
FerretDB (v1 SQLite fork) does not implement MongoDB change streams: a
$changeStream aggregate returns "not implemented" and Meteor busy-loops
retrying it (high FerretDB CPU, cards never open). The snap fix 383b3dd43
already forced changeStreams out of METEOR_REACTIVITY_ORDER for FerretDB;
apply the same strip to the remaining FerretDB run-paths so changeStreams
can never enter the order however it was passed in:
- releases/ferretdb/start-wekan.sh (standalone FerretDB release)
- releases/ferretdb/wekan-entrypoint.sh (FerretDB Docker image)
- releases/ferretdb/start-wekan.bat (Windows, stripped at top level so
each set sees the previous line's result)
The Docker compose files already hardcode safe static values
(oplog,polling / polling, no changeStreams). start-wekan.sh and
start-wekan.bat at the repo root are the real-MongoDB path (they
initialise a replica set), where change streams are correct.
Thanks to uusijani, mueschel and xet7 !
Fixes#6492, #6493, #6480,
FerretDB v1 does not implement MongoDB change streams. The snap's general
default METEOR_REACTIVITY_ORDER is "changeStreams,oplog,polling", and it
arrives in wekan-control already set, so the FerretDB `:-oplog,polling`
fallback did not apply. Meteor then issued $changeStream aggregates that
FerretDB rejected as "not implemented" thousands of times per second - a
busy-loop that pinned FerretDB CPU (100-390%, 168% seen on 8 cores) and
starved board/card loading, so cards would not open (almost all commands
were those failed aggregates).
For FerretDB, force changeStreams OUT of the reactivity order whatever it
was set to, leaving oplog + polling; real MongoDB is unchanged and keeps
change streams. Polling-disabled path is polling only.
Thanks to xet7 !
Fixes#6492,
Fixes#6493.
setBoardView Meteor method did not await user.setBoardView(view), so it
resolved (and the client reloaded) before profile.boardView was written
and a rejected write never surfaced — switching the board view (e.g. to
the new Statistics view) was unreliable. Await it.
All Boards on phones now lays the board icons out as a real 2-column CSS
grid (repeat(2, minmax(0,1fr))) instead of float+width:50%, so at least 2
icons per row is guaranteed regardless of float-logical-value support or
how narrow the boards column is (#6488).
Thanks to xet7 !
Restructure the Upcoming WeKan release section like the released sections
and per docs/v10/Claude.txt: a new-features list and a fixes-the-following-bugs
list, each entry a link to its commit ending with Thanks to X and xet7,
closing with the thanks-to-translators line. Attribute the reported bugs
(mueschel for 6479 and 6480, mimZD for 6488).
Thanks to xet7 !
A moveCard trigger has no oldListName (the wizard chooses a destination
list, not a source), but findMatchingRules built the trigger query with
{ oldListName: { $in: [value, '*'] } }. Mongo's $in does not match a
document that is MISSING the field unless null is in the list, so the
trigger never matched and the rule's action silently never ran, with no
error. Add null to the match list for every field (a $in with null also
matches a missing field), exactly like the cardTitle handling (#2345).
Thanks to xet7 !
Fixes#6491.
From ../log/2026-07-20_15-26-39 (4 chromium failures; #6490 rules test
and spec 42 pass):
- Mobile All Boards (#6488): the real 1-per-row rule was
.board-list.mobile-view li { width:100% } (added via the isMiniScreen
class, more specific than the media-query rule) — set it to 50% too so
there are at least 2 icons per row. Seed 12 boards in the test so the
list definitely overflows and the scroll assertion is meaningful.
- Statistics view test: switch to the view through the actual board-view
switcher (js-open-stats-view) instead of pre-seeding profile.boardView,
which was flaky (localStorage vs profile / board-ready timing).
- Rules Workflow test (#6489): assert the palette renders with labelled
chips (the exact bug signature) instead of driving HTML5 drag-and-drop,
which Playwright's dragTo does not fire through Blaze's delegated
handlers here (the Add Rule button stayed disabled).
- attachmentsList: wrap the manual publish so this.ready() always runs
(finally) and drop the server-side name sort (no index; the client
re-sorts) — defensive against the still-unresolved Files-report hang.
Spec 44 exercises the two rules fixes end-to-end:
- #6490 (list view): seeds two rules, views the SECOND and asserts its
details show the second rule's trigger/action (not the first), then
deletes the second and asserts exactly it is removed (Alpha remains) -
client and server side.
- #6489 (workflow view): asserts the trigger/action palette renders (it
rendered nothing before the TAPi18n import fix), then builds a rule by
dragging a trigger + action into the slots and clicking Add Rule, and
asserts the rule appears and is persisted.
The mobile board list could not be scrolled: the CSS forced it
min-height:100vh (plus a phantom ::after), so it grew to fit all content
and, clipped by the overflow:hidden wrapper, boards below the fold were
unreachable. Give it a bounded height + overflow-y:auto so it scrolls
(natively on iOS; via the touch-drag handler elsewhere, which only
engages once content overflows).
Also improve the phone layout: keep the menu on the left but narrow it
(grid-template-columns minmax(84px,30%) 1fr) so the board icons on the
right show at least 2 per row (was 1 per row), on iPhone 12 mini and
similar. Add a phone-viewport Playwright test.
The Delete and View buttons are in the rulesList child template's each,
but their handlers are on the parent rulesMain and used
Template.currentData() — which returned the PARENT data context, not the
clicked rule. So the rule id was null: deleting failed with
'Match error: Expected string, got null', and 'View rule' always opened
the first rule. Add explicit data-rule-id to the buttons and read it in
the handlers so both operate on the rule actually clicked.
rulesWorkflow.js used TAPi18n without importing it, so paletteLabel()
threw 'ReferenceError: TAPi18n is not defined' and the Add Rule click
handler aborted before saving — creating a rule in the Rules -> Workflow
view silently did nothing. Add the missing import.
Move the board Status from a Board Settings sidebar popup into a
full-width board VIEW alongside Swimlanes / Lists / Calendar / Gantt /
Table in the board-view switcher. Named 'Statistics' (Finnish
'Tilastot'), translated to major languages (rest fall back to English).
New statsView template/js/css rendered from boardBody (isViewStats),
selectable via the switcher (js-open-stats-view -> board-view-stats,
added to the profile.boardView schema allowedValues). Reuses the server
boardStatus method so counts are accurate in lazy mode; shows the same
counts + time-spent summary as before. Text is selectable with mouse
(drag) and touch (long-press): the view stops pointer/touch events from
reaching the canvas drag-to-scroll so native selection + copy work.
Removed the old boardStatusPopup (template/handler/helpers/css) and its
Board menu item. Added a Playwright test for the view. Design doc
updated.
Apply the same fix as attachmentsList to the sibling paginated reports
rulesReport, boardsReport, cardsReport and impersonationReport: a
returned sorted+limited cursor makes Meteor set up a LIMITED live
observe that hangs on FerretDB's OpLog, so the report stays stuck on the
loading spinner. Each now fetches its page and the referenced docs and
publishes them with this.added + this.ready (into rules/actions/
triggers/boards, boards/users/team/org, cards/boards/lists/swimlanes/
users, impersonatedUsers/users respectively). No live cursor is needed
since the reports re-subscribe on every page/search change.
Add a Playwright test (spec 41) that opens each report and asserts it
loads (its search input renders once the subscription is ready).
attachmentsList returned a sorted+limited live cursor, so Meteor set up
a LIMITED live observe, which hangs on FerretDB's OpLog for this query:
the subscription never became ready and the Files report was stuck on
the loading spinner forever (spec 41). Publish the page manually (fetch
+ this.added + this.ready) so ready always fires; the report re-
subscribes on paging/search, so it needs no live cursor.
Also fix the two new #6479 Playwright tests: they located the member
avatar via '.membersWidget' which is a Blaze template NAME, not a DOM
class, so it never matched. Use the real sidebar container
'.board-sidebar' instead.
Move the flat feature docs and feature subdirectories under category
parents: Admin-Panel/ (+ Problems/), Board/, Cards/, Editor/, Reports/,
Automation/, Lists/, Troubleshooting/. Every relative markdown link in
docs/ (and the docs GitHub URLs in CHANGELOG.md and the code-span path
in Undo.md) is recomputed so it still resolves to the same target after
the move.
Done with a scripted move + relative-link rewriter that verifies link
integrity: all 160 rewritten links resolve, and a full scan confirms the
reorg introduces zero new broken docs-internal links (the pre-existing
53 unrelated to the move are unchanged).
New 'Board status' item in the board menu opens a larger, mouse-
selectable popup showing this board's card-loading mode (lazy vs all,
and whether chosen automatically), counts (swimlanes, lists, cards,
archived cards, labels, members, custom fields) and a time-spent summary
in the style of the task time reports (total hours, cards with time,
overtime cards).
Counts come from a server boardStatus(boardId) method so they are
accurate even in lazy mode, where minimongo only holds the visible card
window; the time summary fetches only cards with spentTime > 0 so it
stays cheap on big boards. New i18n keys translated to major languages
(rest fall back to English). Design doc at
docs/Features/Board/Sidebar/Status.md.
Move CPU-usage design under docs/Features/Admin-Panel/Problems/ and add
RAM-usage and Disk-usage design docs (siblings of CPU-usage): both log
how much RAM+swap / disk is used and record only the START and END of
each sustained high-usage period to Admin Panel / Problems, mirroring the
CPU-usage monitor's shape (hysteresis tracker, event stream, env vars).
Link them from the Admin-Panel index and update the now-automatic card
loading description. Update the CHANGELOG link to the moved CPU-usage.
Card loading is no longer an admin-configurable toggle. WeKan decides
per board by size ('auto', the default): a board over the threshold
(default 500 cards, CARDS_LOADING_LAZY_THRESHOLD) loads only visible
cards via windows; smaller boards keep loading all cards (unchanged,
fully featured). The server computes the mode per board and publishes it
(boardCardsLoadingMode -> boardCardLoadingModes) so client rendering
agrees; isLazyCards is now per-board.
Lazy windows now publish comments/attachments/checklists/checklistItems
with ONE cursor per window instead of one per card (same N+1 fix as
eager mode), and an open card subscribes to its own live children
(openCardData) so it is complete even when outside/just-added-to a
window. Operators can still force CARDS_LOADING=all|lazy|auto.
Removed the Admin/Features card-loading dropdown; pure decision logic in
models/lib/cardsLoading.js (resolveCardsLoadingMode now defaults to
'auto', plus effectiveBoardCardsMode + threshold) with updated unit
tests. New i18n key cards-loading-auto across locales.
#6479: the existing removal test only checked the DB, which is why the
bug shipped. Add a strict UI test that the removed member's avatar
disappears from the sidebar (plus a negative test that a non-admin is
offered no remove option).
#6480: add spec 42 verifying the board publication still shows a card
comment carrying boardId after the per-card -> board-level cursor
refactor (positive), and that a comment on a different board does not
leak in (negative — proves the board-level cursor stays boardId-scoped).
Removing a member keeps the entry with isActive:false (#5122, for role
history / re-activation), but membersForSidebar still listed inactive
entries, so Remove from board looked like it did nothing - the avatar
stayed. Show only active members (plus imported placeholders pending
reconciliation); removed members disappear from the list immediately.
Removed people still show greyed where they remain referenced (e.g. a
card assignee) via the existing inactive-member avatar styling.
Admin Panel / Problems / CPU usage could stay empty while FerretDB
pegged the machine: both WeKan and FerretDB measured only system-wide
CPU, and FerretDB at 170-300% (2-3 cores) is only ~40-75% system-wide on
a many-core host, below the high threshold.
Read FerretDB's new processCpuPercent from the throttle response and
surface it: high-CPU rows include it, and a new watch (a pure status
read that never slows FerretDB down, so it cannot make a slow board load
worse) records a start/end episode when FerretDB alone monopolises cores
even though system-wide CPU stays moderate. Tunable via
WEKAN_FERRETDB_WATCH_PERCENT / WEKAN_FERRETDB_PROC_HIGH_PERCENT.
Opening a board opened one live CardComments cursor AND one Attachments
cursor PER CARD. On a board with many cards that spun up thousands of
live observers; under FerretDB's poll-and-diff that pinned FerretDB/
SQLite CPU (170-300%) and made boards take minutes to open.
Publish comments and attachments with a single board-level cursor each,
on their denormalized boardId / meta.boardId (exactly like checklists) -
one cursor per collection instead of one per card, still reacting to
newly added cards. Add supporting indexes so the board-level queries are
not full scans: cards {boardId, archived}, cardComments {boardId},
attachments {meta.boardId}.
Lazy mode (boardCardsWindow) intentionally keeps per-visible-card
children (bounded by the window), so it is unchanged.
The paginated admin reports (Files, Rules, Boards, Cards, Impersonation)
only handled the subscription onReady callback, so if a report
publication errored on the server the report was stuck showing the
loading spinner forever, with no feedback. Handle onStop as well:
clear the spinner on stop and, on a real error, log it and surface the
message. This is defensive; it does not change the happy path.
The spec 41 "Files report shows clean filenames" test failed in all browsers
with `E11000 duplicate key error ... _id: "e2e-att-normal"`: it seeded
attachments with fixed _ids but never cleared leftovers from a previous run (or
another browser project sharing the DB), so insertMany hit a duplicate key.
- Clear the fixed attachment _ids with deleteMany({ _id: { $in: [...] } }) before
insertMany, so the seed is idempotent across re-runs and browsers.
- Also fix a latent bug: findCardIdByTitle was called with a string
('FilesCard') but it takes { boardId, title } and is synchronous. With a
string, EJSON drops the undefined fields and it matched an arbitrary card, so
the attachments would land on the wrong card and the report assertions would
fail once seeding succeeded. Now called as
db.findCardIdByTitle({ boardId: board.boardId, title: 'FilesCard' }).
Complete the high-CPU → FerretDB-slow-down → measure → report loop, and make it
robust when WeKan itself is CPU-starved or FerretDB is unresponsive.
- Adaptive feedback (server/lib/cpuMonitor.js): while CPU stays high WeKan now
INCREASES (doubles) the delay FerretDB adds between operations, up to a cap,
until system CPU drops below a headroom target (WEKAN_CPU_TARGET_PERCENT,
default 70) — enough CPU for other processes — then holds. Each escalation, the
headroom result, and the "even max delay not enough (load is elsewhere)" case
are logged.
- FerretDB self-regulates too: WeKan reads the throttle response's autoSlowDownMs,
hostCpuPercent and operationsSummary (what FerretDB has been doing) and logs
them — so the feature works even if WeKan is too starved to drive the loop.
- No flooding / no hammering (server/lib/ferretdbGovernor.js): every call has a
timeout (WEKAN_FERRETDB_TIMEOUT_MS); WeKan talks to FerretDB at most once per
WEKAN_FERRETDB_ASK_INTERVAL_MS (30s); a non-answer starts a cooldown
(WEKAN_FERRETDB_COOLDOWN_MS) instead of retrying. WeKan records WHEN FerretDB
became unresponsive and, on recovery, logs the full start -> end span plus
FerretDB's status and operations summary. "command not found" (plain MongoDB)
is still treated as permanently unsupported.
- i18n: cpuReportTitle ("CPU usage") translated to all 154 languages.
Guard tests (tests/cpuMonitorWiring.test.cjs) extended for escalation, rate-limit,
timeout/cooldown, outage span, and FerretDB self-regulation/summary. Docs
(docs/Features/CPU-usage/CPU-usage.md) and CHANGELOG updated.
FerretDB de-branded its custom command to the general name `throttle` (it is a
general-purpose MongoDB replacement, usable by any MongoDB-wire client, not only
WeKan). Update WeKan's caller to match: server/lib/ferretdbGovernor.js now sends
{ throttle: 1, ... } and the comments/guard test refer to the `throttle` command.
No behaviour change. WeKan-side names (ferretdbGovernor, slowDownFerretDb) are
WeKan's own and unchanged.
FerretDB is the other big CPU user on the same host. When WeKan's CPU monitor
detects a sustained high-CPU period it now asks FerretDB (via the custom
wekanThrottle command added to the bundled wekan/FerretDB v1 fork) what it is
doing and to slow down, and writes it to Admin Panel / Problems / CPU usage.
- server/lib/ferretdbGovernor.js: runs the wekanThrottle command over the raw
Mongo driver. slowDownFerretDb(slowDownMs, durationMs) asks FerretDB to pause a
few ms before each command for a short, self-expiring window and returns its
activity (commandsProcessed); resumeFerretDb() turns it off. Best-effort — on
plain MongoDB or an older FerretDB the command fails once and is never retried.
- server/lib/cpuMonitor.js: on 'start' asks FerretDB to slow down and logs a row
with FerretDB's reported activity and what it was asked; renews the
self-expiring throttle each sample while CPU stays high; on 'end' asks FerretDB
to resume and notes it. Tunable via WEKAN_FERRETDB_SLOWDOWN_MS.
Guard tests (cpuMonitorWiring) extended for the FerretDB governor. CHANGELOG +
docs/Features/CPU-usage/CPU-usage.md updated.
When CPU is high, the report now also records what automatic mitigation was
taken and whether it noticeably lowered CPU:
- Once the governor actually pauses a governed operation during a high-CPU
period, write ONE 'rate-limited' row: slowing down "<activity>" — pausing
200ms between steps to yield the CPU (also lowers FerretDB query load), with
the CPU% at slow-down start.
- Track the lowest CPU% seen after slowing down; the 'end' row reports the
effect: "slowed down <activity> (paused N times, Xs total). After slowing
down, CPU went A% -> B% — noticeably lower (about -Z points)" (or "not
noticeably lower"). When nothing was running to slow down, it says so.
Still at most three rows per episode (start, mitigation, end). The effect is a
correlation over the sampling window, reported as observed.
Also rename the design doc to docs/Features/CPU-usage/CPU-usage.md (CHANGELOG
link updated). Guard test extended for the mitigation logging.
WeKan and FerretDB on one machine can drive CPU high enough to starve other
software. Add a monitor, a governor, and a report. Design: docs/Features/CPU/CPU.md.
Monitor (server/lib/cpuMonitor.js): samples system-wide CPU% from os.cpus()
idle/total deltas on an interval (so it includes WeKan, FerretDB and every other
process). A pure, hysteresis state machine (models/lib/cpuHighTracker.js) turns
the samples into ONLY the START and END of each sustained high-CPU period — two
rows per episode, never a flood. Enters high after 3 consecutive samples >= 85%,
leaves after 3 consecutive < 70%. Each row carries duration, peak, system load,
and what WeKan was doing (setActivity label). Recorded to a new 'cpu' event
stream (server/lib/cpuLog.js).
Governor: cpuMonitor exports isHighCpu() and pauseIfBusy(), so long batch
operations await a short pause and yield the CPU only while the system is busy
(no cost when idle). Wired into the existing-file extension corrector. Tunable
via WEKAN_CPU_* env vars.
Report: 'cpu' added to EVENT_STREAMS; reuses the generic eventStreamReport
(stream="cpu") with search + pagination; a "CPU usage" item is added to the
Admin Panel / Problems side menu (cpuReportTitle i18n).
Tests: cpuHighTracker unit (start/end, duration/peak, no-flap hysteresis;
positive + negative) and cpuMonitorWiring source guards. CHANGELOG + design doc.
Whenever a filename or file requires sanitization — on upload, migration, the
existing-file corrector, or viewing/serving — record it to the Security event
stream (action:'sanitized'), the companion to the existing action:'blocked'
upload rejections. Each row carries:
- WHEN: the event timestamp.
- WHO: the original uploader (userId), shown as a new clickable username column
in the Problems event report.
- FOR WHAT REASON: sanitizationReasons() — URL-encoded name, invisible
characters, typosquatting (look-alike characters), the specific exploit KIND
(JavaScript code, XML code, XML loop (billion laughs), server-side PHP/ASP,
template injection, HTML code), wrong file type (.txt -> .png), filename too
long, or empty-name-generated.
- THE FILENAME: "from" -> "to".
- WHERE: board > swimlane > list > card, plus the board's organization(s) and
team(s) (server/lib/fileContext.js).
New: classifyExploitKinds() + sanitizationReasons() (isomorphic), the
server-only fileContext resolver, filenameSanitizeLog helpers, catalog keys
file.sanitize / file.content / file.malware, and the uploader column in the
event report. Wired at all fix points (attachments/avatars onAfterUpload,
moveToStorage, correctFileExtensions, httpStreamOutput). EICAR now uses the
file.malware key. Logging is best-effort and never breaks the upload/view path.
Tests: classifyExploitKinds + sanitizationReasons unit tests (positive +
negative) and logging-wiring source guards. CHANGELOG + design doc updated.
One unified filename subsystem, used everywhere a name is shown, uploaded,
served, or migrated. Design: docs/Features/Filename/Filename.md.
Display (imports/lib/fileNameDisplay.js, general cleanFileName + global
{{cleanFilename}}/{{downloadFilename}} helpers): URL-decode, normalize to
generally-used characters (NFKC + confusable-homoglyph folding so typosquatting
"payp<Cyrillic-a>l.exe" shows as "paypal.exe", only in a Latin-majority base so
genuine non-Latin names are preserved), remove invisible/control/bidi chars,
strip HTML/JS/XML/template markup. Removed the earlier invisible-char filter
button, warning triangle, inline descriptions, legend and server invisibleOnly
filter.
Upload (attachments + avatars, all backends): reject exploit-looking filenames
and EICAR virus test files; strip invisible chars; correct the extension to the
real detected type (double-click opens the right app); type-based name when
empty; cap length to a portable max (30, Amiga OS FFS) preserving the extension;
sanitize SVG JS / XML-loop content at the staging location before promoting to
final storage and delete the temp file after; enough-disk-space check with
small-RAM streaming and stop-and-remove-partial on any write error.
Existing files: general storage-agnostic detector streams a small header to
WRITABLE_PATH/files/temp, runs `file`, deletes the temp file; admin-only bounded
batch extension corrector; serve-time on-the-fly exploit sanitizer wired into
httpStreamOutput (sniffs the start, rewrites only dangerous markup, streams the
rest unchanged).
Migrations (moveToStorage/copyFile): sanitize content, finalize the name with
the same general function (detected type, corrected extension, folded
homoglyphs, capped length), save it at the destination, and number
same-name/different-content collisions (document.pdf, document-1.pdf, ...).
Tests: rewrote fileNameDisplay.test.cjs; added uploadFileName, diskSpace,
fileTypeCorrection and fileHardeningGuards unit tests (positive + negative);
updated Playwright spec 41 to the clean-name model. CHANGELOG + design doc.
Made the Files-report filename rendering a GENERAL, reusable component and used it
everywhere filenames are shown:
- New client/components/main/safeFilename.{jade,js,css}: +safeFilename(name=...)
URL-decodes the name, shows a red warning triangle when it hides invisible
characters, and replaces each invisible character inline with its red Unicode
name (all escaped plain text — never markdown/HTML). Plus two global helpers:
{{filenamePlain name}} (decoded name, invisible chars named — for title="" / JS
text) and {{downloadFilename name}} (decoded + invisible chars REMOVED).
- Used it in the Admin Panel → Files report and the card attachments (visible
name via +safeFilename; thumbnail title via filenamePlain; the download="" attr
via downloadFilename; the attachment viewer title via fileNamePlain()).
- Downloads now save a CLEAN name: the Content-Disposition sanitiser in both
server/routes/universalFileServer.js and legacyAttachments.js runs the name
through sanitizeDownloadFileName (URL-decode + remove all invisible/format/bidi
characters), never empty (falls back to "download").
New fileNamePlain()/sanitizeDownloadFileName() in imports/lib/fileNameDisplay.js;
unit + negative tests in tests/fileNameDisplay.test.cjs.
Thanks to xet7 !
Instead of colouring the entire filename red, the Files report now:
- shows a red warning triangle (fa-exclamation-triangle) to the left of any name
that hides invisible characters; and
- replaces each invisible character IN PLACE with its red Unicode description,
e.g. "evil[U+200B ZERO WIDTH SPACE].png" — the visible parts keep the normal
text colour.
New fileNameSegments()/describeInvisibleChar() in imports/lib/fileNameDisplay.js
split the (decoded) name into visible runs + one named segment per invisible
character (bracketed "U+XXXX NAME", falling back to the code point for unnamed C1
controls). Everything is still rendered as escaped plain text (Blaze `{{ }}`) —
never markdown/HTML. Unit + negative tests in tests/fileNameDisplay.test.cjs and
the Playwright spec updated to assert the warning + inline names.
Thanks to xet7 !
New spec tests/playwright/specs/41-admin-newest-features.e2e.js:
- Files report: seeds attachments (normal, URL-encoded "%D0%93%D1%80" -> "Гр", and
one hiding a zero-width space) and asserts the encoded name is DECODED, the
invisible-char name is flagged red (.filename-invisible), the invisible-only
filter lists only it (and a NEGATIVE toggle-off brings the others back), there is
NO Search button, and the search field + pagination controls + legend are shown.
- Version (Information) page: shows the live Reactivity mode plus the configured
METEOR_REACTIVITY_ORDER and DDP_TRANSPORT rows.
- NEGATIVE: the board Table view has no clickable-sortable headers (removed).
Thanks to xet7 !
The archived-boards list published EVERY archived board the user can delete at
once (unbounded, grows on long-lived instances). It now pages server-side
(searchTerm + limit/skip, 30 per page) with a getArchivedBoardsCount method, and
the template gained a search field + prev/next controls in one row (matching the
Admin report tables). Only the current page is ever loaded into the browser.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
Per request, clickable column-header sorting is removed everywhere it existed:
- Board Table view: the sortable `th.js-table-view-sort` headers become plain
headers; the sortField/sortDirection state, the sort click handler and the
sortIndicator arrow are gone. The table now always shows a stable order (card
title ascending). Search + pagination are unchanged.
- Admin Panel → People → Domains: same removal; the getDomainsWithUserCountsPage
method no longer takes sortField/sortDirection and returns a fixed domain-
ascending order (paginateDomains' default). Server-side search + pagination stay.
Dead sort-header CSS removed. Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
Translated filter-invisible-filenames and filename-invisible-legend (the
invisible-only filter button + the red legend) to all 153 languages.
Thanks to translators and xet7 !
The Translation report subscribed with a hardcoded limit of 0, which Mongo/
FerretDB treat as "no limit", so the page loaded EVERY translation string across
all languages into the browser at once. It now passes the infinite-scroll window
(page * 25), so it loads a page at a time and grows as you scroll — the same
bounded pattern the activity feed uses. Guarded in
tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
WeKan buttons hardcoded their colors, so a Member Settings → Change color theme
override never reached most of them (customTheme.css only themed
`button[type=submit].primary`, not plain `button.primary`, and the global button
base was solid black). Now the global button base and the primary buttons in
client/components/forms/forms.css use `var(--theme-accent, <original>)`, and the
admin action buttons (settingBody.css) and People-panel buttons (peopleBody.css,
incl. ext-box / add-remove-team / unlock-all) do the same. The fallback keeps the
default look identical, but once the user picks a theme accent, the buttons across
the app follow it.
Guarded in tests/buttonThemeColors.test.cjs.
Thanks to xet7 !
At Admin Panel → Problems → Files report:
- Percent-encoded filenames (e.g. "%D0%93%D1%80" -> "Гр") are URL-decoded for
display when they decode cleanly; malformed/partial encodings are left as-is.
- Filenames are always shown as PLAIN TEXT — Blaze `{{ }}` HTML-escapes, so a
name is never rendered as markdown or HTML.
- A filename hiding invisible / control / bidi / zero-width characters (after
decoding) is shown in RED. A translated legend on the right of the pagination
controls explains that red = invisible characters.
- A board-view-style filter toggle lists ONLY filenames containing invisible
characters (server-side, so it works across the whole paginated set); clicking
it again removes the filter.
New isomorphic helper imports/lib/fileNameDisplay.js (decodeFileNameSafe,
hasInvisibleChars, INVISIBLE_CHARS_SOURCE) is used by both the client (display +
red flag) and the server (the invisibleOnly query on attachmentsList /
getAttachmentsReportCount). Unit + source-guard tests in
tests/fileNameDisplay.test.cjs. English strings added; translations follow.
Thanks to xet7 !
Across the Admin Panel → Problems report tables (Files/Rules/Boards/Cards/
Impersonation) and the People/Org/Team/Domain tables:
- Removed the redundant "Search" button — typing in the field + Enter already
searches (the keydown handler was already there); dropped the now-dead
js-*-search-button click handlers.
- Put the pagination controls on the RIGHT of the search field, in one row
(margin-inline-start:auto, so it mirrors correctly in RTL), matching the
Security/Speed/Tests event table which already had this layout.
- Made the pagination controls follow the current theme: they now use
var(--theme-accent, #01628c) instead of hardcoded blue/grey/white, so they
honour Member Settings → Change color (which sets --theme-accent on :root) and
fall back to WeKan blue when no custom theme is chosen. The event-stream
pagination links are themed too.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
The Admin Panel → Problems → Cards report already paginates (limit/skip), but it
sorted by { boardId:1, sort:1 } which has NO index, so every page load full-sorted
all cards in memory — the spinner on a site with 11761 cards. Switched both the
cardsReport publication and the client mirror sort to { boardId:1, createdAt:-1 },
the existing index (server/models/cards.js), so one page is a bounded index scan.
Also added a { stream:1, at:-1 } index on the eventlog collection (and { stream:1 }
on eventlogAcks) so the Security/Speed/Tests report pages stay an index scan as the
log grows, instead of a full scan + in-memory sort.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
The Admin Panel → Problems detail methods eventLogCount/eventLogPage awaited
requireAdmin() BEFORE check()ing their arguments. When requireAdmin throws (a
non-admin call, or before admin status resolves on the client), Meteor's
audit-argument-checks runs and throws "Did not check() all arguments during call
to '<method>'", masking the real error and spamming the server log. Moved the
check() calls to the top of both methods, before any await/throw — matching
acknowledgeEventLog, which was already correct. Guarded in
tests/securityLog.test.cjs (check() must precede requireAdmin in every
argument-taking method).
Thanks to xet7 !
Sandstorm defaults to FerretDB but its grain launcher (sandstorm-src/start.js) set
neither --repl-set-name nor MONGO_OPLOG_URL / METEOR_REACTIVITY_ORDER, so it stayed
on poll-and-diff. Now the STEADY-STATE FerretDB is started with --repl-set-name=rs0
and WeKan is pointed at it with METEOR_REACTIVITY_ORDER=oplog,polling (OpLog only
when tailing works, polling fallback). The transient migration-target FerretDB stays
OpLog-free so bulk inserts are not slowed. WEKAN_FERRETDB_OPLOG=false forces polling.
This makes every platform that defaults to FerretDB — Snap, Sandstorm, Docker and
the prebuilt bundle — behave the same. Guarded in tests/ferretdbOplog.test.cjs.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
The FerretDB OpLog work added two Admin Panel → Version row labels
(Reactivity_order, DDP_transport). Translated both to all 153 languages, keeping
the environment-variable names METEOR_REACTIVITY_ORDER and DDP_TRANSPORT literal
inside the parentheses in every language (including RTL and non-Latin scripts).
Thanks to translators and xet7 !
Below the live "Reactivity mode" (oplog / changeStreams / polling — what is
actually running) and "MongoDB Oplog enabled" rows, the Version page now also
shows what was REQUESTED via the environment: the reactivity driver priority
order (METEOR_REACTIVITY_ORDER, falling back to DEFAULT_METEOR_REACTIVITY_ORDER)
and the DDP transport (DDP_TRANSPORT). Together they let an admin see at a glance
"I asked for oplog,polling and it is actually running oplog" vs "it fell back to
polling". The values are returned by the existing getStatistics() server method
(reading process.env), not exposed as public settings. Empty env shows '(unset)'.
New i18n keys Reactivity_order and DDP_transport; guard in tests/ferretdbOplog.test.cjs.
Thanks to xet7 !
Follow-up to enabling the FerretDB OpLog by default (#6480, #6481). Setting
MONGO_OPLOG_URL alone can make Meteor fail to start if OpLog tailing does not
actually work (the same way WeKan on Windows with MongoDB falls back to polling).
Fix: every FerretDB launch path now also sets
METEOR_REACTIVITY_ORDER=oplog,polling — Meteor tries the drivers left-to-right and
uses OpLog ONLY when tailing works, otherwise polling, so a broken/absent OpLog
never blocks startup. Previously only docker-compose set this; the snap
(wekan-control), the bundle (start-wekan.sh/.bat) and the docker entrypoint
(wekan-entrypoint.sh) set MONGO_OPLOG_URL WITHOUT the polling fallback. The
kill-switch path (WEKAN_FERRETDB_OPLOG=false) now selects polling-only.
Admin Panel / Version already reports which driver is actually live: server/
statistics.js derives "Reactivity mode" (oplog / changeStreams / polling) and
"MongoDB Oplog enabled" from Meteor's live _oplogHandle, so it shows `polling`
whenever OpLog did not come up — the direct way to confirm whether FerretDB is
on OpLog or polling.
Tests: tests/ferretdbOplog.test.cjs now asserts the oplog,polling fallback in
every launch path, the polling-only kill-switch path, and that the Version page
detects + displays the live reactivity driver.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
With FerretDB there is no MongoDB oplog, so Meteor observed every live query by
poll-and-diff, pinning FerretDB CPU at 100-390% on busy boards (#6480, #6481).
FerretDB v1 now ships an OpLog (wekan/FerretDB: auto-created capped local.oplog.rs
+ replica-set hello handshake), so every FerretDB launch path now:
- starts ferretdb with --repl-set-name=rs0 (snap ferretdb-control, docker
entrypoint + docker-compose service, bundle start-wekan.sh/.bat), which makes
FerretDB auto-create the OpLog and advertise the replica set; and
- points WeKan at it with MONGO_OPLOG_URL=.../local?replicaSet=rs0 (docker-compose
also switches METEOR_REACTIVITY_ORDER to oplog,polling), so Meteor TAILS the
OpLog instead of polling.
Enabled by default with a kill-switch: WEKAN_FERRETDB_OPLOG=false forces the old
polling-only behaviour. The calmer polling defaults remain as the fallback for
queries Meteor cannot observe via the OpLog. The transient migration ferretdb
(migration-control) deliberately stays oplog-free so bulk inserts are not slowed.
Also cut the client activity feed page from 500 to 50 rows: 500 was far more than
the sidebar/card feed shows and, under polling, was re-fetched and re-diffed on
every poll; infinite scroll still loads more on demand (the server cursor is
index-bounded either way).
Tests: tests/ferretdbOplog.test.cjs source-guards every launch path (repl-set arg,
MONGO_OPLOG_URL, kill-switch) plus the activity page size, and a negative test that
migration-control stays oplog-free.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
#6481 (Nissulya): after MongoDB 3.x -> FerretDB v1 migration, cards with a
non-finite `sort` (±Infinity / NaN, written by old WeKan before #6472) failed to
insert: FerretDB/SQLite rejects non-finite doubles ("invalid value { sort: +Inf }
(infinity values are not allowed)"), aborting the document and leaving boards
stuck on the loading spinner. sanitizeNonFinite() only made the bare mongoexport
tokens PARSE; the parsed value was still a JS Infinity/NaN. Added clampNonFinite()
in the migration tool to reset every non-finite number to a finite 0 before
insert, and a `nonfinite-sort-repair` startup schema-upgrade step that heals the
same corruption in an already-running database (MongoDB or FerretDB), using a
predicate built from finite literals only so it is safe on FerretDB too.
#6481 (Nissulya): LDAP `mail` -> `email` fieldmap returned `undefined` (worked in
6.09). getDataToSyncUserData's email branch read the mapped attribute
case-SENSITIVELY (ldapUser.hasOwnProperty / ldapUser[field]) while the rest of
wekan-ldap uses the case-insensitive getLDAPValue(); a directory returning the
attribute with a different case (exposed by ldapjs -> ldapts, which preserves the
server's case) missed it. The email branch (and the addLdapUser fallback) now
read via getLDAPValue().
#6480 (uusijani): board/CSV export paused on socket backpressure with
`res.once('drain', resolve); res.once('error', reject)`, which leaked one 'error'
listener per backpressured write ("MaxListenersExceededWarning: 11 error
listeners added to [ServerResponse]"). writeWithBackpressure() now removes both
listeners once either settles.
Added tests and negative tests for all three fixes.
Thanks to Nissulya, uusijani and xet7 !
Fixes#6480,
Fixes#6481.
Fix the intermittent "Unexpected userId after login" e2e flake (seen in
33-board-domains, which re-logs-in on the same page: admin then non-admin).
Meteor.userId() can lag the Meteor.loginWithToken callback by a tick, so reading
it immediately sometimes returned the PREVIOUS userId. Poll Meteor.userId() until
it settles on the expected id (5s timeout so a genuine mismatch still surfaces).
Pure test-helper change; the direct-Mongo-seed + resume-token login path this
uses does not go through createUser, so it is unaffected by the session security
changes.
Add server/lib/selfChecks.js: at startup (and via an admin-only runSelfChecks
method) run cheap invariants a unit test would assert (database round-trip,
WRITABLE_PATH/files writable) and record any failure to the Tests stream
(Admin Panel -> Problems -> Tests). WeKan does NOT require Playwright: only
failures detectable without a browser are logged, and no runtime code imports
Playwright (asserted by the test). Wired into server/imports.js; design doc
updated.
Add server/lib/speedMiddleware.js: a WebApp middleware that times non-asset HTTP
requests and records those slower than WEKAN_SLOW_REQUEST_MS (default 2000ms; 0
disables) to the speed stream via speedLog. Best-effort, never throws; wired into
server/imports.js. Source-guard test added.
Record more runtime rejections into the eventlog (Admin Panel Problems):
- fileValidation.js: log every upload rejection (dangerous MIME content ->
xss.mime, mime not on the allow-list -> file.mime, over size limit ->
file.size).
- metrics.js: log spoofing.xff when a /metrics request carrying an
X-Forwarded-For header is denied (likely forged-whitelisted-IP attempt).
- export.js: log authz.export at all four export-authorization denial paths.
All calls are best-effort/guarded (server-only require, try/catch) so logging
never breaks the guard. Source-guard tests added.
Translate problems, summary, securityReportTitle, speedReportTitle,
testsReportTitle, new-problems, acknowledge, no-new-problems,
problems-summary-help and the event-* table headers into all 153 non-English
languages (en is the source). All files validated as JSON.
- 2nd header bar: add a Problems button (warning icon) to the RIGHT of the Info
(version) button; it turns red when there are new problems (settingHeader.js
polls eventLogProblemAreas). Remove the old Reports button; the Admin Panel
still opens on Settings.
- The former Reports page is now the Problems page: left menu Summary / Security /
Speed / Tests, then a separator, then the moved Broken Cards/Files/Rules/Boards/
Cards/Impersonation items.
- Summary (problemsSummary, renamed from the removed top banner): the checkbox
list + one Acknowledge button — the ONLY place to acknowledge.
- Security/Speed/Tests: read-only, paginated, searchable event tables via new
admin-only eventLogPage/eventLogCount methods; acknowledgeEventLog now takes a
stream or array.
- i18n keys + CSS + source-guard tests + design doc updated.
Change the top problem banner from a per-area button to a checkbox list of
problem areas with a single Acknowledge button that acknowledges every checked
area in one call. acknowledgeEventLog now accepts a stream or an array of
streams. Acknowledging happens ONLY at the top banner; the Reports pages are
read-only (noted in the design doc).
Like the Announcement banner, the Admin Panel top now shows, for each problem
area with unacknowledged events, its menu path (Admin Panel -> Reports ->
Security/Speed/Tests) and the count of NEW problems. Each area has an Acknowledge
button that marks the newest problems seen, zeroing the count and removing the
info from the top.
- models/eventLog.js: add the eventlogAcks collection and admin-only methods
eventLogProblemAreas() (count of events newer than each stream ack) and
acknowledgeEventLog(stream) (upsert ack = now).
- client adminProblemBanner.{jade,js}: poll the counts, render path/count/button,
acknowledge on click; included in settingHeaderBar (top of every admin page).
- i18n keys (securityReportTitle/speedReportTitle/testsReportTitle/new-problems/
acknowledge) + banner CSS. Source-guard tests added.
Per correction: use only the existing WeKan database via Meteor JavaScript
queries (works on FerretDB and MongoDB); do not create files/DBs under
WRITABLE_PATH; and have FerretDB report problems to WeKan rather than writing
itself.
- models/eventLog.js: one `eventlog` collection (stream: security|speed|tests).
- server/lib/{securityLog,speedLog,testLog}.js: thin wrappers that insert one
document via EventLog.insertAsync (fire-and-forget, never throw).
- models/lib/securityLogFormat.js slimmed to just sanitizeDetail; remove the
node:sqlite event store (server/lib/eventStore.js) and all file/path/schema
helpers.
- Add a Tests stream: log anything that would fail an existing WeKan test.
- Design docs (WeKan.md, FerretDB.md) rewritten: DB-collection storage, grouped
counts for the summary, Admin Reports read the collection, and FerretDB reports
problems to WeKan which records them (no FerretDB DB/file writes).
- tests/securityLog.test.cjs updated (sanitizer + catalog + collection wiring +
no-filesystem guards); verified via Python mirror.
- Avatar localization redirect SSRF: fetch avatars via fetchSafe (DNS-pinned,
redirects rejected) instead of native redirect:follow, and validate
profile.avatarUrl scheme (http/https/data:image/local) at write time.
- Trello import source.url stored XSS: only render/store an http(s) activity
source URL, so a javascript: board url can no longer execute on click.
- Trello LIVE import readable SSRF: gate every attachment/background/avatar
download with validateAttachmentUrl, matching the offline import path.
- CAS login global user-data race: store validated CAS user data per credential
token instead of a module-global _userData (fixes account-takeover race).
- Metrics X-Forwarded-For whitelist bypass: only trust XFF behind
METRICS_TRUST_PROXY (parsed spoof-resistantly from the right); else use the
socket peer address.
- Stale impersonation export bypass: remove the "|| impersonateDone" export
authorization bypass; require real board visibility (canExport) only.
- Invitation code brute force: generate invitation codes with a 128-bit CSPRNG
(crypto.randomBytes) instead of a 6-digit Math.random value, and rate-limit
createUser (DDPRateLimiter).
The OIDC shared serviceData race from the same report was already fixed (#4897,
the per-login objects are callout-local). Source-guard regression test added
(tests/securityMeifukun.test.cjs) and wired into test:unit:node.
Thanks to meifukun and xet7 !
Wire in three new publish jobs (dormant until their secrets are set — each
guards on its secrets and skips with a ::notice:: so ordinary releases are
unaffected):
- snap-variants: build+publish wekan-ondra and wekan-gantt-gpl snaps.
- ucs: bump + push the wekan/univention app and upload to the App Provider.
- nextcloud: build the ExApp image and publish to the Nextcloud App Store.
Document the new secrets in the header. Add a "Remaining steps" section to the
top of Snap-Ondra-Gantt.md, UCS.md and Nextcloud.md (keys to add + how).
The 29 per-OS manual-vs-automatic update comparison docs move into OS/;
the WeKan-specific docs (README, Snap, Snap-Ondra-Gantt, UCS) stay in the
parent. All cross-links repointed and verified.
Add manual-vs-automatic (Snap-like) update comparison docs for all operating
systems with any Internet update mechanism: Linux, BSD, Haiku, Amiga, RISC OS,
Solaris/illumos, AIX, HP-UX, OpenVMS, z/OS, ArcaOS, ReactOS, FreeDOS, Plan 9,
Redox, SerenityOS, Android, iOS, ChromeOS, HarmonyOS, Ubuntu Touch, Sailfish,
postmarketOS, KaiOS, Tizen, webOS and TV/streaming OSes; plus a README index.
Add Snap-Ondra-Gantt.md (keys/secrets + release-all.yml changes to also release
the wekan-ondra and wekan-gantt-gpl snaps). Rename the two earlier dev docs to
Snap.md / Windows.md and repoint all links.
- i18n: registering generic Chinese (zh) as its own entry made bare "zh"
resolve to itself, so the "zh -> zh-Hans" alias is now dead code — remove it
from LANGUAGE_ALIASES (keep wuu -> wuu-Hans) and update the two mocha tests
(resolveTag/setLanguage) to expect "zh" instead of "zh-Hans".
- e2e (15-board-actions): the Board Settings cog was removed from the header
(it is in the right sidebar now), so the "one click from the header cog" test
failed in every browser. Rewrite it to open the sidebar and open the board
menu (which still has Archived Items) from there.
The changes committed since the v10.00 release bump had no CHANGELOG Upcoming
section. Add one above v10.00 covering all of them: the "Submit editors with
Enter" Member Setting, the right-sidebar drag-to-resize width feature, the #6481
migration NaN/Infinity fix, the #6465 Add List inline-composer options restore,
the right-sidebar width/inputs fix, and the missing copy-selection key — each
with commit links.
Add the sidebar resize handle tooltip (drag-to-resize-sidebar, "Drag to resize
sidebar") to every language file, translated into each language (English-variant
locales carry the English text). All 154 files JSON-validated; value-only
additions.
Add a resize handle on the sidebar edge, like resizing a spreadsheet column
(mirrors the list resize in client/components/lists/list.js). Drag it to change
the sidebar width; the width is saved to profile.sidebarWidth for logged-in
users and to browser localStorage (wekan-sidebar-width) for anonymous users on
a public board, then re-applied on load.
- The handle uses the LOGICAL inset-inline-start, so in LTR it is the left edge
of the right-docked sidebar and in RTL it is the RIGHT edge of the left-docked
sidebar; the drag direction inverts for RTL so dragging always widens/narrows
the visible panel correctly.
- Desktop only: on phones (<=800px) the handle is hidden and the sidebar stays
full width (the 100vw rule is now !important so a desktop inline width can
never leak into mobile).
- Width is clamped (min 280px, capped near the viewport) and re-applied on
window resize so crossing the mobile breakpoint clears/restores it.
New profile.sidebarWidth schema field + getSidebarWidth/setSidebarWidth helpers,
setSidebarWidth Meteor method, i18n (en, fi), and source-guard test
tests/sidebarResize.test.cjs.
Thanks to xet7 !
The Multi-Selection right-sidebar "Copy selection" button used {{_ (quote)copy-selection(quote)}}
but the key was missing from every language file — including the en source —
so i18next had no value to fall back to and rendered the raw key. Add
copy-selection ("Copy selection") to en and translate it to all languages,
mirroring each language(apos)s existing "move-selection" sibling with the verb changed
to copy. All 154 files JSON-validated; value-only additions.
Thanks to xet7 !
- .board-sidebar used width: 30vw, which scaled with the viewport: on very wide
screens it grew to ~double the intended width (it looked right only at mid
widths). Use width: clamp(320px, 30vw, 560px) so it keeps the mid-width look
but is capped (and floored) instead of scaling without bound. Phones (<800px)
still get the full-width 100vw rule.
- The sidebar filter text inputs (Filter List by Title, Filter by card title,
advanced filter) had no width, so they rendered at the browser default narrow
width with a big empty gap on the right. Sidebar text/search inputs now
width: 100% + box-sizing: border-box, so they fill the padded content area
with equal empty space on both sides (the .sidebar-content 12px padding).
Source-guard test tests/sidebarWidth.test.cjs.
Thanks to xet7 !
The #6465 per-list-header inline Add List composer (addListInline) had been
reduced to just a title input, dropping the options the old addListForm had.
Restore them:
- the "Add after which list" position <select>, listing the swimlane lists and
pre-selecting the list whose header button opened the composer; submit reads
it for afterListId and derives nextListId from the following option so the new
list is inserted between them (falls back to the header target for the empty
board case).
- the "or template" link (js-list-template) to create a list from a template.
Helpers swimlaneLists()/isDefaultAfterList() added; createListAfter already
accepts nextListId. Source-guard test tests/addListComposerOptions.test.cjs.
Thanks to csonkaoszimt and xet7 !
Fixes#6465.
Add the two new Member Settings keys (submit-on-enter, submit-on-enter-
description) to every language file in imports/i18n/data/, translated into each
language and inserted after show-desktop-drag-handles. English-variant locales
(en-GB, en_AU, ...) carry the English text; each real language matches its own
terminology, and the keyboard-key tokens Enter, Shift+Enter and Ctrl/Cmd+Enter
are kept verbatim. All 154 files JSON-validated; value-only additions.
#4236 made every multi-line editor submit only on Ctrl/Cmd+Enter (plain Enter
= newline) so titles could be multi-line, but that removed the fast
Enter-to-save title workflow some users rely on (v10 email feedback). Add a
per-user preference in the Member Settings (Change Settings) popup, saved to
profile.submitOnEnter and OFF by default: when on, plain Enter submits the card
title, description and other inlined forms, and Shift+Enter inserts a newline;
when off, behaviour is unchanged (Ctrl/Cmd+Enter saves).
The rule stays in the single pure isSubmitKey(event, {submitOnEnter}); the card
title, the card-description override and the shared client/lib/inlinedform.js
all route through it and read the preference from the current user. New toggle
+ helper + toggleSubmitOnEnter method + schema field, i18n (en, fi), and
editorSubmitKey.test.cjs extended with positive + negative opt-in cases.
Thanks to xet7 !
Related to #4236.
mongo 3.x mongoexport emits non-finite doubles as the bare tokens NaN,
Infinity, +Infinity and -Infinity, which are not valid JSON, so EJSON.parse
threw ("Unexpected token N/+") and migrate-mongo3-to-ferretdb.mjs dropped the
WHOLE document — leaving boards/cards missing after an otherwise "successful"
migration. sanitizeNonFinite() now rewrites those bare tokens, only outside
string literals, to the canonical EJSON v2 double form {"$numberDouble":"..."}
that EJSON.parse accepts, so the document migrates instead of being lost.
Strings that merely contain "NaN"/"Infinity" and ordinary negative numbers are
left untouched. Test tests/migrateNonFinite.test.cjs (with negative cases).
Thanks to Nissulya and xet7 !
Fixes#6481.
Rewrite the v10.00 section to match the final implementation and group ALL 101
commits in the release under their own headings (each with commit links):
- Corrected "done differently" cases: Change Color is visible grouped swatches
(not the initial two-level dropdowns); Font is font-name + size buttons with
immediate apply (not dropdowns); the board-header "icons only" change was
reverted so button texts stay.
- Fixed the Home board entry: it is set via the All Boards Multi-Selection
"Selected:" home action and the after-login redirect runs on all deployments,
so it is available, NOT disabled and NOT Sandstorm-only (an earlier draft
wrongly said the UI was disabled).
- Every commit since v9.99 is now listed once, grouped by feature/fix area.
Rename .github/workflows/playwright.yml -> playwright.yml.disabled so GitHub
Actions no longer runs it (only .yml/.yaml files in .github/workflows are
executed). Reversible by renaming back. NOTE: this workflow also contained the
Meteor unit-tests job and a Puppeteer regression job, so those stop running too.
The script lives in releases/translations/, so the repo root is two levels up
(../..), not one. With a single .. it landed in releases/ and looked for ../tx
at wekan/tx instead of the sibling ../tx, aborting with "tx not found". Match
the cd "$(dirname "$0")/../.." pattern used by the other scripts here.
The .tx config maps Transifex "war" -> local wa-RR.i18n.json, i.e. wa-RR is
Waray/Winaray (a Philippine language), NOT a regional variant of Walloon (wa).
An earlier seed wrongly copied Walloon content into it. Retranslate the file
fresh from English into Waray (2191 strings); placeholders/brand names
preserved, key set unchanged, JSON validated.
- Register Wu Chinese (wuu-Hans): it had a data file but no languages.js
entry, so it was neither browser-detectable nor shown in Change Language.
- Add wuu -> wuu-Hans to LANGUAGE_ALIASES so a bare "wuu" browser locale
resolves (mirrors zh -> zh-Hans).
- Fix display names that were in the wrong script for their (Latin) content:
Wolof "ولوفل" -> "Wolof"; Malay "بهاس ملايو" -> "Bahasa Melayu" (+ Malaysia).
km_KH/ru_RU are symlinks to km-KH/ru-RU, already covered. Every data file is
now registered, so all are browser-detectable and visible in the popup.
Fresh translations: vi, uz, uz-AR (Arabic-script Uzbek), ve (Venda), ve-CC
(Venetian), ve-PP (Vepsian), vo (Volapuk), wa (Walloon), wo (Wolof), xh
(Xhosa), yi (Yiddish), yo (Yoruba), zgh (Tamazight/Tifinagh), zu (Zulu).
Seeded variants uz-UZ/uz-LA, vi-VN, wa-RR, zu-ZA from bases. Completes the
full 153-language set. Placeholders/brand names preserved; JSON validated.
zh.i18n.json existed but had no entry in the languages registry, so a browser
reporting bare "zh" could not auto-detect it and it was missing from the Change
Language list. Add it (code zh, name 中文). The other two unregistered data
files (km_KH, ru_RU) are underscore duplicates already covered by the existing
km-KH / ru-RU entries, whose tag is the underscore form.
Seed Mandarin/Wu/Cantonese (cmn, wuu-Hans, yue_CN) from zh-CN, Japanese-Hiragana
locale (ja-HI) from ja, West Flemish (vl-SS) from nl, and Moroccan Arabic (ary)
from ar as machine-quality baselines sharing the written form, for the community
to refine. Placeholders preserved; JSON validated. 4074 strings.
Fill previously-untranslated UI strings in de, fr, es, it, nl, ru, pl, uk, cs,
ja, ko, zh-CN, tr, ar, pt. Each language matches its existing file terminology
as a glossary plus standard Kanban terms; product/brand names, acronyms, env
vars, console commands, placeholders (__var__, %s, {{..}}) and markup preserved
verbatim. Value-only changes; every file JSON-validated.
de 524, fr 617, es 917, it 938, nl 458, ru 974, pl 1037, uk 895, cs 1108,
ja 926, ko 850, zh-CN 929, tr 1059, ar 1145, pt 500 strings.
Fill previously-untranslated UI strings in the five near-complete languages,
matching each file existing terminology as a glossary and standard Kanban
terms (board, list, card, swimlane, label, checklist, theme, font, ...).
Product/brand names, acronyms, env vars, placeholders (__var__, %s, {{..}})
and markup preserved verbatim. Value-only changes; JSON validated.
zh-TW 29, pt-BR 28, da 159, he 262, sv 382 strings.
Pushes the English source, then force-pushes every language translation to
Transifex in one run (../tx push -s; ../tx push -t -f). -f is required or the
Go tx CLI skips languages whose local file is not newer than the server copy.
Warns that it overwrites newer community translations, so pull first if needed.
Translate the 21 previously-English strings in fi.i18n.json: the disable-*
and anonymize-* import/export/activities/notifications/watch admin feature
labels and descriptions, plus impersonation report title, impersonated user
and reason. Terminology follows existing Finnish strings (seuraaminen,
toimet, profiilikuva, tuonti/vienti, esiintyä käyttäjänä).
Below the "Multi-Selection is on" button a "Selected:" row now offers two
actions on the multi-selected boards:
- star icon: stars every selected board (sets them as Starred).
- home icon: sets the first selected board as the Home board (opened after
login) via the existing toggleDefaultBoard method + router redirect, which
brings the previously hidden Home-board feature back into use.
The Home board also always shows FIRST in the Starred list (even when it is
not itself starred), badged with a home icon centred at the top of its tile.
- Search boards box is now ~half width (300px); the input flexes to fill it.
- "Click checkboxes to select boards" hint moved out of the path title and
stacked directly below the "Multi-Selection is on" button (own column).
- Folder icon and the menu title (e.g. "Remaining") are grouped so the title
always sits to the RIGHT of the icon instead of wrapping below it.
The Filter by Unread / View All / Delete All Notifications item icons
(envelope, copy, trash, check) were faint; force the .menu-icon and .check-icon
(and their i.fa) to black.
The X dropped below the header because a global `.close { position: absolute;
top: 5px }` rule (boardBody.css) applied once my rule stopped setting position.
Set position: static on the drawer .close so it stays a flex item and aligns
with the Notifications title at the right edge of the header row.
- The drawer and its header are now full width (100vw) instead of 400px.
- Rebuild the header as a flex row (hamburger left, title centre via flex:1, X
right) instead of fragile absolute positioning, so the X is aligned with the
Notifications title at the right edge (was sitting too low).
- Force the hamburger and X to black with !important (they were inheriting the
themed header white link colour), overriding the surrounding themed bar.
- The X close button is now black, moved up (top: 8px, aligned with the
"Notifications" title instead of vertically centred lower) and to the far
right (inset-inline-end: 4px).
- The left hamburger menu toggle is black (was #333).
The member-menu "Notifications" item and its js-notifications-drawer-toggle
handler toggled the same notifications drawer as the header bell icon
(notifications.js), so it was a duplicate. Remove the menu entry and its
now-unused handler; the header bell is unchanged.
The js-new-search button clears the search (empties the input + query), so it
is a Clear button. Replace its broom icon with the text of the existing
trello-clear-job translation (en "Clear" / fi "Tyhjennä") and use it for the
aria-label too.
The global-search button hardcoded belize #216694 (inline !important styles +
.board-color-belize CSS), ignoring the theme. Make it a .primary type="submit"
button (safe: the search form has onsubmit="return false") so it uses the
theme override colour via the existing button[type=submit].primary rules
(default blue, or the board/global theme), and remove the hardcoded belize
styles.
The theme override colours .primary buttons via `button[type=submit].primary`
(board-color-* and custom-theme rules). A <button> without an explicit type
attribute does not match [type=submit] in CSS (though it already behaves as
submit), so the archive Restore/Delete buttons kept the default blue. Add
type="submit" (no behaviour change) so they match the theme rules and use the
global theme override colour (named or custom).
The header bars have a higher z-index than #modal, so the archive panel top
(and the close X) was hidden under the top header bar. Offset the archive
modal content 96px from the top (clears both the quick-access and board header
bars) and extend to the window bottom via min-height calc(100vh - 106px).
The archive modal used the default .modal-content (500px, margin: 5vh auto),
so archived boards were cramped and the panel stopped short of the window
bottom. Target the archive modal (the only one containing .archived-lists) and
make it 96vw wide with no bottom margin + min-height calc(100vh - 2vh) so it
reaches the bottom of the browser window; each archived board is a full-width
row.
Add the .primary class to both "Upload an avatar" buttons so they use the
theme primary-button style (default #005377 blue background + white text,
overridden by the board/global theme color) instead of the plain grey/black
default button.
Give .js-reset-text-color / .js-reset-bg-color a button appearance (border,
padding, background, hover) with a dimmed disabled state, matching the font/
size buttons.
Redesign the Font popup:
- Font: one button per installed font, each shown IN ITS OWN font (via inline
style), plus a Default button. Clicking a font applies it immediately.
- Size: a row of buttons ordered by percent — smaller on the left, 100%
(Default) in the middle, larger on the right. Clicking a size applies it
immediately.
- Colors: the text/background color wheels now apply immediately on change /
reset. Removed the Save button (everything applies on click).
New .ui-font-btn / .ui-font-size-btn styling (with .active) in labels.css.
Tests updated in tests/uiFonts.test.cjs.
Widen the language popup responsively (width: min(90vw, 1100px), max-width:
90vw) and lay the list out as an auto-filling grid (repeat(auto-fill,
minmax(170px, 1fr))) so as many languages as possible are visible at once on
wide windows, collapsing to a single column when narrow.
Guarded by tests/changeLanguageColumns.test.cjs.
- Revert the unconditional hiding of board-header button text labels (Private,
Muted, Sort, Filter, ...): they show again at normal widths. The pre-existing
mobile-only (max-width:800px, #6419) icons-only rule is untouched.
- CHANGELOG Upcoming: add consolidated entries for the recent All Boards /
board-header layout polish, the Change Color swatches / immediate-apply /
applies-everywhere / popup title, the #4759 user-insert validator fix, and the
rebuild-wekan.sh CURRENT-IP fix; mark the #2220 home-board toggle as currently
disabled.
"+ Add Board" and "+ Add Template Container" share the .js-add-board .label
element, so add an .is-template-container class to the templates-menu variant
and give it padding 20/8/22/8 — 2px lower than "+ Add Board" (18/8/24/8) —
while keeping the same 42px total vertical padding so the tile height is
unchanged.
Shift the .js-add-board .label vertical padding (top 24->20, bottom 18->22)
so the "+ Add Board" / "+ Add Template Container" text sits 4px higher, while
keeping the same 42px total vertical padding so the grey tile stays the same
height as the board icons. Test now checks total vertical padding equality
(height) rather than an exact padding string.
The desktop board-handle had a dark rgba(0,0,0,0.4) background box; make it
transparent so only the drag-handle icon is visible. The hover highlight is
kept. Guarded in tests/addBoardTileHeight.test.cjs.
The desktop board-handle was top-centered (top:4px; left:50%; translateX);
move it to the right middle (top:50%; translateY(-50%); inset-inline-end),
matching the mobile/small-screen handle position. Guarded in
tests/addBoardTileHeight.test.cjs.
- All Boards path header: order is now Multi-Selection, then Sort, then Search
boards (Search moved to the right of Multi-Selection; Multi-Selection moved to
the left of Sort). Guarded in tests/addBoardTileHeight.test.cjs.
- Top header bar: swap the positions of the mobile/desktop toggle and the zoom
controls (mobile toggle now right after the logo, zoom later). Both kept as
ungated direct children (zoom is no longer hidden when the logo is hidden).
Make the board-header button text labels (Private, Muted, Sort, Filter,
Swimlanes, Multi-Selection, ...) always hidden (was only under a max-width
media query), so the header shows icons only. The board title and the star
count (.board-star-counter) are not button labels and stay.
Guarded in tests/headerHamburger.test.cjs.
The #6465 one-click board-settings cog (js-open-board-menu) sat just left of the
sidebar hamburger, duplicating Board Settings which is reachable from the right
sidebar. Remove the cog from boardHeader.jade, its now-dead click handler from
boardHeader.js, and the unused .js-open-board-menu header CSS rule. The sidebar
board-menu button (sidebar.jade/js) is unchanged, and the hamburger + separator
remain.
Guarded in tests/headerHamburger.test.cjs.
When the window is not wide enough, the 2nd header bar button labels (Private,
Muted, Sort, Multi-Selection, ...) wrapped to a second row. Add a max-width:
1200px media query that hides the .board-header-btn text spans (show icons
only), keeping the board title and the buttons on one line. The star count
(.board-star-counter) is kept.
Guarded in tests/headerHamburger.test.cjs.
Previously the sidebar hamburger sat 12px from the right edge (2px margin +
10px bar right padding), more than the ~8px gap to the right of the user name
in the top bar (.header-user-bar-name margin-inline-end: 8px). Remove the board
header bar right padding and give the hamburger margin-inline-end: 8px, so its
right-edge gap is the same small amount as the user name.
Guarded in tests/headerHamburger.test.cjs.
The hamburger used the general .board-header-btn margin: 0 12px, leaving a
button-sized empty gap on each side. Tighten its side margins to 2px (and the
preceding cog button right margin to 2px) so the hamburger sits snugly at the
right edge with no wasted space to its left or right.
Guarded in tests/headerHamburger.test.cjs.
The board header bar (Swimlanes + Lists views) used a float layout: the right
button group (which ends with the js-toggle-sidebar hamburger) was float:
inline-end. As the window width changed, the floated groups wrapped and the
hamburger drifted to the middle of the bar. Make #header-main-bar a flex row
(align-items:center, flex-wrap:wrap), make the button groups flex (their
buttons float is ignored inside a flex container), and pin the right group with
margin-inline-start:auto so it always hugs the right edge (or the right of its
row when wrapped).
Guarded by tests/headerHamburger.test.cjs.
Feedback fixes to the Select Color picker:
- Apply IMMEDIATELY on clicking a swatch (and when a custom-color wheel is
committed) via a shared applySelection(); removed the Save button/handler.
- Category titles (Flat/Clear/Dark/Special) are left-aligned and clear: both,
so they drop below the previous group swatches (which float: inline-start)
instead of the 2nd/3rd/4th title sitting mid-row.
- Remove the empty band above the first (Flat) title (first-child margin-top:0)
and tighten the Default row.
- Member Settings Change Color popup now has a header: added changeColorPopup-title
("Change Color" / fi "Vaihda väri"), matching Board Settings.
Tests updated in tests/themeColorPicker.test.cjs.
The dev-server CURRENT-IP options detected the IP with
ip a | grep noprefixroute | ... | grep 192.
which requires the noprefixroute flag AND a 192.x subnet. On hosts without
either (e.g. arm64 Ubuntu on a 10.x/172.x network) it returned empty, so
ROOT_URL became http://:3000 and Meteor crashed with "TypeError: Invalid URL".
Detect the primary IP subnet-agnostically via the default route
(ip route get 1.1.1.1 -> src), fall back to hostname -I, then to localhost so
the URL is always valid. macOS uses ipconfig getifaddr en0/en1 with a localhost
fallback. Applied to both CURRENT-IP dev-server options.
Remove the fa-home Home-board toggle from the board tiles (boardsList.jade),
its click handler and the isDefaultBoard tile helper (boardsList.js), so a
Home board can no longer be set from the All Boards page. The model helpers,
server toggleDefaultBoard method and the login redirect are left intact but
are no longer reachable from the UI. Test flips to guard the disabled state.
The All Boards button showed only an icon (span.emoji-icon > fa-check-square-o)
with the reset X as a sibling, while the Swimlanes View (boardHeader.jade)
shows the check icon + a "Multi-Selection" text label with the reset X nested
inside. Match the All Boards markup to the Swimlanes View (direct icon + text
label + nested reset with fa-times-thin), and add stopPropagation to the reset
handler so the now-nested X does not bubble to the activate handler and
immediately re-enable selection.
Guarded by tests/multiSelectionButton.test.cjs.
The .boards-path-header was a single-row flex (justify-content: space-between,
no flex-wrap) and .path-right (search box + Sort / Multi-Selection / Clear)
also did not wrap, so narrowing the window — especially with Multi-Selection
on, whose hint widens .path-left — pushed those buttons off/hid them. Add
flex-wrap: wrap to the bar, .path-left (min-width:0 so it can shrink; hint
wraps under the title) and .path-right (buttons wrap among themselves), so
everything drops to a second row and stays visible.
Guarded in tests/addBoardTileHeight.test.cjs.
The .board-list-header div (a leftover zoom-controls container) rendered
nothing but still reserved vertical space via margin: 1vh 0 2vh 0 + padding:
1vh 0 — an empty grey band above the boards layout, between the top and the
left menu / "My Boards" bar. Removed the empty element from boardsList.jade
and its now-unused CSS rule, so .boards-layout is the first child of .wrapper.
Guarded in tests/addBoardTileHeight.test.cjs.
The grey add-tile (.js-add-board .label, shared by both "+ Add Board" and
"+ Add Template Container") overrode min-height:100px, line-height:56px and
padding:36px 8px 32px 8px — taller than the #6465-thinned board tiles
(.board-list-item: min-height:72px, padding:24px 8px 18px 8px). Match the
board-tile box model so the grey background is the same height as a board icon.
Guarded by tests/addBoardTileHeight.test.cjs (asserts the add-tile min-height +
padding equal the board tile, and the old oversized values are gone).
Two fixes from feedback that picking clearblue "did not change" and the
dropdowns were hard to use:
1) The global theme override now wins EVERYWHERE, including board pages. Before,
the <body> autorun suppressed it whenever a board was open (onBoard gate), so
changing the color while viewing a board did nothing. Now a set global override
is applied regardless of board context, and #header / #header-quick-access
(header.jade) and .board-wrapper (boardBody.jade) prefer the global override
over the per-board color. Unset it to return to per-board colors. When no
global is set, an open board still exposes its own custom colors.
2) The picker no longer uses category/theme dropdowns (colors were invisible).
It now shows the actual color SWATCHES with their names, grouped by category,
with the category name as a header above each group. The flat/clear color
wheels still appear once such a color is selected; custom-capability is derived
from the selected color. customTheme.css styles the group labels.
Tests updated: themeColorPicker/globalThemeColor guards for grouped swatches and
the global-wins-everywhere behaviour.
Two fixes to the #6465 inline Add List composer:
1) Save button did nothing. The inline composer calls createListAfter WITHOUT
nextListId, but the server check() used Match.OneOf(String,null,undefined)
(not Match.Optional) for it. Meteor check throws "Match failed [400]" on a
MISSING object key unless the sub-pattern is Match.Optional, so every inline
add-list 400'd. The omittable params (swimlaneId/afterListId/nextListId/type)
are now Match.Optional, so callers may omit them.
2) Empty swimlane/board now shows a + button, and the create-list form appears
only after clicking it (a swimlane that already has lists keeps using the
per-list-header add-list button — no + button needed). The reveal is scoped
to the clicked swimlane via a wekan-add-list-empty Session flag, cleared on
save/close.
Tests: models/lib/createListParams.js + tests/createListParams.test.cjs mirror
the method's param contract (incl. Meteor's missing-key rule) with the exact
client shapes + negatives, and a source guard that the check uses Match.Optional;
tests/upcomingUiGuards.test.cjs gains guards for the empty-state + button reveal.
Wired into test:unit:node.
specs/13-swimlanes.e2e.js waited only 6s for the swimlane action .js-pop-over
to appear. Under the full parallel suite that occasionally exceeds 6s on
webkit (the popup opens fine, ~3s, when the test runs alone), so the test
flaked. Bump to 15s to match the suite standard popup-visibility wait; a
genuinely broken popup still fails.
The optional profile.uiTextColor / profile.uiTextBgColor schema fields ran
their custom() hex validator on EVERY user insert, including when the field
was absent. /^#..$/.test(undefined) is false, so the validator returned
"notAHexColor" and collection2 threw ValidationError for any user with no
custom color set — surfacing as a SyncedCron fatal unhandledRejection and
blocking user creation (seen in ../log test-server.log; also cascaded into
ECONNREFUSED e2e failures as the server destabilized).
Guard both custom() validators to return undefined when the value is unset
(undefined/null/empty), matching the existing list-color validator. Add a
source-guard test so the guard cannot silently regress.
Translate the strings added this cycle in fi.i18n.json, reusing existing
terminology (väri, taulu, lista, uimarata, fontti, teema, Oletus): the Select
Color theme categories, the Member Settings font / size / text + background
color pickers, the default-board tooltips, and the list-move confirmation.
Fixes theme-category-clear, which had been auto-translated to the verb
"Tyhjennä" (empty) instead of the theme sense "Kirkas". font-preview-text uses
the standard Finnish pangram so the preview shows ä/ö.
Restore the old "a grain opens straight into its board" behaviour as a
convenience, WITHOUT persisting anything. On the Sandstorm home route only:
- a saved Home board (explicitly chosen by the user) always wins -> redirect;
- else, once the boards subscription has loaded, exactly ONE board -> just
open it (nothing is saved);
- else (zero or many boards, no chosen Home board) -> stay on All Boards.
Choosing a Home board stays a separate, explicit action (the All Boards home
toggle, #2220) — the auto-open never writes it.
The redirect is reactive (Tracker.autorun over a boards subscription), so it
waits out Sandstorm asynchronous grain login (Meteor.userId lands late) and
board loading instead of firing once too early. Runs at most once per page
load, and only when isSandstorm.
- models/lib/sandstormAutoOpen.js: pure, unit-tested decideSandstormAutoOpen()
(+ tests/sandstormAutoOpen.test.cjs, wired into test:unit:node).
- config/router.js: startSandstormAutoOpen() reactive redirect, gated to
Sandstorm; non-Sandstorm keeps the existing one-shot default-board redirect.
The Font popup now has a color wheel for the text color and one for the text
background color, each with an Unset button to go back to default. Values are
free choices (native <input type=color>), validated server-side as #rrggbb
hex (models/lib/uiFonts isHexColor6) so only a strict hex ever reaches a CSS
value — no injection surface. An unset/invalid value clears that color.
- profile.uiTextColor / profile.uiTextBgColor schema (hex-validated) + getters;
setUiColors(textColor, bgColor) method ($set valid hex, $unset otherwise).
- changeFontPopup: two color wheels + reset buttons; live preview reflects
font, size, text color and background color.
- Applied UI-wide via --wekan-ui-text-color / --wekan-ui-bg-color CSS variables
+ has-ui-text-color / has-ui-bg-color body classes (uiFont.js + uiFont.css).
- i18n text-color / text-background-color; tests extended (hex + negatives +
source guards).
Part of #4759.
New "Font" entry in the member menu opens a popup with a dropdown of fonts
DETECTED as actually installed in the browser (no free typing) and a Font
size dropdown of sensible presets (Smaller..Largest, no typed numbers). Both
have a Default option that unsets the custom choice.
Security: font names and size keys are validated server-side against a
curated whitelist / preset list (models/lib/uiFonts.js), so only a known safe
font name and a preset percentage ever reach the DOM. Labels are plain text
(Blaze-escaped) — never HTML or markdown. No CSS-injection surface.
- models/lib/uiFonts.js: UI_FONTS whitelist + SAFE_FONT_RE + isKnownFont /
fontFamilyValue and UI_FONT_SIZES presets + isKnownFontSize / fontSizeValue.
- client/lib/fontDetector.js: canvas width-comparison detection of installed
fonts, filtered to the whitelist.
- profile.uiFont / profile.uiFontSize schema + getters; setUiFont /
setUiFontSize methods (validated, null/default unsets).
- changeFontPopup (font + size dropdowns, both with Default) wired in
userHeader.js; applied UI-wide via CSS variables in uiFont.js + uiFont.css
(marker body classes), wired into client/features/main.js + client/styles.js.
- i18n change-font/font/font-default/font-size(+presets); tests/uiFonts.test.cjs
(pure + negatives + source guards) wired into test:unit:node.
This is a Member Settings feature (not an Admin Panel option).
Fixes#4759.
Both Board Settings and Member Settings Change Color now use a shared
category -> theme two-level dropdown picker with custom color wheels for the
flat (1 color) and clear (2 colors, a color slide) categories; dark/special
are fixed. Custom colors are validated server-side as #rrggbb, stored in
board.customThemeColors / profile.globalThemeCustomColors, and applied as
CSS variables (--theme-accent / --theme-accent-2) consumed by customTheme.css
to recolor the header, primary buttons and sidebar button.
- client/components/main/themeColorPicker.{jade,js}: shared picker, scope
"board" or "global", reusing the #5514 native color wheel + themeCategories.
- board.setColor(color, custom) + setGlobalThemeColor(color, custom): validate
via isValidCustomColors (flat/clear + count + hex) before storing.
- boardChangeColorPopup and changeColorPopup now render the shared picker;
removed their old swatch-list helpers/events.
- globalThemeColor.js: apply custom colors as :root CSS variables (board own
colors on a board, else the user global override) + marker body classes;
customTheme.css consumes them.
- Wire globalThemeColor.js / themeColorPicker into client/features/main.js and
customTheme.css into client/styles.js. This also fixes globalThemeColor.js
never having been imported (so the #5778 override now actually loads).
- i18n theme / theme-category[-flat/clear/dark/special]; tests
themeColorPicker.test.cjs + updated globalThemeColor.test.cjs.
Fixes#5778.
Partition the ~19 board/global theme colors into flat / clear / dark /
special and define where custom colors are allowed (flat = 1 accent,
clear = 2 for a color slide, dark/special = fixed none). This is the shared
source of truth for the redesigned Select Color picker (two-level dropdowns
+ color wheel) used by both Board Settings and Member Settings.
- models/lib/themeCategories.js: THEME_CATEGORIES + categoryOf /
colorsInCategory / allowsCustomColor / customColorCount /
isValidCustomColors (validates category + count + #rrggbb hex).
- tests/themeCategories.test.cjs (wired into test:unit:node): behaviour +
negatives + a source guard that the partition exactly equals
config/const.js ALLOWED_BOARD_COLORS.
- docs/Theme/Theme.md: full design — categories, two-level dropdown UX,
custom-color rules, CSS-variable rendering plan, storage
(board.customThemeColors / profile.globalThemeCustomColors), and
server-side validation.
Completes the global per-user theme override (Member Menu / Change Color)
begun in the previous commit.
Fixes#5778.
A new "Change Color" entry in the member menu works like Board Settings /
Change Color, but is a per-user GLOBAL override saved to the profile
(profile.globalThemeColor). The chosen color theme applies to the whole UI —
All Boards, Search All Boards, Admin Panel, My Cards, etc. — via a
board-color-<name> class on <body> and the header, so a user can pick a dark
theme (dark/midnight/moderndark/exodark/cleandark) or any other theme
everywhere. The first popup entry clears the override.
- models/users.js: profile.globalThemeColor field + getGlobalThemeColor /
globalThemeColorClass / setGlobalThemeColor helpers.
- server/models/users.js: setGlobalThemeColor method, validated against
BOARD_COLORS (rejects unknown colors so no arbitrary CSS class is injected)
and auth-guarded; null/empty clears it.
- client/components/main/globalThemeColor.js: Tracker autorun that adds the
class to <body> on non-board pages; on a board the board own color wins, so
the global class is cleared there to avoid two themes clashing.
- header.jade: #header and #header-quick-access fall back to the user global
theme class when not on a board (covers the #header-specific color rules).
- Change Color menu entry + changeColorPopup (color swatches + clear option),
wired in userHeader.js.
- i18n change-color / theme-default; tests/globalThemeColor.test.cjs wired
into test:unit:node.
Deleting a list no longer destroys it. The list and its cards are marked
(deletedAt/deletedBy/deleteBatchId), hidden from the board, recorded as a
reversible delete in history, and restorable via lists.restore or Ctrl+Z.
This is the first slice of "no permanent delete in ordinary use": physical
removal is limited to GDPR/account erasure and a Global-Admin purge gated by
a new Admin Panel / Features / Delete "Enable permanent delete" toggle
(off by default).
- models/lib/softDelete.js: pure notDeleted/softDeleteSet/restoreModifier/
canPurge helpers (+ tests/softDelete.test.cjs, wired into test:unit:node).
softDeleteSet omits falsy actor/batch and restore uses $unset so no null is
ever written to a Date/String schema field.
- enablePermanentDelete feature flag (models/lib/featureFlags.js) + Settings
schema field.
- deletedAt/deletedBy/deleteBatchId schema fields on Lists and Cards
(optional, no null default -> absent means live).
- board/swimlane list render paths filter deletedAt: null.
- server/models/lists.js: shared softRemoveList() + lists.softRemove /
lists.restore / lists.purge (purge gated on canPurge = isAdmin && flag);
client delete handler and REST DELETE now soft-remove.
- userPositionHistory undo()/redo() handle actionType delete/restore via a
batch-consistent _applyDeleted() helper.
Design + planned rollout (other entities, Recycle Bin, admin Delete category
table with GDPR data classes) in docs/Features/Undo/Undo.md.
Every user-facing delete becomes a soft delete (deletedAt/deletedBy), making
deletions restorable and undoable (#1023). No permanent delete in ordinary
use: physical removal is limited to GDPR/account erasure and an explicit
Global-Admin purge gated behind Admin Panel / Features / Delete ->
"Enable permanent delete for Global Admin" (off by default). Covers scope
(soft vs exempt collections), the softRemove/notDeleted mechanism, cascade
via deleteBatchId, archived-vs-deleted distinction, undo/History integration,
and migration steps.
The activities publication only ships the most-recent `limit` activities and
the client pages them in via loadNextPage, so large boards stay fast without
deleting activity history. Document this so the request is closeable.
Fixes#2539.
The 'Filter by date -> Overdue' and 'list disappears in swimlanes' fixes were
reported originally by email, not as GitHub issues - #6483 and #6484 do not exist
(404). Replace the dead issue links in their Upcoming entries with '(reported by
email)'. The fixes themselves are unchanged.
Thanks to xet7.
Adds tests (with negative cases) for the Upcoming changes that previously lacked
them:
- tests/defaultBoard.test.cjs (#2220): behavioural toggle/decision logic (set,
unset the current default, switch to a different board; negatives: nothing is
the default when unset, B is not the default when A is) + source guards that
the schema, model + server toggleDefaultBoard, once-per-session router redirect,
and board-tile toggle are all wired.
- tests/upcomingUiGuards.test.cjs: source guards for the #6465 Add List header
button + inline composer (leading column replaced by empty-state gating),
minicard white-space (min-height:0) and swimlane-header zoom clip
(overflow:visible/height:auto), and the #6478 touch confirmation before a
cross-swimlane list move (gated on touch/small screen; declining aborts).
The other Upcoming changes already had tests (filterDateNull, listMoveSwimlane,
cardDragSwimlaneScrollRefresh, popupAfterConfirm, undoRedoSelection,
listWidthDefaults, ferretdb* in the FerretDB repo).
Fixes#2220. Fixes#6465. Fixes#6478. Fixes#6479.
Thanks to xet7.
On the All Boards page each board tile gets a home (house) toggle next to the
star. Marking a board sets it as the user's default 'home' board; the next login
(or reload) lands on it instead of All Boards. Clicking again clears it.
- profile.defaultBoardId (per user) + getDefaultBoardId/isDefaultBoard/
toggleDefaultBoard model helpers + a toggleDefaultBoard Meteor method (mirrors
toggleBoardStar).
- home route redirects to the default board ONCE per session (so clicking All
Boards afterwards stays on the list; honoured again next login/reload); by id
so it works before the board subscription loads; graceful fallback if the board
is gone.
- board tile .js-set-default-board toggle + isDefaultBoard helper; i18n
set/unset-default-board-title.
Thanks to xet7.
Per request, the History design now records EVERY change a user makes (not just
card groups) in one append-only changeHistory store, and undo/redo becomes the
keyboard front-end to it (restore the current user's most recent change) rather
than a separate feature - superseding userPositionHistory.
Same table + restore is surfaced from many menus, each just a scope filter over
the one store: card group, whole card, Member settings (per-user), Board Settings
(per-board), Swimlane menu, List menu, and any future entity menu. Scopes nest
(card in list in swimlane in board) via id-column ORs. Added a scoped-views
section, the scope/scopeId page() params, per-scope permissions, and updated the
phasing (migrate position undo/redo onto changeHistory first). Undo.md now points
at History.md as the source of truth for the unified direction.
Thanks to xet7.
docs/Features/Undo/Undo.md documents the #6478 feature: position-move undo/redo
(card/list/swimlane) via userPositionHistory with an undone/undoneAt redo stack,
undoLast/redoLast methods, Ctrl+Z/Ctrl+Y bindings, and the touch confirmation for
cross-swimlane list moves. Records the inert-recording bug (collection referenced
as an un-imported global), the write/read wiring, retention, v1 limitations
(positions only; content undo is the separate History feature) and an extension
checklist.
Thanks to xet7.
Detailed design doc at docs/Features/History/History.md for the requested card
details 'History' feature: per-group history popup with a searchable, paginated
(current page only), per-contributor change table and restore.
Key point: WeKan's Activities log records what happened but NOT before/after
values, so restore needs a new append-only cardGroupHistory content-versioning
collection - the doc specifies the model, write/read (paginated+searchable+
per-user) methods, the 2-pane UI (History + contributor avatars | table with
select/change-type/content/datetime, search+pagination+restore bar), RTL
mirroring, restore semantics (re-logged to both source and restorer; history is
append-only), security, and a phased rollout starting with Description.
Thanks to xet7.
Swimlanes/Lists views no longer render a permanent Add List composer column.
Each list header now has a far-right add-list button; clicking it opens the Add
List composer as a column immediately AFTER that list in the DOM - which appears
to the right of the list in LTR and to the left in RTL (the lists lane is a flex
row that mirrors under dir=rtl). An empty swimlane/board shows the composer at the
start so the first list can still be added.
- new always-open addListInline template (title input + save + close), submit ->
createListAfter (afterListId = the clicked list, swimlaneId = the displayed
swimlane recorded from the DOM by the header button).
- Session 'wekan-add-list-after'/'wekan-add-list-swimlane' drive which list the
composer opens after; isAddListAfter/swimlaneHasNoLists/boardHasNoLists helpers.
- leading +addListForm removed from the non-mini swimlane and listsGroup
branches; mini-screen path unchanged.
First cut - desktop/main views; needs live verification of styling, RTL and the
empty-board case.
Thanks to csonkaoszimt (report) and xet7.
A user accidentally dragged a list into another swimlane on mobile (merging it
with an existing list) and spent ~15 min recovering - no confirmation, no undo.
Undo/Redo: the userPositionHistory collection modelled this but was NOT actually
recording (trackChange guarded on an un-imported global) and had no redo or key
bindings. Now:
- list moves are recorded in updateListSort (import UserPositionHistory so the
guard passes); card moves already had the call.
- add a symmetric redo() model method + an undone/undoneAt redo stack; add
userPositionHistory.undoLast/redoLast methods (a new action clears the redo
stack via trackChange).
- wire Ctrl+Z / Ctrl+Y (and Cmd variants) in client/lib/keyboard.js; disabled
inside inputs/textareas so native text undo is unaffected.
- pure selection logic models/lib/undoRedoSelection.js + tests.
Confirmation: on touch / small screens, moving a list to a DIFFERENT swimlane
(which re-homes every card) now asks for confirmation; a decline reverts the
drag. Same-swimlane reordering is unaffected.
Thanks to mueschel (report) and xet7.
Clicking a .js-confirm button silently did nothing. Popup.afterConfirm() stashed
the pending action as a field on the Blaze DATA CONTEXT and the confirm button
read it back as this.__afterConfirmAction. But the context is a
ReactiveCache/Minimongo document (a board member sub-doc), and Blaze re-renders
the confirmation popup with a fresh/immutable copy of that context, so the field
was gone by click time - so every afterConfirm dialog (remove member from board,
etc.) no-oped.
Store the action on the Popup INSTANCE (Popup._afterConfirmAction) instead, which
survives the re-render; it is still invoked with the confirmation popup's own data
context as this, so this.userId keeps working. The .js-confirm handler also guards
against a missing action instead of throwing. Test tests/popupAfterConfirm.test.cjs
with a negative case reproducing the old context-mutation failure.
Thanks to mueschel (report) and xet7.
Dragging a card from one swimlane to the SAME list in another swimlane dropped
it back in the source swimlane, especially with long overflowing lists. The card
sortable's sort handler auto-scrolls the board (#443) via .js-lists scrollLeft /
.board-canvas scrollTop, but jQuery UI sortable caches container/item geometry at
drag start and only re-caches on its own placeholder moves - never on our manual
scroll. Long lists are exactly what triggers auto-scroll, so the drop resolved
against a stale geometry map and the stop handler's ui.item.parents('.swimlane')
persisted the wrong swimlane.
Re-cache positions with sortable('refreshPositions') whenever the sort handler
actually scrolled - complementing the #2769 DOM-mutation refresh in listBody.js,
which does not fire on scroll. Source-guard test
tests/cardDragSwimlaneScrollRefresh.test.cjs.
Thanks to mueschel (report) and xet7.
The #6465 density change lowered MIN_LIST_WIDTH 270->200 and the default
272->220, but specs/38-fixed-list-width.e2e.js still asserted the old 270 floor:
setFixedListWidth(200) was expected to be REJECTED (it is now valid), and the
anonymous default was expected to be 272. This failed on chromium/firefox/webkit.
Use 150 as the too-small value (below the new 200 floor), update the client MIN
mirror to 200 and the default to 220, and add a POSITIVE case that a width of
210 (>=200 but below the old 270) is now accepted.
Thanks to xet7.
v9.99 was released with the LDAP connection-leak fix, the bundled-FerretDB pool
note and the snap #6476 wait-loop diagnostics. Everything committed after the
v9.99 bump - the QEMU snap build, the #6465 UI density/minicard/dock/swimlane
changes, the #6483 date-filter fix, the #6484 list-move fix, and the #6476
root-cause (FerretDB orphaned-table crash loop) - now sits under a new
# Upcoming section above v9.99 instead of being backdated into v9.99.
Thanks to xet7.
Updates the #6483 note: label ($in), title ($regex) AND date range
($gt/$gte/$lt/$lte) filters are all now pushed down to SQLite in the bundled
FerretDB, so none of them full-scan the board. Dates use SQLite's ->> accessor
for numeric comparison of the stored millis, verified end-to-end.
Thanks to xet7.
Notes that the filter slowness flagged earlier is addressed in the bundled
FerretDB, which now pushes {labelIds: {$in: [...]}} and literal {title: {$regex}}
down to SQLite instead of scanning + matching every card's sjson in Go.
Thanks to xet7.
At e.g. 80% zoom (transform: scale on .board-wrapper) the gray swimlane header
(.swimlane-header) looked cut off: it had overflow: hidden with a fixed
min-height, so once the scaled layout rounded, the bar/text was sliced. Use
overflow: visible + height: auto (keeping the min-height floor) so the header
grows to fit and cannot clip vertically; short swimlane names are unaffected and
a long name wraps instead of being cut.
Speculative CSS fix - verify in the running app at 80% (and check 50%/125%/200%).
Thanks to xet7.
Operator logs (uusijani, a1bert01) showed FerretDB was listening and WeKan
connected, then a startup SyncedCron upsert hit FerretDB error
'table accountslockout.connections_<hash> already exists', which became an
unhandledRejection and exited the process; systemd crash-looped it so the HTTP
port never came up. The real fix is in the bundled FerretDB (collectionCreate
now uses CREATE TABLE/INDEX IF NOT EXISTS to re-adopt an orphaned table). The
snap wait-loop timeout/diagnostics remain useful for the separate 'FerretDB
genuinely not ready' case.
Thanks to xet7.
Several users reported 9.x wastes space vs the older 6.09 layout. Tighten three
density defaults (all overridable; user customizations untouched):
- List width default 272 -> 220px (models/lib/listWidth.js, models/lists.js),
minimum 270 -> 200px here and in the server check (server/models/users.js).
Lists already render the same width by default (resolveListWidth) on private
and public boards; now narrower so more fit. Test updated.
- Board tiles (All Boards page): min-height 100 -> 72px, vertical padding
36/32 -> 24/18px (boardsList.css).
- Card-detail right dock max-width 800 -> 520px (and the wide-screen centred
variant 600 -> 520px) in cardDetails.css, so the opened card no longer takes
~1/4 of the screen.
Thanks to xet7.
A board-wide list has swimlaneId === null and renders under every swimlane. The
list-drop handler computed
isDifferentSwimlane = targetSwimlaneId && targetSwimlaneId !== originalSwimlaneId
but targetSwimlaneId is always the swimlane the list is shown under, and
originalSwimlaneId is null for a board-wide list, so ANY small drag made this
true - it set list.swimlaneId AND moved every card in the list to that one
swimlane, so the list vanished from all other swimlanes (recoverable only by
restoring a backup).
Also require originalSwimlaneId: board-wide lists stay board-wide on a reorder,
while a genuinely swimlane-scoped list can still be moved between swimlanes. Test
tests/listMoveSwimlane.test.cjs, with a negative control that the old target-only
condition rebound a board-wide list.
Thanks to xet7.
Cards without a date store the field as null (that is what the sidebar's noDate
filter matches: {dueAt: null}). The comparison filters build {$lte: now}
(Overdue/past) and {$gte, $lte} (today/this/next week), and $lte MATCHES null
under both FerretDB and minimongo - null sorts before any date and neither
implements MongoDB type-bracketing - so Overdue selected every dateless card.
DateFilter._getMongoSelector now adds $ne: null to any comparison selector so
only real dates match; the noDate filter (a bare null) is unchanged. Test
tests/filterDateNull.test.cjs, with a negative control proving the old bare
{$lte: now} matched null.
The reported filter SLOWNESS and the title/label over-matching are separate
(FerretDB scanning $regex/$in/range queries not pushed down to SQLite) and need
live reproduction.
Thanks to xet7.
The minicard title renders inside a .viewer, which inherited the global
.viewer { min-height: 2.5vh } (client/components/main/layouts.css). On tall
screens that reserved a tall empty band beneath a one-line title, so a large
part of every minicard was blank and fewer cards fit on screen. The minicard
title .viewer now sets min-height: 0 (the same override already applied to the
label .viewer), so a minicard collapses to fit its content.
Thanks to xet7.
The Launchpad 'snapcraft remote-build' legs for ppc64el and s390x ended in
Launchpad state 'Stopped' with no snap produced, yet remote-build still exited 0;
the job's name-only success check let an empty/stale file through and the upload
died with ''wekan_<v>_<arch>.snap' is not a valid file' (exit 64). Build them
instead with docker/setup-qemu-action + diddlesnaps/snapcraft-multiarch-action on
a normal runner - fast, because the snap is bundle-centric (the wekan part only
downloads the prebuilt wekan-<version>-<arch>.zip and repackages it, no native
compilation).
riscv64 stays on Launchpad (the QEMU snap action does not support it) but now has
timeout-minutes: 180 so a stuck build fails with a clear message instead of
GitHub's silent 6-hour cancel.
Thanks to xet7.
With database=ferretdb, snap-src/bin/wekan-control waits for FerretDB to accept
connections before starting node - WeKan does not open its HTTP port until the
database answers. That wait loop had no timeout and no diagnostics, so if
FerretDB never started listening (crashed or arch-incompatible per-arch binary,
locked/corrupt SQLite, or the service left disabled by a failed migration
hand-off), WeKan blocked there forever: the service showed active but the port
never opened and the only symptom was a silent 'FerretDB not ready yet' loop.
uusijani's wekan.log stopped right after the startup env dump, confirming
control never reached node main.js.
Mirror the MongoDB branch: after WEKAN_DB_WAIT_TIMEOUT seconds (default 120,
overridable) print an actionable hint once, then keep retrying - pointing to
'snap logs <snap>.ferretdb', naming the SQLite dir to check for locks/corruption,
the arch-mismatch case, the snap start --enable recovery, and the
'snap set <snap> database=mongodb' fallback. Regression test
tests/ferretdbWaitTimeout.test.cjs, including a negative guard that the wait is
not a silent unbounded loop again.
Thanks to uusijani (report) and xet7 (fix).
tx pull -f fills any string untranslated on Transifex with the English source, so
languages whose translations live only in git silently revert to English on every
pull. Make the pull self-heal, and fix the push helpers so restored translations
actually upload.
- pull-translations.sh: after the pull, for each language file whose changes are
ENTIRELY reverts, git checkout HEAD -- <file> to restore the committed
translations and force-push them back (../tx push -t -l <lang> -f). Files that
also carry a real new/updated translation from Transifex are NOT auto-healed
(a whole-file checkout would discard it) and are left for manual handling.
- report-english-regressions.mjs: add a machine-readable --files mode and an
otherChanges classifier, so only pure-revert files are offered for auto-heal;
the human report tags mixed files.
- push-translation.sh: add -f (without it the Go tx CLI skips a language whenever
the local file is not newer than the server copy - push.go shouldSkipPush - so
a freshly reverted file uploads nothing), plus a usage guard.
- push-copy-en-gb-translation.sh (new): copy en.i18n.json to en-GB.i18n.json
verbatim and force-push it as the en_GB translation, so British English shows
as translated instead of reverting to the English source on each pull.
Thanks to xet7.
Operators reported that after an update WeKan "dies really quickly", restarts
did not help, and it "kills our openldap server with too many open connections";
others saw logins hang for minutes then fail with "Must be logged in". Every
LDAP login attempt (loginHandler.js) and every background sync tick (sync.js)
created a new LDAP() and connect()ed but NEVER called disconnect() on any path,
so each attempt - including every failed login and every one-minute sync tick -
leaked a socket to the LDAP/AD server until it hit its connection limit and
started refusing connections, taking it and all WeKan logins down.
Guarantee release on every exit path: a shared runWithLdapDisconnect() helper
(connectionGuard.js) disconnects in a finally; the login handler runs its whole
flow through it; background sync() disconnects in a finally; importNewUsers()
disconnects only the connection it owns; and LDAP.disconnect() is a safe no-op
when connect() was never reached. Adds behavioural + negative + source-guard
tests (tests/ldapConnectionRelease.test.cjs, wired into test:unit:node).
Also bumps the bundled FerretDB whose SQLite pool no longer caps MaxOpenConns
at 16 (that starved WeKan's cursor load: minutes-long board loads, failed
logins).
Thanks to xet7.
Document the two GitHub CodeQL code scanning fixes already committed
(alerts #423 js/incomplete-sanitization and #422
js/biased-cryptographic-random) in a new Upcoming section above v9.97,
linked to the wekan.fi Hall of Fame entries.
Thanks to GitHub CodeQL and xet7.
256 is not a multiple of the 55-character id alphabet, so the plain
byte % 55 mapping skewed generated document ids toward the first
characters. randomId now uses rejection sampling: bytes at or above the
largest multiple of the alphabet size (220) are discarded and resampled,
so every character is equally likely. Ids stay Meteor-style 17-char and
exact-length for custom lengths. Resolves code scanning alert #422.
Tests: tests/schemaUpgradeSteps.test.cjs gains a rejection-sampling
guard (negative case pins that out-of-range bytes are never wrapped).
Thanks to xet7.
The CSS-declaration-to-RegExp conversion escaped only parentheses;
escape the full regex metacharacter set (including backslash) instead.
Resolves code scanning alert #423. Test-only, fixed input list, but the
complete escape is correct and matches the pattern already used in
tests/archiveLinkGrouping.test.cjs.
Thanks to xet7.
Every deletion path (admin removeUser method, self-service account
delete, DELETE /api/users/:userId) removed only the users document,
leaving dangling references everywhere: empty-avatar board members that
could not be removed, stale card members/assignees/watchers, orphaned
avatar files - reproducible for 8 years and reopened in 2025. A
server-only Users.after.remove collection hook now prunes
boards.members/watchers (object-shaped, $pull by userId),
cards.members/assignees/watchers and lists.watchers (string arrays), and
the user's Avatars files, on EVERY path that removes a user; a cleanup
failure can never break the deletion itself. Activities and comments are
deliberately preserved for history - their rendering is already
null-guarded (270eacb20, Playwright-verified).
Tests: tests/userDeletionCleanup.test.cjs (6, positive and negative,
end-to-end against a fake database).
Thanks to chotaire and xet7.
Drag start hid every list's "+ Add Card" composer link with
display: none, collapsing its row: lists shrank, auto-height swimlanes
shrank, and every swimlane below jumped up about one row (and back down
on drop), moving the drop target under the cursor mid-drag. The root
cause was proven by frame-diffing the issue's own GIF: the three largest
frame discontinuities are exactly drag start and drop, showing the
composer row vanish and the next swimlane header shift ~23px. The
composer now hides with visibility: hidden, preserving its layout box;
checked multi-selection cards keep display: none intentionally (the drag
payload previews the post-drop list).
Tests: tests/swimlaneDragJump.test.cjs (8, positive and negative,
including a guard that flags any return of the layout-collapsing rule).
Thanks to gerroon and xet7.
off-screen list.
The horizontal auto-scroll in the card sortable targeted .board-canvas,
which stopped overflowing horizontally when the swimlane layout made the
.js-lists lane the horizontal scroller - scrollLeftMax was always 0, the
guard compared 0 < 0 and never fired, and ui.helper[0].offsetLeft -= 15
assigned a read-only property. Edge-proximity auto-scroll now drives the
lane actually under the pointer (axis-agnostic, clamped, overshoot-safe
helpers in imports/lib/boardAutoScroll.js), with vertical scrolling kept
on the board canvas.
Tests: tests/boardAutoScroll.test.cjs (15, positive and negative,
including a reproduction that the old no-overflow target can never
scroll).
Closes#603: obsolete - the stale-drop-target cause was removed by
d887e553c (perfect-scrollbar removal, native list scrolling),
ed8471be9 (sortable auto-scroll re-enabled) and jQuery UI 1.14.2, whose
sortable resolves insertion neighbours with live offsets on every
mousemove, so a scrolled target list cannot desynchronize drop targets.
Thanks to anhenghuang, AlexanderS and xet7.
Sandstorm username races.
- #2345: the Card Title Filter is now SAVED by every board trigger
builder (a trigger doc missing the field could never satisfy the
matcher's $in - those rules fired for nothing), SHOWN in the rule
details, and ENFORCED for archive/restore triggers by resolving the
title from the card when the activity lacks it; legacy field-less
triggers keep matching; the filter popup prefills its current value.
- #2674: rules created via POST/PUT /api/boards/:boardId/rules never
fired - missing matching fields are now normalized to '*' wildcards
and trigger/action types validated; the addMember/removeMember rule
actions no longer crash on unresolvable usernames or member-less
cards and their writes are awaited. New docs/API/Rules.md (endpoints,
matching fields, wildcard semantics, the exact two-rule
add-on-move-to/remove-on-move-from workflow), linked from REST-API.md;
api.py help now lists the rule commands with the same example.
- #574: Sandstorm unique-username generation probes case-insensitively
(anchored, regex-escaped) and retries the next number when a
concurrent insert wins the unique-index race, instead of aborting the
login hook with E11000.
Tests: tests/rulesCardTitleFilter.test.cjs (12),
tests/rulesApiTriggerNormalize.test.cjs (19),
tests/sandstormUsername.test.cjs (11) - positive and negative cases.
Thanks to InfoSec812, sfahrenholz, mitar and xet7.
Inviting by email derives the new user's username from the email local
part; a collision with an existing user (cats@foo.com then
cats@facebook.com) made Accounts.createUser throw Meteor's raw
"403 Username already exists", shown to the inviter as just "403". The
username now probes cats, cats1, cats2, ... to the first free variant
(bounded), and exhaustion raises the translated error-username-taken.
Tests: tests/inviteeUsername.test.cjs (11, positive and negative,
including the literal reported scenario).
Closes#804: already fixed - every popup is viewport-clamped with
internal scrolling since ac368de06 (#5667 geometry rewrite: maxHeight
from live viewport space, bounded flex layout) plus the 04eb8a8fb
(#6221) global 90vh clamp; the member picker inherits the shell, so
neither standalone nor the Sandstorm iframe can grow past the viewport.
Thanks to lemoer, ocdtrekkie and xet7.
The due-date picker configures defaultTime 17:00 (received/start/end use
now()), but an inverted guard in datePickerRendered applied it only when
the card ALREADY had a date - the one case where it is unnecessary - so
for dateless cards the time input stayed empty and submit stored a
hard-coded 12:00. Empty pickers now pre-fill with the configured
default, submit falls back to it, and existing dates keep their own
time. The 2018 AM/PM display/parse mismatch was already fixed by the
native HTML date/time inputs (79b94824e); week start already honors the
user preference.
Tests: tests/datePickerDefaultTime.test.cjs (10, positive and negative).
Thanks to Vlasterx, saschafoerster, suncobran and xet7.
- #2769: refresh drag geometry when the DOM changes mid-drag - cards no
longer drop into the wrong swimlane while someone adds a card.
- #1992: board import restores all five card date fields (and creator)
with fallbacks; receivedAt/endAt were never imported at all.
- #2292: archiving a swimlane archives its cards (mirroring lists);
restore brings back exactly the cards archived with it.
- #2494: client noCache card lookup returned a Promise since the
Meteor 3 port - multi-select board moves wrote sort: NaN everywhere.
- #1853: subtask "View it" falls back to the subtask's boardId when the
deposit board is not loaded, instead of silently doing nothing.
- #1554: restore the reactive dependency lost in 7673c77c5 so cards
added after board render accept sidebar label/member drops.
- #2306: "filter to selection" and every bulk action are board-scoped;
foreign-board cards can no longer be silently archived.
- #1437: new POST /users/logout API endpoint revokes the presented
resume token, or all tokens with {"all": true}.
All with positive+negative regression tests (see tests/*.test.cjs).
Closes#1389: already fixed - the standalone pencil edit button
(0cc63b810) plus the wrapped viewer (bf2b3b40c) guarantee an edit target
even when a full-width link fills the description.
Thanks to hever, Cactusbone, Vermeille, Vanclief, Miffe, IcedQuinn,
ppouliot, GhassenRjab and xet7.
Since 8c3ce4bb7 (2021) the "close the previous inlined form" call was a
silent no-op: the inlinedForm escape action registers with
enabledOnClick: false and EscapeActions.clickExecute skips such actions,
so clicking another checklist item left both edit forms open - and the
submit handlers find the template's FIRST textarea, so the wrong form's
text was saved over the submitted item. Subtasks reproduced the full
bug; the checklists workaround corrupted the shared open-form tracker so
Escape fell through and closed the whole card details pane. A pure state
manager (client/lib/inlinedFormManager.js) now enforces the single-open
invariant: opening a form closes the tracked previous one (popups
untouched, preserving the 2021 intent); close/destroy only reset the
tracker for the form they own.
Tests: tests/inlinedFormSingleOpen.test.cjs (9, positive and negative,
including the exact reported A->B->C repro).
Thanks to Beebo89 and xet7.
Two defects: the tokenizer flipped into regex mode on every '/' even
inside quoted strings, so a quoted date like '06/04/2020' broke
tokenizing and the whole filter silently no-opped; and date custom
fields store Date objects while the comparison selectors used strings
and parseInt - equality and ranges could never match, != matched every
card. Dates now parse per the user's date format (day-first formats
respected) into half-open Date-range selectors; non-date fields keep the
legacy selectors unchanged.
Tests: tests/advancedFilterDate.test.cjs (14, positive and negative).
Closes#2521: already fixed since v3.88 (9819c9f80) - the checklist
completed/uncompleted activity text was missing due to an activityType
name mismatch between model and template; the current unified activity
template, i18n keys and helpers render it correctly.
Thanks to k1ng440, ott29 and xet7.
addSubtaskCard inserted every subtask card with the constant sort -1,
leaving the whole list tied: a drop between two equal sorts computes a
zero increment, the move modifier is empty and Card.move() silently
discards it - the card snapped back, and a multi-selection drop wrote
the SAME sort to every selected card, permanently destroying their
relative order (the data-loss risk in the issue triage). Subtask cards
now append with a unique sort (max+1), and the sortable stop handler
detects degenerate gaps (ties/inversions) and repairs the siblings'
sorts to a strictly increasing order before recomputing the drop index;
healthy lists take the unchanged fast path.
Tests: tests/subtaskCardReorder.test.cjs (14, positive and negative,
including the exact issue scenario and a guard that the old
{base:-1, increment:0} result can never be produced again).
Thanks to jayki and xet7.
- #3453: publish the FULL subtask ancestor chain, not only direct
parents - the cross-board full-path label vanished after refresh.
- #3748 (defect half): skip unresolvable custom-field definitions on
linked cards - phantom empty rows and a template TypeError on every
card details render. The mirroring itself is by design: linked cards
are pointers; label/custom-field ids are board-scoped; name-based
inheritance is the copy feature, not the link feature.
- #3199: group each archived card with its own Restore/Delete links and
add a clear separator below the group (RTL-safe, theme-neutral).
- #3843: comment-editor uploads and the attachments popup now share one
null-safe meta builder, and tests pin that comment attachments list in
the card's Attachments section.
Closes#3748: mirroring is by design (see above); the only actionable
defect is fixed in this commit.
Closes#3378: already fixed - notification_cleanup moved off SyncedCron
to a guarded Meteor.setInterval singleton, and quave:synced-cron 2.4.0
handles the E11000 history collision that percolate 1.5.x missed.
Closes#3276: already fixed by d3625db75 - the spent-time badge helpers
now read the live Cards document reactively, so the overtime color flips
immediately; verified behaviorally against the real component.
Closes#3843: behavior verified present and now regression-locked.
Thanks to MPeti1, peterbecich, fxkr, jghaanstra and xet7.
The maximized card pane had no position of its own, so it remained an
in-flow item inside the scrolled board canvas and rendered off-screen
after scrolling down; desktop-mode floating-window rules also overrode
every maximize geometry rule, and inline drag offsets survived
maximizing. The pane is now viewport-fixed with insets that win over
both (drag position restores on minimize), RTL-safe. Regression test
with a CSS cascade resolver that fails on the pre-fix stylesheet:
tests/maximizedCardPosition.test.cjs.
Closes#3566: mobile shows one list at a time by design (xet7's own
comments in the issue); Move Card popup is the supported flow, and the
2021-era touch drag glitches were since fixed with drag handles.
Closes#3252: already fixed - comment deletes are guarded in
client/components/activities/comments.js (tagged #3252), checklists in
checklists.js, attachments via #5282.
Closes#3542: no code bug - redirect_uri is the same expression on the
client and server (mismatches come from ROOT_URL/proxy configuration,
per the Bug:Environment-specific label), and the login-style half was
fixed via #5695.
Thanks to pravdomil, 1ubuntuuser, gastoncollaud and xet7.
- CHANGELOG.md: Upcoming entries for the LDAP group filter fix (#4036),
invitation code regeneration (#4043), CJK add-card footer wrapping
(#4023) and team-to-board member sync (#4593), whose code shipped in
the previous commit.
- server/models/users.js: do not delete the invitation code in
onCreateUser before the account insert is committed - a failed insert
(duplicate username/email) burned the code for every retry (#4043).
Consumption happens after a successful insert; re-invites regenerate
stale codes.
- tests/teamBoardMemberSync.test.cjs: the #4593 regression tests (13,
positive and negative) for the team board-member sync helpers.
Thanks to zeisss-mercedes, jkoenig134, yuki-snow1823, Sylvain2703,
szymonsztuka and xet7.
#5695#4897#4654#5174#4825#5659#4730#4419#4158#4560#4036#1959#1971.
- Startup schema upgrade (server/lib/schemaUpgradeSteps.js): on start,
check that data from EVERY old WeKan version is migrated to the newest
structure and migrate only what is missing - all platforms, MongoDB and
FerretDB. Version-gated (marker stores WeKan version + datetime of the
last re-check; one findOne per boot until a new release), non-blocking,
live dashboard at /schema-upgrade-status showing the product name, fast
on big databases (distinct() set-joins, updateMany batches). Steps:
archived-flag backfill, swimlane structure + visibility rescue
(#1959#1971: cards under deleted/archived/foreign swimlanes reassigned
to a visible swimlane; card-insert hook validates supplied swimlaneIds),
merge-per-swimlane-lists (v7.98/v8.0x list copies merged back into
shared lists: no duplicate columns in Lists view, everything visible in
Swimlanes view, cards keep their swimlane), embedded checklist items,
customFields boardIds, allows* backfills, members isActive, permission
lowercase, filesystem path healing.
- Migration speed (5-hour reports): insertMany batches in the text phase,
preloaded target-record maps in the file phases.
- Snap attachment-repair + FILES_ONLY importer mode (see prior commit
wiring) extended with CFS FileSystem-store coverage
(ATTACHMENTS_STORE_PATH era), missing-binary reporting, and
migrate-gridfs-to-fs.mjs bucket fixes.
- OAuth2/OIDC: OAUTH2_LOGIN_STYLE=redirect honored (#5695); concurrent
logins no longer contaminate each other's user data (#4897); account
merge no longer wipes avatars/templates (#4560).
- LDAP: background sync fixed (#4654), password login rejected after LDAP
migration (#4419), LDAP_ENCRYPTION=true actually encrypts (#4158),
group filter accepts multiple groups and admits admin-sync groups
(#4036).
- All Boards tiles: per-list card counts + member avatars restored
non-reactively (#5174#4825). Uniform default list widths (#5659).
Declined invitations no longer resurrect membership (#4730).
- Tests with negative cases for every fix (tests/*.test.cjs; suite green
except the pre-existing environment-only htmljs failure).
Closes#5600: OAUTH2_CA_CERT already works - the fetch migration
(49a272d6c) applies the CA to all OIDC calls via https.Agent.
Closes#3828: board members seeing all board cards is by design (no
per-card visibility model), and organizations/teams now exist.
Thanks to mueschel, ArturRuta, gerardo-junior, fabianrbz, Miuler,
butteredCat-2021, Griiimm, preciousamorc, farwayer, LeoLu-eng, hnb1,
rangersdo and xet7.
- Migration importers: resolve the CollectionFS GridFS id from
copies.<bucket>.key too (the REAL old-WeKan layout; only
original.gridFsFileId / gridFsFileId / copies.gridfs.key were tried,
none of which exist there) via a shared resolveCfsGridFsId() in
releases/migrate-mongodb-to-ferretdb.mjs,
snap-src/bin/migrate-mongo3-to-ferretdb.mjs and
snap-src/bin/migrate-gridfs-to-fs.mjs. The modern importer now drives
CollectionFS extraction from cfs_gridfs.<bucket>.files itself, so a
missing/empty cfs.<bucket>.filerecord no longer silently skips every
file; binaries without a filerecord are still extracted to disk, and
filerecords whose binary cannot be located are reported on the
dashboard instead of dropped.
- Meteor-Files phase: match versions.*.meta.gridFsFileId without a
storage flag (WeKan's own getFileStrategy rule), handle every version
(not just 'original'), and add a bucket-driven sweep of <bucket>.files
by metadata.fileId so binaries are recovered even when the record's
flags say nothing about GridFS. GridFS-flagged versions with no
locatable binary are reported.
- mongo3 importer: copy the CollectionFS top-level boardId/cardId/
listId/swimlaneId/userId into meta on the created records - an
attachment without meta.cardId shows on no card.
- Admin Panel > Attachments: the Filesystem Storage paths were computed
from process.env.WRITABLE_PATH IN THE BROWSER, so they always showed
"/data". New admin-only getAttachmentStoragePaths method returns the
real Snap-aware paths (shared models/lib/attachmentStoragePath.js),
also used for the settings document default (was /data/attachments,
actual Docker path is /data/files/attachments).
- Snap: `snap run wekan.database ferretdb` now says it does NOT migrate
data, says when nothing was switched, and points at
`snap run wekan.migrate` for re-running the full migration.
- Tests with negative cases: tests/migrationAttachmentExtraction.test.cjs
(behavioral resolveCfsGridFsId from all three importers + wiring
guards) and tests/attachmentStoragePath.test.cjs, wired into
test:unit:node.
- Companion fix in wekan/FerretDB: accept documents with literal dotted
field names like MongoDB 3.6+, so migrated documents containing them
are no longer silently dropped.
- CHANGELOG.md: new Upcoming section with these changes.
If attachments are already missing after an earlier migration, run
`snap run wekan.migrate` - the source MongoDB data was never modified,
and the fixed importers re-create the attachment records and files.
Thanks to mueschel and xet7.
The right-docked card details window exposed two real issues in the
Playwright run (03-cards-operations failing in all three browsers):
- Archiving or deleting a card left its id in the openCards session
list, so the floating details window kept rendering above the board —
and, docked to the right edge, exactly over the archives sidebar,
intercepting its Restore/Delete clicks. Both handlers now drop the
card from openCards and clear currentCard.
- An OPEN board sidebar now stacks above the card window (z-index 2002
vs 2001), so the sidebar is always usable while a card is open.
Also from the same run: the new one-click cog spec closed its popup with
a keyboard Escape that proved unreliable across engines — it now uses
the popup's own X button (.js-close-pop-over) like 19-accessibility
does. The chromium-only 33-board-domains failure is an unrelated
token-login race in the auth helper (userId mismatch), not caused by
these changes.
tests/uiDensity.test.cjs got guards for both follow-ups (openCards
cleanup in archive+delete, sidebar z-index above the card window).
Updated ChangeLog.
Thanks to xet7.
tests/ferretdbHasData.test.cjs runs the real snap-src/bin/ferretdb-has-data
against crafted directories. This guard gates two critical switches
(migration-control's finish_success and mongodb-control's #6458/#6466
failure handler), so its semantics must never drift. Positive: non-empty
.sqlite, no -wal sidecar required (clean shutdown checkpoints it away),
one good file among empties. Negative: 0-byte .sqlite from a failed
migration, empty/missing directories, -wal/-shm-only leftovers, and a
DIRECTORY named *.sqlite. All eight behaviors verified against the
actual script. Wired into test:unit:node; ChangeLog updated.
Thanks to xet7.
The 2026-07-16_18-33-28 test run failed one spec in all three browsers:
the #6465 one-click board-settings cog added a second .js-open-board-menu
element, so 03-cards-operations' bare class locator resolved to 2
elements and tripped Playwright's strict mode. The archives test now
scopes the click to the sidebar's instance (.board-sidebar
.js-open-board-menu), keeping its 'from inside the sidebar' intent.
Also added a spec for the new cog itself to 15-board-actions: visible in
#header-main-bar, popup not open before the click (negative), ONE click
opens the real boardMenu popup (.js-open-archives inside), Escape closes
it again.
Thanks to xet7.
tests/cpuExecWiring.test.cjs, with negative cases: every Linux bundle in
release-all.yml embeds cpu-exec + its own arch's static qemu-user (arm64
and the QEMU-built extra arches replace the inherited amd64 one, extra
arches tolerantly), the Windows/macOS bundles strip both Linux-only
files, qemu-user-static is installed in every bundle-building job and
both sandstorm jobs, the Sandstorm .spk ships cpu-exec + qemu via
build-deps.sh (tolerant when qemu is not installed), the Docker
entrypoint and the bundle launcher route ferretdb/node through cpu-exec
while keeping direct-exec fallbacks for bundles that lack it, and the
snap ships cpu-exec via the snap-src helpers part. Wired into
test:unit:node; complements tests/cpuExec.test.cjs (the script's own
behavior).
ChangeLog Upcoming: the regression-tests entry now lists the cpu-exec
wiring test, the subtasks default-board test (#6456) and the FerretDB
fork's integration-test fixes.
Thanks to xet7.
Fixes#6456.
The lazily-creating getters for the default subtasks helper board and
its landing list still used the sync Boards.insert / Swimlanes.insert /
Lists.insert / Boards.update APIs that Meteor 3 removed from the server,
so creating a subtask crashed with 'insert is not available on the
server. Please use insertAsync() instead' whenever the ^Board^ helper
board had to be created. The list creator additionally read
getDefaultSwimline()._id, which is a Promise on the Meteor 3 server.
- getDefaultSubtasksBoardId / getDefaultSubtasksListId are now PURE
getters (no creation), matching the #3868/#2256 rule that only the
server may create these.
- The server-side lazy creation moved into getDefaultSubtasksBoardAsync
and getDefaultSubtasksListAsync using insertAsync/updateAsync and
getDefaultSwimlineAsync — the exact path addSubtaskCard uses.
- The never-called date-settings twins had the same sync calls and no
server-only guard at all; they are pure getters now too.
- tests/subtasksDefaultBoard.test.cjs guards the async creators and that
no sync collection writes come back to models/boards.js, wired into
test:unit:node.
- Updated ChangeLog.
Thanks to sjohnen and xet7.
That commit's message listed all ten issues after a single Fix keyword,
but GitHub only auto-closes a reference that directly follows its own
closing keyword, so only the first issue was closed on push. Closing
the rest here; the fixes themselves are already on main.
Fixes#6455. Fixes#6458. Fixes#6466. Fixes#6467. Fixes#6468.
Fixes#6472. Fixes#6465. Fixes#5547. Fixes#5282.
Thanks to xet7.
Fix#6458 completely: the reporter's host runs inside a hypervisor that
masks AVX, and the old per-tool AVX wrappers (amd64-only, PATH-based)
were bypassed by absolute-path mongod invocations.
- New general snap-src/bin/cpu-exec: runs any binary directly when the
CPU has the features it declares (--features x86_64=avx,aarch64=atomics
or WEKAN_REQUIRED_CPU_FEATURES) and through same-arch qemu-user when
not; plain zero-overhead exec with no declared features. Lookup order:
WEKAN_QEMU_USER, qemu-<arch> next to the script (bundle/Docker),
$SNAP/qemu-<arch>, the snap's migratemongo/avx one, then system
qemu-user(-static). Clear error + direct run when no qemu exists, so
the real SIGILL surfaces instead of hiding.
- Snap: mongodb-control and migration-control run every mongod 7 through
cpu-exec, so MongoDB works without AVX (slower) and migration can READ
modern MongoDB data on such CPUs; completed-FerretDB switch and
migration fallbacks unchanged (switch_to_completed_ferretdb extracted).
- release-all.yml: every Linux bundle .zip ships cpu-exec + this-arch's
static qemu-user (amd64/arm64/ppc64le/s390x/riscv64; stripped from
win64/mac bundles), flowing into Docker and Snap automatically;
Sandstorm .spk gets both via build-deps.sh. Bundle launcher and Docker
entrypoint route node/ferretdb through cpu-exec.
- Docs: mongodb-avx-qemu.md and mongodb-raspi4-qemu.md document the
built-in mechanism.
Tests, with negative cases, for the newest features and fixes at
changelog: htmljs array-vs-attributes (#6459), description draft
normalize/reset (#6455), comment draft lifecycle (#5547), attachment
delete guard (#5282), rules move actions + import normalization (#6472),
snap mongod-failure/migration recovery (#6458#6466), FerretDB polling
defaults (#6467#6468), UI density guards for every #6465 fix, and a
behavioral cpu-exec test against fake cpuinfo + fake qemu. All wired
into test:unit:node. Go table tests for the FerretDB SQLite filter
pushdown are in the wekan/FerretDB repo.
Updated ChangeLog.
Thanks to xet7.
- #6459: card More menu rendered empty (no Delete): the vendored jade
compiler's htmljs patch made isConstructedObject(Array) false, so
'label {{_ ...}}:' lines got their content array mis-assigned as tag
attributes and Blaze threw 'foreign objects in attributes' killing the
whole cardMorePopup. Also fixed the list More link input (nonexistent
rootUrl helper -> absoluteUrl).
- #6455: saving a card description never removed a pre-existing unsaved-
edits record, and the draft/description comparison mismatched on Markdown
hard-breaks and empty descriptions, re-creating a phantom draft on every
save. Save now clears the draft; both sides normalized the same way.
- #5547: comment drafts: the draft-saving escape handler had been disarmed
since 2019 (flag with no setter), so a comment being written was lost
when the card closed. Drafts are now saved continuously (debounced),
flushed on teardown, cleared on submit; text no longer visually vanishes
on outside clicks.
- #5282: attachment delete: guard against the doc being already evicted
from Minimongo ('Removed nonexistent document'), like the existing
comment/checklist guards.
- #6472: rules move card to top/bottom: fall back to the card's current
list when listName does not resolve (was a swallowed TypeError = rule
silently did nothing); wizard stored listTitle which the engine never
reads (listName); empty destination wrote sort +-Infinity; rules JSON/CSV
import now uses the rules.createRule method instead of client inserts
rejected into minimongo limbo, and defaults missing trigger matching
fields to '*'; empty boardId no longer overrides the real board; the
server-side orphaned-cards fallback in List.cards()/cardsUnfiltered()
now actually resolves its async swimlane lookup.
- #6465: desktop density back to WeKan 6.09: base font 14px and headings
22/18/16px (vw clamps resolved to 18/24px on desktop), All Boards
wrapper padding 10px/15px, card details docks to the right edge instead
of floating on top of its own card (still draggable), 20px canvas
padding instead of ~48px white borders, removed the force-all-card-text-
to-title-size rule, admin org/team table Select/Unselect-all header
links are compact icons and header cells may wrap, zoom pill no longer
cut off, one-click board settings cog in the board header.
- #6458#6466: snap: mongodb-control now checks mongod's exit status and
does an AVX pre-flight (MongoDB 5+ needs AVX; without it mongod SIGILLs)
instead of pinging a dead port forever behind a 502: it switches to a
completed FerretDB migration, or (re)runs the migration (AVX-free) with
a 3-attempt guard. Migration importers no longer fail the whole run on
>=10 per-item errors ('Avatars Errors' etc.), and a failed 3.x-source
migration keeps the copied FerretDB data + checkpoint and resumes next
start instead of deleting it and 'falling back' to a mongod 7 that
cannot open 3.x data files.
- #6467#6468: with FerretDB, calm Meteor's no-oplog polling storm
(METEOR_POLLING_THROTTLE_MS=2000, METEOR_POLLING_INTERVAL_MS=30000
defaults in the snap and bundle launcher; overridable). The FerretDB
fork gets filter pushdown, a sane pool size and less locking in its own
repo.
- Updated ChangeLog.
Thanks to xet7.
Follow-up to PRs #6469 and #6470:
- The login-time org/team sync now clears the inherited method invocation
context (DDP._CurrentMethodInvocation.withValue) around a normal
Meteor.callAsync, instead of invoking the raw method handler with a
hand-made invocation object. This goes through Meteor's normal method
dispatch (check() argument audits, EJSON argument cloning) while still
being the server-to-server path (connection null) that the admin guard
in setUserOrgsTeamsFromLdap allows.
- Added the ddp package dependency to wekan-ldap for the DDP symbol.
- Fixed indentation in localizeAvatarFromBuffer and restored the comment
explaining the proceedAfterUpload argument.
- Removed a stray double blank line in the LDAP login handler.
- Updated ChangeLog about the merged LDAP fixes.
Thanks to xet7.
Added a build-sandstorm job that runs after the GitHub Release is created,
with the same steps as the standalone sandstorm.yml workflow (which still
exists for testing the .spk build on its own), attaching
wekan-<version>-sandstorm.spk to the Release. Non-blocking, so the
experimental Sandstorm build never fails or delays the release.
Thanks to xet7.
Both snap jobs (snap-native and snap-launchpad) pushed only to candidate, beta
and edge, and stable had to be released by hand afterwards. Publish to
stable,candidate,beta,edge instead. base: core24 allows stable and candidate.
Thanks to xet7.
A big migration can run for 5 hours, so being interrupted by a snap refresh,
`snap stop` or a reboot is normal - but it was treated as a failure, and every
interruption threw away all of the work.
Distinguish interrupted from failed. snapd's SIGTERM killed the importer, bash
resumed at the line after the importer call, read the signal exit code (143) as
"the migration failed", and fail_and_run_mongodb deleted the partial FerretDB
SQLite and set migrate=off. Now a SIGTERM/SIGINT trap (and an importer exit code
>= 128, since snapd signals every process in the service cgroup) keeps the
partial database and the checkpoint, leaves auto-migration on, and hands back to
mongodb-control so WeKan keeps serving from MongoDB until the next start resumes.
Both importers flush their checkpoint on the signal and exit 128+signo.
Checkpoint files, not just collections. Only fully-copied collections were
checkpointed; the file phase started over. Worse, the destination path was picked
with an "append _1, _2, ... while the file exists" loop, so every already-
extracted attachment was written a second time under a new name, orphaning the
first copy - a resumed migration silently needed twice the disk the up-front
space check budgeted for. Files are now checkpointed individually (recorded only
once the bytes are on disk AND the record points at them, and re-verified by size
on resume, so a half-written file is never mistaken for a finished one) and
skipped when resuming. The path is now deterministic: idHex is the record's _id,
so two records never collide and an existing file there can only be this record's
own partial extraction, which is meant to be overwritten.
Discard the checkpoint together with the SQLite it describes. The checkpoint
lives in $SNAP_COMMON, not in the SQLite dir that discard_partial_ferretdb wipes,
so it survived. The next migration then trusted it, skipped every "already
migrated" collection, copied only the rest into the now-empty database, and
reported success - leaving the snap serving a FerretDB missing most of its data.
The MongoDB 3 importer had no checkpoint at all and now resumes collections and
files the same way. The source MongoDB data is never touched on any of these
paths.
Thanks to markusst1982 and xet7.
Meteor's accounts-base "resume" login handler projects a single array element
with the positional operator:
Meteor.users.findOneAsync(
{ 'services.resume.loginTokens.hashedToken': hashedToken },
{ fields: { 'services.resume.loginTokens.$': 1 } })
FerretDB rejects that find with "Executor error during find command :: caused
by :: positional operator '.$' couldn't find a matching element in the array"
(code 51246).
Resume is how every already-logged-in browser re-authenticates on page load and
on every DDP reconnect, so the throw logged users out, the client retried the
connection, and the retry loop pinned the FerretDB CPU - the board looked broken
right after a migration that had just taken hours.
Replace the handler with one that projects the whole loginTokens array and picks
the matching token in JS. Upstream already does exactly this in its own $or
fallback query ("Cannot use ...loginTokens.$ positional operator with $or
query"), so the array is known to be small enough to fetch, and behaviour is
otherwise unchanged - including looking up the hashed token on its own first so
the unhashed token is not sent to the database unless it has to be.
Closes#6457
Thanks to markusst1982 and xet7.
9.93 is released, so move the two commits made after it into a fresh
"# Upcoming WeKan ® release" section above v9.93, organized like the previous releases:
Features: database setting authoritative + snap run wekan.database mongodb|ferretdb +
no-downtime handling of a failed migration.
Bugs: migration skips dotted (GridFS/CollectionFS/system) collections that FerretDB
rejects, and cleans up a partial SQLite from a failed migration.
No entry text changed; only relocated.
Problem: the control scripts force-switched to FerretDB whenever a *.sqlite file existed, so
`snap set wekan database=mongodb` did not stick and a failed migration caused downtime with no
way to keep WeKan running on MongoDB while fixing it.
- The `database` snap setting is now AUTHORITATIVE. Removed the "FerretDB SQLite present ->
force ferretdb / disable mongodb" overrides from wekan-control, ferretdb-control and
mongodb-control. wekan-control keeps only the safety guard (never start an EMPTY FerretDB
while MongoDB has data).
- New `snap run wekan.database mongodb|ferretdb` command (bin/wekan-database): switch which
database WeKan runs on. `mongodb` also pauses auto-migration (migrate=off) so it does not
switch back; `ferretdb` requires a non-empty SQLite first.
- Auto-migration can be paused: migration-pending now also returns "not pending" when
`snap get migrate` == off. A migration that FAILS now runs fail_and_run_mongodb: delete the
partial SQLite, set migrate=off, and exec mongodb-control so WeKan keeps working on MongoDB
(no downtime, no retry loop). fall_back_to_mongodb likewise sets migrate=off instead of the
done marker. `snap run wekan.migrate` re-enables migrate and retries.
- finish_success now restarts wekan.wekan so it reconnects to FerretDB after a successful
migration instead of waiting for the now-stopped MongoDB.
Registered the `database` app in snapcraft.yaml and snapcraft-core26.yaml (also added the
previously-missing migrate/maintenance apps to core26).
Thanks to xet7.
Two bugs surfaced when the MongoDB 7 -> FerretDB migration finally connected (after the
db-eval fix):
1. FerretDB v1 rejects collection names containing a dot:
invalid key: "attachments.chunks" (key must not contain '.' sign)
Both importers tried to copy GridFS internals (attachments.chunks/.files, avatars.*,
cfs_gridfs.*) and CollectionFS cfs.<bucket>.filerecord collections as TEXT, aborting the
migration. Now the text phase skips ANY dotted collection: none of WeKan's real data
collections contain a dot, and the dotted ones are GridFS internals (extracted in the file
phase), CollectionFS filerecords (now turned into bare attachments/avatars records in the
file phase via replaceOne upsert:true) or system.* collections.
2. The failed migration had already copied some text collections, leaving a NON-EMPTY but
incomplete files/db/wekan.sqlite. ferretdb-has-data then saw it as "migrated", so
mongodb-control disabled MongoDB and the snap tried to serve a half-migrated FerretDB. On
any failure migration-control now runs discard_partial_ferretdb: stop the temp target
FerretDB and delete the partial SQLite, so the snap cleanly keeps MongoDB and retries. The
finish_success switch is also gated on it (`rc -eq 0 && finish_success`).
Source MongoDB data is never modified or deleted.
Thanks to xet7.
9.92 is released, so move everything committed after it into a fresh
"# Upcoming WeKan ® release" section above v9.92, organized by topic like the
previous releases (features, then bugs):
Features: wekan.migrate command; maintenance mode + maintenance page.
Bugs: db-eval driver resolution (ESM ignores NODE_PATH); decide FerretDB vs
MongoDB from a non-empty SQLite database (not the marker); mongod-7
readiness probe fast-fail.
v9.92 is restored to what it shipped, including its "migration-success marker is
now authoritative" bug entry (which the Upcoming "presence of a FerretDB SQLite
database" entry supersedes). No entry text changed; only relocated.
ready_via_node waits up to 45s for the temporary source mongod to accept connections, to
allow a large MongoDB 6/7 database time to replay its journal (#6454). Add a liveness check:
if the mongod process (SRC_PIDFILE) has already exited - e.g. mongod 7 cannot open old
MongoDB 3.x data - stop waiting immediately and drop to the MongoDB 3.2 reader, instead of
pinging a dead process for the full timeout. Matters across many unattended 6.09 -> 9.x
upgrades. (With --fork, start_mongod usually already returns non-zero when mongod cannot open
the data; this also covers a mongod that started then died mid-probe.)
Thanks to xet7.
For unattended upgrades at scale (6.09/MongoDB 3.2 -> 9.x/FerretDB across many servers), the
"did the migration succeed?" test must not be fooled by a 0-byte stub file.
- New shared helper snap-src/bin/ferretdb-has-data: exit 0 only if a *.sqlite file bigger than
0 bytes exists in files/db. Used by mongodb-control, ferretdb-control and wekan-control in
place of the previous "*.sqlite exists" glob, so the DB decision is based on a real,
non-empty FerretDB database. (Deliberately does NOT require the -wal file, which SQLite may
checkpoint away when FerretDB is stopped - that would cause false negatives at startup.)
- migration-control finish_success now verifies the non-empty SQLite database exists (and logs
the WAL/shm sidecars) BEFORE switching the snap to FerretDB. If the importer returns success
but wrote no data, it does not switch or set the done marker - MongoDB data is kept and the
migration retries on the next start.
Thanks to xet7.
db-eval is the Node helper the snap uses instead of mongosh to check whether MongoDB/FerretDB
is up, elect the replica-set primary, and probe mongod-7 readiness during migration. It did
`import { MongoClient } from 'mongodb'` while the wrapper set NODE_PATH to the bundled driver
-- but Node's ESM loader IGNORES NODE_PATH (only the CommonJS loader honors it). So the import
resolved nothing and db-eval exited BEFORE opening any connection, making every
ping/primary/rs-* check fail.
This single bug explains the whole family of failures seen this week:
- WeKan looping "MongoDB not ready yet, retrying..." / "FerretDB not ready yet..." forever
even though the database was running and listening;
- replica-set initialisation failing;
- the MongoDB -> FerretDB migration falling back to MongoDB 3.2 because the mongod-7
readiness probe never connected (mongod 7 opened the data fine, but db-eval couldn't reach
it), and 3.2 cannot read WiredTiger-7 files -> no FerretDB SQLite produced.
Proof from the migration source mongod log: mongod 7 reached "Waiting for connections" with
ZERO "Connection accepted" before the readiness timeout killed it; the only connection in the
file was the native `mongo` shell to mongod 3.2.
Fix: resolve the driver with createRequire (CommonJS resolution honors NODE_PATH and the
bundle layout), anchored inside the modern bundle (npm-mongo v6 first). Applied the same fix
to the standalone migrate-schema-v843.mjs and migrate-gridfs-to-fs.mjs tools.
Thanks to xet7.
wekan.migrate (bin/wekan-force-migrate): force a fresh MongoDB -> FerretDB migration,
ignoring the database setting and the migration marker. Removes any partial FerretDB SQLite +
resume checkpoint, sets database=mongodb, and starts wekan.mongodb so migration-control
re-reads the existing MongoDB (3 or 7) data and migrates again. Source MongoDB data untouched.
wekan.maintenance on|off (bin/wekan-maintenance): toggles a $SNAP_COMMON/.wekan-maintenance
marker. While present, mongodb-control / ferretdb-control do NOT auto-migrate or auto-disable,
so `snap start wekan.mongodb` or `snap start wekan.ferretdb` stays up and you can reach the
data over the MongoDB wire protocol on port 27019 (one at a time - they share the port).
Maintenance page (bin/wekan-maintenance-page.mjs): in maintenance mode wekan-control execs
this instead of WeKan; it serves an "under maintenance" page (HTTP 503) on the web port for
ALL URLs. It shows the Admin Panel product name if set (not "WeKan"), read from
$SNAP_COMMON/.productname.txt, which is cached while a database is running by wekan-control
(new db-eval `product-name` command) and by both migration importers - so it is available even
when both databases are stopped.
Registered `migrate` and `maintenance` apps in snapcraft.yaml.
Thanks to xet7.
Regression fix. An earlier change made mongodb-control/ferretdb-control/wekan-control key
the "use FerretDB / disable MongoDB" decision off the .migration-to-ferretdb-done marker.
But migration-control ALSO writes that marker when the migration falls back (data
unreadable, tools missing) or when there is nothing to migrate - producing NO FerretDB
data. So on a server whose MongoDB 7 -> FerretDB migration failed:
- mongodb-control saw the marker -> "migration already finished; disabling mongodb
service" -> disabled MongoDB;
- FerretDB SQLite (files/db) was EMPTY;
- database=mongodb, so wekan-control waited on MongoDB -> "MongoDB not ready yet,
retrying in 5 seconds..." forever, and wekan.mongodb refused to stay up.
Now all three scripts decide from ACTUAL DATA ON DISK: MongoDB is disabled / FerretDB is
forced ONLY when a *.sqlite database exists in files/db. An empty files/db means the
migration did not succeed, so mongod starts normally and WeKan keeps working (and the
migration can be retried). The marker still prevents re-running a finished migration.
Thanks to xet7.
Upcoming section: document that statfs is in snapd's default seccomp allow-list, so the
MongoDB -> FerretDB migration's free-space guard is active on Snap; quotactl is not used and
its absence is covered by the ENOSPC/EDQUOT write-failure fallback.
Document that statfs (and statfs64/fstatfs/fstatfs64/statvfs/fstatvfs) are in snapd's
default seccomp allow-list (snapcore/snapd interfaces/seccomp/template.go), so free-space
checks WORK inside a snap (which also has no per-snap disk quota by default, so statfs shows
real usable space). quotactl is NOT in the allow-list, but it is never called; a snapd
storage-quota group is still caught by the ENOSPC/EDQUOT write-failure path. Only Sandstorm
grains genuinely lack statfs (FUSE unimplemented, quotactl blocked). No behaviour change.
migrate-mongodb-to-ferretdb.mjs (the modern MongoDB 6/7 driver importer that
migration-control runs, packaged from releases/):
- Resolve the mongodb driver by probing the WeKan bundle with createRequire anchors and
USE WHAT WORKS: prefer a v6+ driver that exposes GridFSBucket and speaks OP_MSG, since
an older bundled v2 driver's OP_QUERY is rejected by FerretDB ("Unsupported OP_QUERY
command: update"). A plain `import from 'mongodb'` could pick up that v2 driver. Fail
fast with a clear message if no usable driver is found.
- Bring it to parity with migrate-mongo3-to-ferretdb.mjs's data-safety and UX: measure
total attachment/avatar bytes up front and STOP before extracting if they will not fit;
if space runs out mid-run, stop + delete the partially migrated files + report how much
more disk is needed (a full disk can corrupt the still-running source MongoDB);
detect ENOSPC/EDQUOT where free space is not measurable (Sandstorm); show a live
per-file progress bar; and translate the dashboard into the browser's language.
Existing checkpoint/resume, schema upgrade, orphan fixing, compaction and index
creation are unchanged.
wekan-control:
- On startup, decide the database from what data actually exists on disk (FerretDB SQLite
at $SNAP_COMMON/files/db, MongoDB WiredTiger at $SNAP_COMMON), not the `database` setting
alone. If ferretdb is selected but its SQLite is empty while MongoDB still has data,
revert to database=mongodb instead of starting an EMPTY FerretDB that would look like all
data was lost, and tell the user to run the migration first.
Thanks to xet7.
Symptom: WeKan never started, looping "MongoDB not ready yet, retrying in 5 seconds..."
forever, even though mongod appeared to be running.
Cause: mongodb-control started mongod with a HARDCODED --wiredTigerCacheSizeGB 32. On any
server with less than ~34 GB RAM, mongod was OOM-killed seconds after startup. That
included the temporary mongod started to initialise the replica set: it died before
db-eval could reach it (log showed "child process started successfully" then 30 s of
failed pings), so the replica set was never initiated. The final mongod then ran with
--replSet rs0 but no config, no PRIMARY was elected, and wekan-control (which needs the
replica-set primary for Meteor change streams) waited forever.
Fixes in mongodb-control:
- WiredTiger cache is now RAM-aware: ~50% of (MemTotal - 1 GB), the same formula mongod
uses for its own default, capped at 32 GB, min 1 GB. Override with
MONGODB_WIREDTIGER_CACHE_GB. Applied to both the temp replica-set-check mongod and the
final mongod.
- Temporary-mongod readiness wait raised 30 s -> 90 s so a large database that needs
longer to replay its journal still gets its replica set initialised/reconfigured.
Fix in migration-control:
- The temporary source mongod started to READ the data during a MongoDB -> FerretDB
migration now uses a conservative RAM-aware cache (1/4 of (MemTotal - 1 GB), cap 8 GB,
override MIGRATION_MONGOD_CACHE_GB), leaving room for the target FerretDB and the Node
importer that run alongside it. Applied only to the mongod 7 (WiredTiger-only) read so
the flag can never clash with a legacy MMAPv1 MongoDB 3.x dbpath.
Thanks to xet7.
Symptom: on an already-migrated install, `sudo snap start --enable wekan.ferretdb`
started FerretDB and then it immediately stopped itself, logging:
"database is 'mongodb', not 'ferretdb'. Disabling ferretdb service."
Cause: every DB service keyed its behaviour off the `database` snap setting alone. If
that setting was never flipped to ferretdb (e.g. the migration's INTERNAL `snapctl set`
did not re-run the configure hook), ferretdb-control read `database=mongodb` and disabled
itself, so FerretDB could not be started by hand without first running
`snap set wekan database=ferretdb`.
Fix: the marker $SNAP_COMMON/.migration-to-ferretdb-done is now authoritative.
- ferretdb-control: if the marker exists, repair database=ferretdb and keep running
instead of self-disabling.
- mongodb-control: if the marker exists, repair database=ferretdb and disable mongodb,
BEFORE the migration-pending check so a finished migration is never re-attempted.
- wekan-control: already forces ferretdb on the marker (previous commit).
Immediate recovery on an already-migrated install running an older release:
sudo snap set wekan database=ferretdb
Thanks to xet7.
wekan-control (the wekan.wekan service) only WAITED for the database DATABASE points at
and never started a DB service, so if both wekan.ferretdb and wekan.mongodb were
stopped/disabled WeKan hung on "MongoDB not ready yet, retrying..." forever.
Now, on start, wekan-control:
1. If the migration-success marker $SNAP_COMMON/.migration-to-ferretdb-done exists,
forces database=ferretdb, then enables + starts wekan.ferretdb and stops + disables
wekan.mongodb. This self-heals the case where the migration's INTERNAL `snapctl set`
never re-ran the configure hook that flips the services.
2. Before waiting, enables + starts whichever DB service is configured
(snapctl start --enable = snap enable + snap start), so a merely-stopped DB is
brought back up instead of WeKan waiting forever.
Uses the snap instance name so parallel installs target their own services.
Thanks to xet7.
v9.91 was cut as a release, so move the Snap FerretDB service-flip fix out of it into a
fresh "# Upcoming WeKan ® release" section above v9.91. No entry text changed; only
relocated.
After a MongoDB -> FerretDB migration, WeKan hung on "MongoDB not ready yet, retrying..."
because no database was running: wekan.ferretdb stayed disabled and wekan.mongodb stayed
enabled-but-stopped.
Root cause: the wekan.ferretdb service disables itself while database=mongodb, and the
service flip that re-enables it lives in snap/hooks/configure. migration-control switches
the backend with an INTERNAL `snapctl set database=ferretdb`, but an internal snapctl set
does not re-run the configure hook, so the flip never happened.
Fix: finish_success now does the flip itself (mirroring the configure hook's ferretdb
branch): enable+start+restart wekan.ferretdb, then stop+disable wekan.mongodb, using the
snap instance name so parallel installs target their own services. FerretDB is started
before MongoDB is disabled so a DB is up first.
Immediate recovery on an already-migrated install:
sudo snap start --enable wekan.ferretdb && sudo snap stop --disable wekan.mongodb
v9.90 (2026-07-15) was already cut, but later work had been appended to it. Create a new
"# Upcoming WeKan ® release" section above v9.90 and move into it everything committed
after the v9.90 cut:
- new features: Snap/Sandstorm migration dashboard (per-file progress + disk guard)
- updates: i18n 10 more languages, native-name fixes, pull English-regression report
- tests: dev server also frees the MongoDB port
- bugs: MongoDB 3->FerretDB EJSON + stay-on-page; "Always show all code as plain text"
reactivity race; i18n browser-language -> file mapping fixes
v9.90 is restored to its cut contents (MimeBleed CRITICAL + the original features/updates/
tests/bugs). No entry text changed; only relocated.
Document the Upcoming i18n work: the ja_JP->ja clobber fix, case/underscore-insensitive
language matching, Chinese subtag fallback + zh alias, the cmn tag typo fix (bugs), and
the 10 new selectable languages, native-name corrections, and the pull-translations
English-regression report (updates).
Add languages.js entries for translation files that had none (so they were pulled from
Transifex but never selectable): ca-valencia (Català (Valencià)), en_ID/en_SG/en_TR
(English (Indonesia/Singapore/Turkey)), es_CO (Español (Colombia)), fr-FR (Français
(France)), pt_PT (Português (Portugal)), ru-UA (Русский (Украина)), tk_TM (Türkmençe
(Türkmenistan)), wuu-Hans (吴语（简体）). Skipped km_KH and ru_RU (duplicate the existing
km-KH / ru-RU entries) and zh (already aliased to zh-Hans).
Fix language names that used the English name instead of the native one:
ace "Acehnese" -> "Bahsa Acèh"
cy "Welsh" -> "Cymraeg"
cy-GB"Welsh (UK)" -> "Cymraeg (Y Deyrnas Unedig)"
af_ZA"Afrikaans (South Africa)" -> "Afrikaans (Suid-Afrika)"
Fix several browser-language -> translation-file mapping gaps:
- isLanguageSupported is now case-insensitive (requested) via a new TAPi18n.resolveTag()
that maps any input to the canonical languages.js tag case-insensitively AND
underscore<->hyphen-insensitively (so 'zh-hant'->'zh-Hant', 'JA-JP'->'ja-JP', browser
'af-ZA'->legacy key 'af_ZA'). loadLanguage/setLanguage/ensureLanguageLoaded resolve
through it, so the loaded file, the i18next code and the stored current tag all agree.
- Bare base codes with no plain-code file resolve via an alias map: 'zh' -> 'zh-Hans'
(Chinese has only script/region files), so plain 'zh' gives Simplified, not English.
- Browser detection (client/lib/i18n.js) now strips trailing subtags progressively
instead of jumping to the first segment: 'zh-Hans-CN' -> 'zh-Hans', 'zh-Hant-TW' ->
'zh-Hant' (Chrome sends these), rather than -> 'zh' -> English.
- languages.js: fix the 'cmn' entry whose tag was the typo 'cnm' (and code 'cn'), which
mismatched supportedLngs and broke selecting Mandarin; now tag/code = 'cmn'.
Adds i18n.test.js coverage for resolveTag, case-insensitive isLanguageSupported, the zh
alias, the underscore/hyphen match, and each Japanese variant loading its own file.
Two Transifex languages were writing to the same local file: .tx/config lang_map had
`ja_JP: ja`, which sent Transifex's ja_JP INTO imports/i18n/data/ja.i18n.json — the same
file the real Japanese (`ja`) uses. On `tx pull -a -f`, the emptier/untranslated ja_JP
overwrote ja.i18n.json, reverting Japanese strings to the English source. Map it to its
own file instead: `ja_JP: ja-JP` (-> ja-JP.i18n.json), matching languages.js which already
has three separate Japanese entries (ja -> ja.i18n.json, ja-JP -> ja-JP.i18n.json,
ja-Hira -> ja-HI.i18n.json). No other lang_map target collides. languages.js already loads
each to its own file, so no change needed there.
Also add releases/translations/report-english-regressions.mjs and call it from
pull-translations.sh: after pulling, it lists the language files where a previously
translated string reverted to exactly the English source (i.e. untranslated on Transifex),
so the regression is visible instead of being committed silently.
The MongoDB 3 -> FerretDB migration work had grown into one large bug bullet that
actually contained major features (live per-file progress bar, chunk-by-chunk streaming,
disk-space safety guard + rollback, Snap/Sandstorm/availability detection). Move those to
the "new features" section as their own bullet, and keep the EJSON-resolution fix +
stay-on-page hand-off as the bug entry (with a pointer to the feature bullet).
Previously the statfs free-space guards were gated on IS_SNAP. But a Snap container may
also be unable to report free space (statfs fails). Drive the behaviour off whether free
space is actually MEASURABLE instead:
- updateDiskFree: skip statfs only on Sandstorm (where it is known-unreliable — reports the
host disk, not the grain quota); everywhere else ATTEMPT statfs, and on failure leave
state.diskFree < 0 (unknown).
- ensureDiskForFile / the up-front total-size pre-check: run only when state.diskFree >= 0
(measurable); otherwise skip and rely on an ENOSPC/EDQUOT write failure.
- Dashboard already hides the free-space figure and switches to "free space required for
all files" whenever diskFree < 0, so a Snap-with-no-statfs degrades exactly like
Sandstorm: try, and stop + delete + report on a write failure.
IS_SNAP is now only used for the platform log line. CHANGELOG updated.
The statfs free-space checks only make sense on the Snap (a real filesystem whose size we
can read). A Sandstorm grain cannot see its free space or quota — its FUSE layer does not
implement statfs and quotactl is blocked (confirmed in the Sandstorm source), and statfs
on the writable /var reports the host disk, not the grain quota. So:
- Detect Snap via $SNAP (IS_SNAP) and Sandstorm via SANDSTORM / SANDSTORM_RAW_MONGO_PATH /
METEOR_SETTINGS.public.sandstorm (IS_SANDSTORM).
- Run the statfs up-front + mid-run free-space guards ONLY on Snap.
- On Sandstorm (and anything else), just try to migrate and detect "out of space" from an
actual ENOSPC/EDQUOT write failure (in the streaming writer and in the file-loop catches),
which triggers the same stop + delete-migrated-files + report rollback (onDiskAbort).
- Dashboard shows the free-space figure only when known (Snap); on Sandstorm it says free
space is unknown and phrases the requirement as "free space required for all files".
Sandstorm source used only for research (grain cannot query disk/quota); not committed.
CHANGELOG updated.
Add the missing Upcoming bug entry for the alwaysShowCodeAsText fix (the viewer read a
stale ReactiveVar and never re-rendered, so the toggle did nothing; now set inside the
mentions helper from the same reactive setting it already reads). The MongoDB 3 ->
FerretDB migration progress/disk-guard improvements were already recorded in the mongo3
migration entry.
Migration dashboard + migrator improvements for the MongoDB 3 -> FerretDB path:
- Live per-file progress: the file currently being extracted shows its name, size,
"file N of TOTAL", a percent progress bar, and whether it is an attachment or an
avatar. File-type words use WeKan's existing translations in the viewer's browser
language (Accept-Language), read best-effort from the bundle with an English fallback.
- RAM-safe streaming: each GridFS file is streamed chunk-by-chunk (sorted by n) straight
to disk via a spawned mongoexport + readline, with natural back-pressure, so a multi-GB
attachment never lands in memory. The old approach buffered the whole file through
mongoexport's 512 MB stdout maxBuffer and failed on big files.
- Disk-space guard (a full disk can corrupt the still-running source MongoDB): the
dashboard shows remaining free space; the migrator measures the total size of all
attachments+avatars up front and stops immediately if the volume cannot hold them; it
also stops mid-run if free space drops below a safety margin (default 1 GB,
MIGRATION_MIN_FREE_BYTES). On such a stop it deletes the partially-migrated files to
free the space back, reports how many files were migrated before stopping, and shows how
much more disk space is required to migrate all files.
Cannot run the snap here, so this is reviewed but not executed; needs a snap migration run
to verify. CHANGELOG updated.
The MongoDB 3 migrator resolves WeKan's modern bson (with EJSON) and mongodb v6 by
anchoring require() inside the Meteor bundle. It anchored the sub-paths relative to the
script, but in the snap the script runs from $SNAP/bin/ while the bundle is at
$SNAP/programs/server/... (one level up) — so every anchor resolved
$SNAP/bin/programs/server/... (nonexistent) and fell through to the ancient meteor-spk
base bson 1.x with no EJSON, giving "FATAL: EJSON.parse unavailable" and aborting the
migration.
Build candidate bundle roots from $SNAP (env) and the script's parent dirs, then try the
known modern-bundle sub-paths under each (npm-mongo's nested v6 driver first, so the
ancient v2 that FerretDB rejects with OP_QUERY is never chosen). Node's module resolution
walks up from the '_.cjs' anchor to programs/server/npm/node_modules/bson.
Also: on successful hand-off the dashboard now reloads the SAME page the user was on
(the board URL) instead of forcing All Boards, so a reload during migration keeps you in
place. The dashboard already serves the progress page for every URL. CHANGELOG updated.
The viewer (mentions -> markdown) applies alwaysShowCodeAsText via a ReactiveVar
(Markdown.alwaysShowCodeAsText) that only a separate startup Tracker.autorun kept in
sync with the setting. But the mentions helper re-renders whenever the settings doc
changes (it reads getCurrentSetting for renderLinksAsPlainText/stripLinks), and that
re-render often runs BEFORE the bridge autorun updated the ReactiveVar — so the inner
markdown helper read the stale flag and rendered links/markdown normally (clickable),
and since mentions does not depend on that ReactiveVar it never re-rendered again.
Net effect: toggling "Always show all code as plain text" did nothing (links stayed
clickable, code stayed rendered), even after reload (same race on load).
Fix: set Markdown.alwaysShowCodeAsText inside the mentions helper, from the same
reactive getCurrentSetting() it already reads, BEFORE rendering the inner markdown
via Blaze.toHTML. The markdown helper now always reads the up-to-date flag in the same
synchronous render, so the toggle takes effect immediately in every rich-text field
(card titles, descriptions, comments, checklists). The startup autorun stays for any
direct +markdown use outside a viewer.
kill_meteor_on_port freed the app port (3000) and rspack dev-server port (8080) but not
Meteor's bundled MongoDB on app-port+1 (3001). When the meteor parent is SIGKILLed its
mongo child is often orphaned and keeps holding 3001, so the next `meteor run` failed
with "Unexpected mongo exit code 48 ... port was closed, or was already taken". Also
free app-port+1 (which additionally clears a leftover standalone test mongod on :3001),
include it in the readiness guard/wait, and in the SIGKILL escalation. CHANGELOG noted.
Bring the Windows batch runner to parity with rebuild-wekan.sh: the :3000 server for
Node E2E + Playwright now runs from the precompiled .build\bundle instead of
`meteor run`, so no recompile. New :start_bundle_server subroutine (used by both the
parallel and sequential "Run ALL tests" flows):
- Builds .build\bundle once if missing (meteor build .build --directory).
- Resolves Meteor's bundled node via `meteor node -e process.execPath` and the sibling
dev_bundle mongod; runs the bundle with that node (native-module ABI match).
- Installs the bundle's programs\server npm deps once.
- Starts Meteor's mongod on :3001 (db "meteor", matching what the tests seed), or reuses
a MongoDB already listening there; stops it on exit only if this run started it.
- Starts `node .build\bundle\main.js` with MONGO_URL/ROOT_URL/PORT/WRITABLE_PATH set in
the parent scope (child inherits them) then unset so Mocha/E2E do not inherit MONGO_URL.
Mocha still uses `meteor test` (:3100, its own build) — it cannot run from a production
bundle. Intro text and cleanup updated; CHANGELOG notes the parity. Untested on Windows
here (no cmd available); needs one Windows verification run.
Group the Upcoming section under the standard headers: CRITICAL SECURITY ISSUE
(MimeBleed), new features (import/export privacy, always-show-code, render-links),
updates (webhook card description, Sandstorm docs), tests (yargs mocha crash, live
progress, .build/bundle reuse), bugs (Sandstorm migrated-grain Admin Panel, Version
storage engine). Also fold the bundle-server "meteor" vs "wekan" database fix into
the .build/bundle test entry.
The bundle-based :3000 server pointed at mongodb://127.0.0.1:3001/wekan, but the
Playwright and Node E2E tests seed their users/boards straight into
mongodb://127.0.0.1:3001/meteor (tests/playwright/helpers/db.js,
tests/e2e/list-regressions.js) — the DB name Meteor's built-in mongo used under the
old `meteor run`. Same mongod, different database: the app read an empty DB while the
tests seeded another, so every test needing seeded data failed (only the ~9 per browser
that need no seed passed). Point the bundle server at /meteor so app and tests share
one database again.
Complete the Upcoming test-infrastructure notes: the readiness poll that hung on
Meteor's :3000 proxy (progress froze at [0s]) is now fixed with a curl timeout and a
wall-clock-bounded wait, and "Run ALL tests" checks for .build/bundle specifically and
builds it once if missing. Also note the .sh (bundle) vs .bat (meteor run) split in the
server-start wait item.
Before running ALL tests, check for the .build/bundle directory specifically (the
:3000 test server runs it). If it is missing (never built, or a previous build left
.build without a bundle), build it with `meteor build .build --directory` first.
Previously it only checked the .build parent, so a missing/partial bundle was not
rebuilt here (only caught later by the main.js check).
"Run ALL tests" started the :3000 server with `meteor run`, which recompiles into
.meteor/local even after you already built .build/bundle. Node E2E + Playwright only
need a live WeKan over HTTP, so start that server from the precompiled bundle instead:
- `node .build/bundle/main.js` with Meteor's bundled node (matching native-module ABI),
MONGO_URL to Meteor's bundled mongod on :3001 (or reuse a MongoDB already listening
there). Boots in seconds, no recompile. One-time `programs/server` npm install runs
if missing. mongod is stopped on exit only if this run started it.
- The server boot log and the npm install now STREAM LIVE (scrolling: tail -n 0 -f /
tee) so you see exactly what is happening instead of a single frozen summary line.
- Sequential mode runs suites strictly one at a time, each streaming its own output;
the parallel-only combined refreshing table is now skipped in sequential mode.
Mocha still uses `meteor test` (its own .meteor/local-test build) — its in-process
server-side tests cannot run from a production bundle, so that one build is unavoidable
and copying the bundle would not help it. The script warns the bundle is run as-is, so
rebuild it after source changes. CHANGELOG updated.
In sequential mode only one suite runs at a time, so there is no reason to hide its
output in a log and show only a counter. Refactor the job runner: extract run_job_body
(the actual suite command) and, in sequential mode, pipe it through tee straight to the
console — you now see every test tick by one-by-one as the reporter prints it, then a
final PASS/FAIL + count line. Parallel mode still runs jobs in the background to logs
(the combined table reads them). tee is on the right of the pipe so the suite's exit
code is captured in STATDIR, not tee's.
The "Building WeKan" message during Run ALL tests suggested a fresh full build even
though the user had already built WeKan. Reword it: the tests start a live
`meteor run --port 3000`, and Meteor recompiles into .meteor/local on start only for
inputs that changed since the last build (sources / node_modules), then caches it.
No behavior change, message only.
The "Run ALL tests" server-readiness wait used `curl http://127.0.0.1:3000/sign-in`
with no timeout. Meteor binds the :3000 proxy early and accepts the TCP connection
while the app is still building, but does not send an HTTP response until the build
finishes. So curl blocked on that first connection for the whole build: the loop
never advanced and the new progress line froze at [0s] with only the log header,
even though the build was progressing in the log.
Give curl --connect-timeout 2 --max-time 4 so each poll returns quickly (not-ready
during the build, ready once /sign-in actually answers). The elapsed seconds and the
newest build step now refresh every few seconds as intended. Bound the wait by
wall-clock time (.sh: 1200s; .bat: ~240 polls) instead of a fixed count, since polls
now take a few seconds each. Also add the timeout to the Playwright-ALL precheck.
Audited both runner scripts and closed every place that used to sit silent for
minutes during test runs:
- Server first-build wait (Run ALL tests, both modes): .sh shows elapsed seconds +
newest build step from the server log in place; .bat shows elapsed seconds every
~10s and points at the live build log (echoing arbitrary build lines is unsafe on
cmd because they contain > < | &).
- Sequential per-job (option 2): .sh prints a live elapsed + pass/fail counter per
job and a final PASS/FAIL line; .bat now runs each job in its own minimized window
(reusing the proven parallel start-commands + .done-<key> flags) and polls a live
pass counter one job at a time, instead of redirecting silently to a log.
- Playwright ALL browsers single menu item (.sh option 10 / run_playwright_parallel):
streams each browser's list reporter live via tee while still saving the log;
PIPESTATUS[0] keeps per-browser pass/fail accurate through the pipe.
Single-suite items (Mocha, import, E2E, single Playwright) and the parallel combined
progress table already showed progress and are unchanged. CHANGELOG updated.
Record the Upcoming test-infrastructure change: "Run ALL tests" now shows elapsed
time + newest build step during the server build, and a live per-job pass/fail
counter in sequential mode, instead of sitting silent for minutes.
Running ALL tests (menu options 1/2) was silent for minutes in two places:
- While the :3000 WeKan server did its first rspack build, the readiness wait only
printed dots. Replace that with an in-place line showing elapsed seconds and the
newest build step from the server log (=> Compiled Rspack..., => Started MongoDB,
=> Started your app), so the build is visibly progressing.
- In sequential mode each job blocks until it finishes, so nothing showed while a
job built and ran. Add a live in-place counter per job (elapsed seconds + tests
passed/failed, from count_pass/count_fail on the job log) and a final PASS/FAIL
line when it completes.
The parallel-mode combined progress table is unchanged.
Update the "Test infrastructure" Upcoming entry with the confirmed root cause and
resolution: the second-stage boot crash was node_modules/yargs-parser/build/lib/index.js
using the guarded ternary `const require = createRequire ? … : undefined`, fixed by
generalizing the createRequire removal to a line-wise match (run before import.meta.url
expansion) and broadening the scan from node_modules/yargs to yargs and its ESM deps.
Also note the three server test files that were present but missing from the curated
server/lib/tests/index.js loader and are now registered. Verified: 450 passing, 0 failing
(411 before the three files were wired in).
The Mocha (server-side) test bundle crashed at boot with 0 tests run because
yargs and its ESM dependencies are dragged into the Meteor test server bundle,
where Meteor 3 wraps every module in a CommonJS function and their native-ESM
constructs (import.meta, `const __dirname`, `const require = createRequire(...)`)
are illegal and crash the bundle before any test runs.
Two gaps remained in scripts/patch-yargs-dirname.cjs:
- The `const require = createRequire(...)` removal (and its trigger) only matched
the direct-call form. yargs-parser/build/lib/index.js uses the guarded ternary
`const require = createRequire ? createRequire(import.meta.url) : undefined;`,
which slipped through and crashed at boot with "Identifier 'require' has already
been declared". Generalized the match to line-wise `const require = ...createRequire...;`.
- The scan only walked node_modules/yargs, so yargs-parser (the actual offender)
was never patched. Broadened the scan to yargs and its ESM dependency packages.
Also register the three server test files that were present but missing from the
curated server/lib/tests/index.js (they never ran): the MimeBleed file-validation
bypass regression, the import/export privacy settings, and the impersonation report
query. Server suite now boots and runs (411 passing).
CHANGELOG Upcoming documents the bug and the two-stage debugging journey.
The yargs postinstall patch expanded import.meta.url -> require('url').pathToFileURL(...)
BEFORE removing the const require = createRequire(...) call. The paren-naive removal
regex createRequire([^)]*) then stopped at the first ) of the injected require('url'),
replacing only part of the statement and leaving a dangling
/* Meteor: use wrapper require */.pathToFileURL(__filename).href));
in yargs' esm.mjs. That is invalid JS (a leading .pathToFileURL after a comment), so
Meteor's reify parser threw 'Unexpected token (19:33)' when the test server bundle pulled
yargs in -- meteor test reported 0 tests, even though every repo source file was fine.
Fix: remove the createRequire call BEFORE expanding import.meta.url (so the injected
parens can't break the match), and add a repair rule + trigger so re-running the script
collapses the dangling leftover in already-corrupted node_modules/yargs files back to the
marker. Fresh and already-broken files both end valid.
- models/fileValidation.js: a stray BOM (U+FEFF) inside the looksLikeDangerousMarkup
regex character class broke the server test build with a Babel 'Unexpected token'
syntax error, so Mocha ran 0 tests. JS \s already matches U+FEFF, so the explicit
BOM was redundant; use plain \s*.
- models/import.js: importBoard awaited assertImportEnabled() BEFORE the switch that
check()s the "board" argument. Meteor's audit-argument-checks tracks checks on the
async context, so awaiting first made the later check(board) not count, throwing
'Did not check() all arguments during call to importBoard' -- which broke the WeKan
JSON import (#21) and Excel import (#25) Playwright tests. Check "board" up front
(Match.OneOf(Object, Array)) before the await; the per-source switch still does its
specific check.
- server/publications/activities.js: move the disableActivities gate to AFTER the
check() calls so the argument-checks audit is satisfied when the toggle is on
(latent: it would have thrown 'did not check all arguments' with activities off).
Supersede the earlier 'keep MongoDB 7' approach: the WeKan snap now moves EVERY
existing MongoDB database onto FerretDB (SQLite) on first boot after an upgrade,
then shuts MongoDB down so only WeKan (Node.js) + FerretDB (SQLite) run. Text data
goes into SQLite; CollectionFS + Meteor-Files GridFS attachments/avatars are
extracted to files/attachments and files/avatars.
migration-control now routes by how the source can be READ, not by keep-vs-migrate:
- mongod 7 can open it (modern MongoDB 6/7, incl. a DB earlier migrated up from 3.x)
-> keep that mongod as source, run the modern driver importer
(migrate-mongodb-to-ferretdb.mjs) into a temp FerretDB SQLite target.
- else mongod 3.2 can open it (old MongoDB 3.x) -> run migrate-mongo3-to-ferretdb.mjs
(legacy mongoexport CLI).
- else (unreadable/corrupt, or tools missing) -> fall back to a normal MongoDB start
so the service is never left dead, and retry next boot.
On success: mark done + snapctl set database=ferretdb; mongodb-control then stops and
disables the MongoDB service. This also fixes the reported failure where a healthy
MongoDB 7 database was misdetected as MongoDB 3.x, the 3.x path failed, and — because
mongodb-control exec's this script — mongod never started and the service looped.
Probe readiness lengthened 20s -> 45s; the temp source mongod is tracked by pidfile
and force-stopped so it never leaves the dbpath locked. MongoDB data is never
modified or deleted; the snap only switches to FerretDB once migration succeeds.
Both migration dashboards (Snap MongoDB-3 importer and the Sandstorm/general
MongoDB importer) hard-coded 'WeKan'. If the migrated database has a product name
set in Admin Panel (settings.productName), the dashboard now shows that name and
does not mention WeKan; otherwise it defaults to WeKan.
- snap-src/bin/migrate-mongo3-to-ferretdb.mjs: read settings.productName via
mongoexport early in run() into state.product; title/h1/complete message use it.
The importer->app hand-off poll no longer keys off the product-dependent title
string; it checks a stable '<!--migration-dashboard-->' marker instead.
- releases/migrate-mongodb-to-ferretdb.mjs: read settings.productName via the driver
right after the source connects into state.product; the HTML __PRODUCT__ placeholder
is substituted in buildHtml(). Header clarified to FerretDB (SQLite).
The one-time MongoDB 3 -> FerretDB migration check probed whether mongod 7 could
open the existing data and, if that short probe failed for ANY reason (journal
recovery, stale mongod.lock, slow disk, large oplog), assumed the data was
MongoDB 3.x. A healthy MongoDB 7 database that failed the probe was then sent down
the 3.x path, where mongod 3.2 also could not open it, logging 'could not start
migratemongo mongod on the MongoDB 3.x data'. Because mongodb-control exec's the
migration script, mongod never started -- the MongoDB service failed to activate
and looped on every restart.
Fix: only run the 3.x migration when the data is POSITIVELY confirmed as MongoDB
3.x (mongod 3.2 can actually open it). In every other case -- MongoDB 6/7, data the
probe could not read, or missing tools -- fall back to a normal MongoDB 7 start in
the same service activation (set the marker + exec mongodb-control) instead of
exiting with nothing running. Also: lengthen the mongod-7 readiness probe 20s -> 45s
so large databases needing recovery are not misread, and track the temporary probe
mongod by pidfile + force-stop it so it never leaves the dbpath WiredTiger lock held.
The MongoDB data is never modified or deleted.
- client/lib/tests/renderLinksPlainText.tests.js: the 'render links as plain text'
toggle and XSS hardening. Config assertions (stripLinks adds <a> to FORBID_TAGS,
default does not, KEEP_CONTENT) plus real sanitizeHTML() behavior: <a> stripped to
its text when stripLinks, kept by default, and javascript: hrefs / event handlers /
<script> removed regardless.
- client/lib/tests/alwaysShowCodeAsText.tests.js: escapeHtmlSource (exposed on the
Markdown export) escapes <script>/comments/quotes/ampersand-first so code is shown
not executed; leaves plain text and empty strings unchanged.
- server/lib/tests/impersonationReportQuery.tests.js: the Impersonation report search
selector (extracted to models/lib/impersonationReportQuery.js so it is testable
without re-registering the publication) builds a case-insensitive $or across the
identity fields, escapes regex metacharacters, and is empty for a blank term.
The MimeBleed fix (fileValidationBypass.security.tests.js), SortBleed
(boards.security.tests.js) and import/export anonymization
(importExportSecurity.tests.js) already carry positive + negative tests.
WeKan's upload validation (models/fileValidation.js) detects a file's real MIME
type by running the Unix 'file' command. On minimal Docker/Alpine images without
'file', detectMimeFromFile() silently returned undefined and the code fell back to
the CLIENT-supplied fileObj.type. An authenticated board member (WITH_API=true)
could upload HTML+JS while setting fileType: image/png; the spoofed type is not on
the dangerous-MIME deny-list, so the dangerous-content scan was skipped and the file
was stored, yielding stored XSS served under the WeKan origin (CWE-434).
Fix: the client-supplied type can no longer gate the safety scan. When content-based
detection via 'file' is unavailable, fall back to a dependency-free JS content sniff
(looksLikeDangerousMarkup) that inspects the real bytes for HTML/SVG/XML/<script>
signatures and forces the dangerous-content scan regardless of the claimed MIME, so a
spoofed image/png that is really HTML+JS is rejected. The sniff matches only definitive
markup, so genuine binary uploads (real PNG/JPEG/PDF, incl. large ones) are unaffected.
Also log a one-time warning when 'file' is missing (previously silent).
Regression test server/lib/tests/fileValidationBypass.security.tests.js covers the
spoofed dangerous uploads and safe binaries.
CVSS:3.1 8.3 High (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N). Thanks to HNUfwj and xet7.
Disabling activities/notifications/watch can serve any law or policy, not only
GDPR. Remove GDPR mentions from the code comments and the en.i18n.json toggle
descriptions (and the Admin Panel docs), keeping the neutral #5820 reference.
A card description was recorded in the activity log (a-changedDescription, #5482)
but never added to the outgoing-webhook / notification params, so integrations got
an event with no description text.
The Activities.after.insert payload now sets params.description (the card's current
description, only when non-empty) for every card event, and forwards the activity's
oldValue/value alongside the existing timeValue/timeOldValue so a description change
carries the before/after text. New fields are additive and backward-compatible.
Impersonation events are already recorded in the impersonatedUsers collection
whenever an admin impersonates a user (e.g. to export a private board). Surface
them as a new admin report, newest-first, with the same server-side search +
pagination as the other reports.
- server/publications/impersonationReport.js: impersonationReport publication
(admin-only, sort createdAt -1, limit/skip, $or search over admin/user/board/
attachment ids and reason) + getImpersonationReportCount method. Also publishes
the referenced admin/impersonated user docs (same fields the People panel uses)
so usernames resolve and the Edit user popup has its data.
- adminReports.jade/.js: new Impersonation side-menu entry, sub-template (Date,
Admin, Impersonated user, Board, Reason), pagination + search wired through the
shared reportConfig. Clicking a username opens the same editUser popup as
Admin Panel / People.
- i18n: impersonationReportTitle, impersonation-admin, impersonation-user, reason.
- server/lib/tests/importExportSecurity.tests.js: positive and negative unit
tests for the anonymization helpers (map building, user-doc scrubbing, @mention
rewriting that ignores unknown handles and email addresses, requestedBy/assignedBy
identity replacement, and safe no-ops on empty input).
- docs/Features/Admin-Panel/Admin-Panel.md: new Features tab section documenting the
Performance, Security (rich-text hardening + import/export privacy) and
Notifications (GDPR) toggles.
New Notifications category with three GDPR toggles (all default off), enforced
server-side:
- Disable all activities: activity-feed entries are neither recorded
(Activities.before.insert returns false to cancel) nor shown (the activities
publication returns nothing, hiding existing and new entries).
- Disable all notifications: the Activities.after.insert dispatch hook returns
early, so no watch notifications are sent; activity recording is unaffected.
- Disable watch: the watch() method rejects any watch-level change, and the board
header watch button is hidden.
A synchronously-readable server cache (models/lib/featureFlags.js, kept current by
a Settings observer) lets the sync before.insert hook read the flags without
awaiting. Adds settings disableActivities, disableNotifications, disableWatch,
published in the public setting, plus global Blaze helpers activitiesDisabled /
watchDisabled for UI hiding.
Six new optional toggles (all default off) governing how boards and user data
cross the WeKan boundary, enforced server-side so they cannot be bypassed from
the client:
- Disable all import / Disable all export: master switches that turn off every
import/export feature. importBoard and cloneBoard call assertImportEnabled;
every Exporter build()/buildStream() call assertExportEnabled. The import and
export menu options are hidden in the UI via global importDisabled/exportDisabled
Blaze helpers.
- Disable import avatars / Disable export avatars: never carry avatars into/out of
WeKan. Import is gated at the single localizeAvatarFromBuffer choke point (covers
WeKan JSON import, LDAP, OIDC/OAuth2 login sync and board-open localization) plus
Trello inlineMemberAvatars; export skips the base64 avatar embed + avatarUrl in
both Exporter paths.
- Anonymize import users / Anonymize export users: replace username/fullname/initials
with counter placeholders (user1, user2, ...), drop avatars, and rewrite @username
mentions + requestedBy/assignedBy in card/comment text. The placeholder word "user"
is translated to the current user language. Export covers both build() and the
streaming buildStream() (which does an id-only pre-scan so mentions streamed before
the users array resolve to matching labels); import scrubs the incoming board in
WekanCreator before any placeholder user or card is created.
New shared server helper models/lib/importExportSecurity.js holds the settings
read, guards, anonymization map builder and text rewriter. Adds settings
disableAllImport, disableAllExport, disableImportAvatars, disableExportAvatars,
anonymizeImportUsers, anonymizeExportUsers, published in the public setting.
Translate the new render-links-as-plain-text-description, always-show-code-as-text
and always-show-code-as-text-description strings to Finnish, matching existing
terminology (tarkistuslistat, klikattava, 'Kun käytössä...', 'Oletuksena pois
käytöstä...').
New optional toggle under Admin Panel / Features / Security. When enabled,
rich text is never rendered as markdown or HTML -- the entire source is shown
as escaped plain text in every rich text field (board and card titles,
descriptions, comments, checklists, etc.), so hidden content is always
revealed: HTML comments (<!-- -->), the target URL inside a markdown link,
JavaScript and any other code. All code is always visible, not clickable, and
not running.
This extends the existing invisiblebleed protection (which already showed raw
source for description-less markdown links) to all content, and complements
the "Render links as plain text" toggle.
Implementation:
- New global setting alwaysShowCodeAsText (models/settings.js), published in
the public setting publication, default off.
- Admin Panel / Features / Security gains a second materialCheckBox toggle.
- The markdown helper has the raw text, so the decision lives there. Because
the wekan-markdown package cannot import app code, the setting is bridged via
a ReactiveVar on the exported Markdown object; the rich text viewer
(editor.js) keeps it in sync with the setting reactively, and the markdown
helper reads it and renders the fully HTML-escaped source in a <pre> when on.
Full escaping (not DOMPurify stripping) ensures tags like <script> are shown
as text rather than removed. The description-less-link branch now uses the
same full escaping so it too reveals all source.
New optional security feature under Admin Panel / Features / Security. When
enabled, all links -- both markdown links like [label](url) and raw HTML
<a href> tags -- are always shown as plain, non-clickable text in every rich
text field (board and card titles, descriptions, comments, checklists, etc.),
so a link can never be clicked and cannot present misleading anchor text.
This is a hardening option on top of the existing XSS sanitization (which
already strips javascript:/data: schemes, event-handler attributes and
dangerous tags); it addresses #6453, where a board title rendered as a
clickable link. Default off, so links stay clickable.
Implementation:
- New global setting renderLinksAsPlainText (models/settings.js), published in
the public setting publication.
- Admin Panel / Features gains a Security category with a materialCheckBox
toggle that saves the setting immediately.
- The shared DOMPurify sanitizer takes a { stripLinks } option that forbids the
<a> tag while keeping its inner text (KEEP_CONTENT), so links collapse to
plain text. The rich text viewer (mentions helper in editor.js) passes
stripLinks based on the setting, gated reactively so toggling re-renders.
On Sandstorm the grain owner (Sandstorm 'configure' permission) maps to a
WeKan admin, which gates the Admin Panel and its Attachments / Sandstorm
cleanup tools. A new grain worked because Users.after.insert derives the role
for the freshly inserted user, but a grain migrated from an older WeKan
already contains the user, so that insert hook never runs. Sandstorm
auto-login uses connection.setUserId() (bypassing accounts-base, so
Accounts.onLogin never fires), and the remaining observeChanges hook on
services.sandstorm only fires when that field actually changes on login. When
the migrated user's stored permissions already equal the grain's current
permissions, the login $set is a no-op with no oplog entry, so isAdmin was
never derived and the owner had no Admin Panel.
Reconcile at grain startup (a migrated grain reboots once migration
completes): grant WeKan admin to every Sandstorm user whose stored
permissions include 'configure'. Promote only, never revoke here (that is the
change hook's job on a real permission change), so a stale/empty stored
permission set can never lock the owner out of the Admin Panel.
The storage engine was read only from serverStatus, which requires the
cluster-level clusterMonitor role. A per-database WeKan user (readWrite on
the wekan db only, as in docs/Platforms/FOSS/Docker/Meteor3/) is not
authorized to run it, so it was rejected and the field stayed 'unknown'.
Fall back to a $collStats aggregation, which needs only the collStats action
that read/readWrite already grant, and read the real engine (wiredTiger /
inMemory) from storageStats. The MongoDB compatible version and Database
commit were already correct: they come from buildInfo, which needs no
special privileges.
The postinstall script (scripts/patch-yargs-dirname.cjs) added in 6b409c5da
to fix the Meteor/Mocha test boot crash makes npm mark the root package with
hasInstallScript: true. Sync the lockfile to match package.json.
A low-privilege (comment-only / read-only) board member could escalate to
board admin and take over a private board via the board 'sort' collection
allow rule. To support drag-to-reorder, a second Boards.allow({ update })
rule returned true for any board member whenever the update touched the
'sort' field. Meteor applies the WHOLE modifier once any allow rule approves
and no deny rule rejects, and does not scope the approving rule to the field
that satisfied it. Because canUpdateBoardSort only checked that 'sort' was
AMONG the modified fields, a restricted member could smuggle arbitrary board
mutations (members, permission, title) into the same $set as 'sort' in one
DDP Boards.update call, making themselves admin, flipping the private board
to public, and evicting the legitimate owner. The last-admin deny rule only
inspected $pull, so a wholesale $set of the members array bypassed it.
Fix: restrict canUpdateBoardSort so the sort-reorder rule approves an update
only when 'sort' is the sole modified field. Defense in depth: the last-admin
deny rule now also rejects a $set rewrite of the members array that would
drop the last active admin. Regression test covers the multi-field smuggling
case. The legitimate All Boards drag-reorder is unaffected: it persists order
per-user in profile.boardSortIndex, not in the board document.
CVSS:3.1 8.8 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), CWE-863, CWE-269.
Thanks to 5ud0 / Tarmo Technologies and xet7.
- .github/workflows/meteor-spk.yml: assembles WeKan's modernized meteor-spk (the
packaging tool + its meteor-spk.deps: Node 24, FerretDB, Mongo 3.x CLIs, modern
sandstorm-http-bridge) via sandstorm-src/build-deps.sh — reusing sandstorm.yml's
setup — and zips it as meteor-spk-YYYY-MM-DD_HH_MM_SS.zip, the same kind of
self-contained bundle sandstorm-io/meteor-spk releases but with WeKan's deps baked in.
Uploaded as an artifact and to the newest GitHub Release. Needs no keyring (it does
not pack/sign a .spk).
- .github/workflows/sandstorm-store.yml: publishes an already-built .spk to the
Sandstorm App Market. Installs Sandstorm + assembles meteor-spk and restores
SANDSTORM_KEYRING like sandstorm.yml, downloads the newest .spk from the WeKan release
(built and attached by sandstorm.yml), renames it to wekan-<VERSION>.spk (VERSION from
the release tag, e.g. 9.88, overridable via inputs), and runs 'spk publish
wekan-<VERSION>.spk' exactly like releases/release-sandstorm.sh. Does not rebuild the
.spk.
Thanks to xet7.
The crash moved from yargs/lib/platform-shims/esm.mjs to yargs/build/lib/utils/
apply-extends.js (import.meta.resolve(config.extends)) — yargs' ESM build has more than
one file using import.meta. Rewrite the workaround to scan the whole node_modules/yargs
tree and rewrite every ESM-only construct (import.meta.url/.resolve/.dirname/.filename,
const require = createRequire(...), and yargs' own const __dirname) to the CommonJS
wrapper equivalents in one pass, so a new yargs file can't reintroduce the boot crash.
yargs is never executed at runtime here, so only valid CommonJS parsing matters.
Thanks to xet7.
Renaming only __dirname was not enough: yargs' esm.mjs also uses import.meta.url (invalid
in Meteor's CommonJS module wrapper -> 'Cannot use import.meta outside a module') and
redeclares require via createRequire(import.meta.url) (collides with the wrapper's
require). reify rewrites the file's import statements but not import.meta. Rewrite all
three to use the wrapper's __filename / __dirname / require, which yargs never actually
exercises here (it is only bundled, never called). Idempotent; also patches a file left
half-rewritten by the previous version of this script.
Thanks to xet7.
.meteorignore does not apply to node_modules under Meteor 3 / rspack (verified: the
rebuilt Mocha bundle still contained node_modules/yargs), so revert that no-op rule and
fix the actual crash instead.
Root cause (pre-existing, unrelated to app code): the whole yargs package gets pulled
into the server bundle as a transitive devDependency, and its ESM shim
node_modules/yargs/lib/platform-shims/esm.mjs declares a top-level
'const __dirname = fileURLToPath(import.meta.url)'. Meteor wraps that .mjs in a CommonJS
module function that already provides __dirname, so it collides —
'SyntaxError: Identifier __dirname has already been declared' — crashing the server
bundle at boot, which is why Mocha reported 0 tests.
Add scripts/patch-yargs-dirname.cjs, run from a package.json postinstall, which renames
yargs' local __dirname (and its .substring/.lastIndexOf uses) to __dirnameYargs so it can
no longer collide with the wrapper's. Idempotent and best-effort (never fails install);
yargs is not used at runtime here so the rename is inert for the app.
Thanks to xet7.
'meteor test' (Mocha) crashed at boot with 'Identifier __dirname has already been
declared'. Root cause is unrelated to app code: node_modules/yargs/lib/platform-shims/
esm.mjs declares a top-level 'const __dirname = fileURLToPath(import.meta.url)', which
collides with the __dirname that Meteor's CommonJS module wrapper already provides. yargs
gets pulled into the bundle only because i18next-sprintf-postprocessor (imported by
imports/i18n/tap.js) ships a stray rollup.config.js that does require('yargs'), and a
devDependency (mongodb) has since installed yargs 18 into node_modules so that require now
resolves. That build config is not part of the package's runtime entry
(index.js -> dist/commonjs), so exclude it from Meteor's bundle via .meteorignore.
Pre-existing (the same boot crash happened before this branch's test work) and independent
of the avatar/import-export feature.
Thanks to xet7.
Two build/load fixes surfaced by running the full test suite:
- server/imports.js: import the new server-only files so they actually load. In
mainModule mode a file not imported here never loads, so Accounts.onLogin avatar
localization (server/avatarLocalizationOnLogin.js) and the imported-user reconciliation
Meteor methods (server/importedUserReconciliation.js) would silently never register.
- Test __dirname collision: 'meteor test' crashed at boot with 'Identifier __dirname has
already been declared'. The client test index (client/lib/tests/index.js) loads
boardTriggersClass.tests.js, which referenced the bare __dirname global; under
meteor test that makes Meteor inject a colliding with its CommonJS
wrapper's, aborting the whole server bundle (the same failure already fixed once in
dependencies.openapi.tests.js — this was the next file to trip it). Replace __dirname
with a process.cwd()/PWD walk-up in boardTriggersClass.tests.js, and defensively in the
node-run tests/rtl.test.js, tests/stickers.test.js and tests/stickers.packs.test.js too.
Thanks to xet7.
Split the testable, security- and correctness-critical logic of the new avatars +
original-members feature into pure Node modules (module.exports, no Meteor) and cover them
with plain-Node tests/*.test.cjs (positive AND negative), matching the repo's existing
unit-test style. Wired into the test:unit:node script.
- models/lib/avatarUrlSafety.js (from server/lib/localizeAvatar.js): isExternalAvatarUrl,
isBlockedIp (SSRF ranges), decodeDataUri, checkUrlHostSync. Tests assert external vs
local/relative/non-http URLs, that private/loopback/link-local/CGNAT/metadata/multicast
IPv4+IPv6 (incl. IPv4-mapped) are blocked while genuine public addresses and near-miss
ranges are allowed, data: decoding, and that non-http(s) schemes, localhost and
metadata hosts are rejected.
- models/lib/importedUserReconciliationPlan.js (from server/importedUserReconciliation.js):
planReconciliation. Tests: matches merge, non-matches deactivate, never match another
placeholder or self or a username-less placeholder.
- packages/wekan-ldap/server/ldapPhoto.js (from sync.js): getLdapPhotoBuffer. Tests the
Buffer / array / {type:'Buffer'} / base64 shapes and jpegPhoto>thumbnailPhoto, and that
missing/empty/short values yield null (never throw).
- models/lib/importedBoardMemberPlan.js (from wekanCreator.js): planImportedBoardMember.
Tests: unmapped member kept by original id but inactive+non-admin, mapped role preserved,
importer and id-less members dropped.
The extractions are behaviour-preserving; the app modules now import these helpers.
Thanks to xet7.
Make it obvious which board members are backed by a real account and which are not,
both on card avatars and in the right sidebar member list.
- userAvatar (js/jade/css): the avatar gets an 'imported-member' class (dashed grey ring
+ amber '?' corner badge) for un-reconciled board-import placeholders
(authenticationMethod:'imported'), and an 'inactive-member' class (greyscale + dim +
grey badge) for members deactivated on the board (e.g. a person not in LDAP after
reconciliation). A placeholder is usually both; a real active account gets neither. The
tooltip explains the state.
- boards.js membersForSidebar(): active members first (as before) then the inactive /
imported ones appended, and sidebar.jade uses it, so the member list shows EVERYONE and
which are active vs not instead of hiding inactive members.
- i18n: imported-member-no-account, inactive-member.
Thanks to xet7.
server/importedUserReconciliation.js turns the inert import placeholders into the right
real members deliberately, after import — never auto-mapped during import.
- reconcileImportedUsers(): for each authenticationMethod:'imported' placeholder, find a
real account with the same username (not another placeholder) — the valid accounts are
whatever real WeKan accounts exist, typically provisioned by LDAP/OIDC at login — and
merge the placeholder into it; if none exists (e.g. the person is not in LDAP) leave the
placeholder and its board memberships inactive (isActive:false).
- mergeImportedUserInto(placeholderId, targetId): reassign every reference (board.members,
card.members, card.assignees, activities.userId, cardComments.userId) from the
placeholder to the target, reusing the target's membership if it already is a member,
then remove the placeholder.
- Admin-only Meteor methods reconcileImportedUsers and mergeImportedUser(placeholderId,
targetId) for the automatic sweep and for one-off deliberate mapping.
Because reconciliation matches against existing real accounts (which LDAP populates on
login) it needs no direct LDAP query and is provider-agnostic. Merges reassign by the
preserved original _id, so nothing is lost.
Thanks to xet7.
Importing a WeKan board no longer collapses unmapped members onto the importing user (a
wrong mapping attaches the wrong person and can leak board permissions). Instead each
original member carried in board.users becomes an inert placeholder user:
- createPlaceholderUsers() reuses the ORIGINAL _id, so every card/comment/activity
member reference resolves to the right person with no remapping, and populates
this.members as an identity map (id -> id) so _user() keeps the original member.
- Placeholders are created with Users.direct.insertAsync (bypassing the after.insert
hooks — Sandstorm identity sync and the disableRegistration/invitation-code gate that
would otherwise reject a non-account user), marked authenticationMethod:'imported',
loginDisabled:true, isActive:false, and carry NO password or email. Username collisions
suffix the placeholder's name so an existing account is never renamed/stolen.
- The member's avatar (embedded as base64 by the exporter) is restored into files/avatars
via the localizer, so the original picture shows and is exportable again (Sandstorm too).
- Board membership adds imported members inactive and non-admin, so they are visible but
hold no permissions until deliberately reconciled later; the importer stays sole admin.
Also guard the Sandstorm Users.after.insert hook to no-op on users without
services.sandstorm (placeholders), which otherwise threw reading preferredHandle.
Mapping/merging to real accounts and LDAP reconciliation are a later, deliberate step.
Thanks to xet7.
Board export already carried the original members' username, fullname and initials (the
field whitelist excludes passwords, emails and services). Now, for each member whose
avatar is a local WeKan file, embed the file itself as base64 (profile.avatarFile +
avatarFileName + avatarFileType) alongside the existing avatarUrl reference, in both the
in-memory build() and the streaming buildStream() paths.
Because this reads a local avatars file (no outbound fetch), it works inside a Sandstorm
grain too: a board that already has many stored avatars can be exported with every
member's picture intact, ready to re-import elsewhere. External, not-yet-localized
avatars are still exported as their URL only (Increment 1 localizes those into files
first, on board open / at login).
Thanks to xet7.
Second set of triggers so external avatars from identity providers become local WeKan
avatars (files/avatars), shown in WeKan and carried by board export/import.
- LDAP (packages/wekan-ldap/server/sync.js): syncUserData now reads the binary
jpegPhoto / thumbnailPhoto (tolerating Buffer / array / {type:'Buffer',data} / base64
shapes) and, unless the user already has a locally-stored avatar, stores it as a
self-contained data: URI in profile.avatarUrl. That displays immediately and needs no
coupling from this package to app code; the app then materialises it to a real file.
- OIDC (packages/wekan-oidc/oidc_server.js): capture the standard claim (with
an OAUTH2_AVATAR_MAP override) into serviceData and set profile.avatarUrl for new users.
- App (server/avatarLocalizationOnLogin.js): Accounts.onLogin localizes the logging-in
user's external avatar immediately (provider-agnostic), complementing the board-open
trigger. Fire-and-forget, idempotent, never blocks login. (Inside a Sandstorm grain
outbound fetch is sandboxed, so a Sandstorm profile picture is a best-effort no-op here
and needs client-assisted capture — a later step.)
Thanks to xet7.
First trigger for external-avatar localization: the single-board publication
(publishComposite('board')) now fires a best-effort, fire-and-forget
localizeBoardMemberAvatars(boardId). For every member whose profile.avatarUrl points
outside WeKan, it copies the image into WeKan's own files/avatars (via the SSRF-guarded
helper) and repoints avatarUrl at the local copy. Idempotent (already-local avatars are
skipped) and it never blocks or delays the publication.
This is the universal catch-all: no matter how a member's avatar became external
(OAuth2/OIDC picture URL, gravatar, a pasted URL), opening the board makes it a local,
exportable WeKan avatar. (Note: inside a Sandstorm grain outbound fetch is sandboxed, so
Sandstorm profile pictures need the provider-side capture added next; LDAP jpegPhoto is
binary and is imported at login, also next.)
Thanks to xet7.
First piece of making external avatars (Sandstorm profile pictures, LDAP jpegPhoto,
OAuth2/OIDC picture claims, gravatar, any URL/data-URI) into local WeKan avatar files
under WRITABLE_PATH/files/avatars, so they display without the identity provider and are
carried by board export/import.
server/lib/localizeAvatar.js:
- isExternalAvatarUrl(url): true unless already a local /cdn/storage/avatars/ (or legacy
/cfs/files/avatars/) URL.
- localizeAvatarFromBuffer(userId, buffer, {type,name}): write bytes into the Avatars
FilesCollection (onAfterUpload sets the user's local profile.avatarUrl).
- localizeAvatarFromUrl(userId, url): fetch (or decode a data: URI) then store.
- localizeUserAvatarIfExternal(user): idempotent no-op when already local.
Every network fetch is SSRF-guarded: http/https only; the host is resolved and any
private, loopback, link-local, CGNAT, multicast or cloud-metadata (169.254.169.254)
address is refused; 8s timeout; 5 MB cap; image content-type only. Not wired to any
trigger yet (board-open / export / login flows come next).
Thanks to xet7.
Now that the grain boots, logs in, lists/opens boards, uploads/downloads attachments,
and migrates an old MongoDB 3 grain end to end, drop the two temporary diagnostics:
- models/attachments.js: revert the Meteor-Files debug flag to false (it was enabled on
Sandstorm to trace the upload 'session expired [408]' issue and was spamming the grain
log with the full FilesCollection dump and every find()).
- server/ferretdbQueryDebug.js: remove the mongodb Collection.find wrapper that logged
FerretDB-rejected selectors (used to find the $elemMatch 'unknown operator: userId'
issue, since fixed in wekan/FerretDB).
Thanks to xet7.
Two UX requests once the migration itself works end to end:
- Auto-open All Boards. Previously the dashboard sat on the grain URL for 60s after
completion and the admin had to reload to reach WeKan. On success the importer now
exits after ~5s (long enough for the browser to fetch the done page), and the done
page runs a JS poller that fetches '/' until WeKan's app shell answers (tolerating the
brief importer->WeKan port hand-off gap) and then location.replace('/') opens All
Boards. The spinner keeps spinning through the hand-off so it is clear the grain is
still working; no meta-refresh on the done page (a refresh mid-hand-off would hit a
dead port). On failure it still stays up a minute with the errors.
- WeKan colours. Recolour the dashboard from the dark scheme to WeKan's blue/white/grey
(belize blue #2980b9 headings and spinner, white card on light-grey background, grey
borders, system font).
Thanks to xet7.
With text collections migrating, the 3 attachments still produced 0 extracted files and
errors like 'parse attachments.chunks: Unexpected Binary Extended JSON format
{"$binary":"iVBOR..."}'. Two causes, both fixed:
1. Legacy Extended JSON v1 binary. mongo 3.x mongoexport writes binary as
{"$binary":"<b64>","$type":"00"} (v1), but modern bson EJSON.parse only
accepts v2 {"$binary":{"base64":...,"subType":...}}. Rewrite v1 -> v2 per line
before parsing, so chunk data (and any binary in text collections) parses.
2. Meteor-Files native GridFS buckets were unhandled. The grain stores attachments in
attachments.files + attachments.chunks (FilesCollection record in the attachments
collection), not CollectionFS's cfs_gridfs.*. Reassemble those buckets to disk,
linking each GridFS file to its record via metadata.fileId/versionName, then repoint
the migrated 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. Also exclude <bucket>.files/.chunks (and tempstores) from the text
migration so binary chunks are no longer run through EJSON as documents.
Thanks to xet7.
Text collections exported and 'inserted N/N' was logged, but every document actually
failed with 'Unsupported OP_QUERY command: update' — nothing reached FerretDB. Cause:
requireAny('mongodb') 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.
(Separately, GridFS attachment/avatar extraction still finds 0 files for this grain —
its attachments appear to be in Meteor-Files buckets (attachments.files/.chunks) rather
than the CollectionFS cfs_gridfs.* the importer currently handles; to be addressed once
the modern driver confirms text migration and the real attachment collection counts.)
Thanks to xet7.
Link the mongodb default-import, mongoexport --quiet removal, diagnostic/dashboard, and
createRequire commits inline within their parent migration bullets.
Thanks to xet7.
The EJSON diagnostic was conclusive: require('bson') returned an object with no EJSON,
mongodb.EJSON was undefined, and mongodb/lib/bson* were MODULE_NOT_FOUND. Cause: the
importer sits at the deps root next to the OLD meteor-spk 0.6.0 base node_modules
(bson 1.x with no EJSON at all, plus an ancient mongodb that has MongoClient but no
EJSON re-export), kept there only for the niscu->3.0 stage — so a bare require resolved
those adjacent copies. WeKan's current bson/mongodb (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. This also
switches the importer to the modern mongodb driver — the same one the WeKan app uses
against FerretDB.
Thanks to xet7.
The mongodb default import exposed MongoClient but NOT EJSON (mongodbPkg.EJSON was
undefined), so the previous 'take EJSON from mongodb' attempt still hit the FATAL
guard. Node 24's ESM default-interop for these CommonJS packages drops the
getter/re-export used for EJSON. Switch to createRequire (CJS require returns the real
module.exports with getters intact and honors NODE_PATH), and resolve EJSON by trying,
in order: mongodb.EJSON, mongodb/lib/bson.js, mongodb/lib/bson, bare bson's .EJSON,
and bare bson itself — falling back with a diagnostic list of what each attempt
returned so a remaining failure names the cause instead of just 'undefined'.
Thanks to xet7.
With mongoexport connecting, every collection then failed with 'parse <coll>: Cannot
read properties of undefined (reading parse)' — EJSON was undefined. The importer runs
with NODE_PATH=programs/server/node_modules, but the EJSON-bearing bson (7.3.0) lives
under programs/server/npm/node_modules, so a bare 'import bson' did not resolve to it
and EJSON came out undefined. The mongodb driver (which resolves fine — MongoClient
works) bundles bson and re-exports EJSON from lib/bson.js, so take EJSON from the same
default import and drop the separate bson dependency. Add an upfront guard that fails
loudly if EJSON.parse is ever missing instead of spamming one error per collection.
Thanks to xet7.
The real reason every mongoexport failed (revealed once --quiet was dropped):
'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) — so mongoexport could
never reach it, while the mongo shell (whose host defaults to 127.0.0.1) connected
fine and listed all 42 collections. Pass --host 127.0.0.1 explicitly.
Also fill the dashboard Activity panel from the first moment (mongoexport-ready line,
and one line per collection including empty ones) so progress is visible live instead
of the panel sitting on '(waiting…)' while only red connection errors accumulated.
Thanks to xet7.
The --version probe confirmed the bundled mongoexport runs fine (r3.2.22), yet every
per-collection export exited status=1 with empty stderr AND stdout. The empty stderr
was mongoexport's own --quiet flag suppressing its failure message. Drop --quiet so
the real reason (e.g. 'Failed: <reason>') prints to stderr; mongoexport's normal
progress lines also go to stderr, so stdout stays clean Extended JSON either way.
Also surface progress on the dashboard as the user asked: a rolling Activity log
(last ~15 lines: collections found, per-collection export/insert counts, GridFS file
extraction counts) rendered in a panel and mirrored to the grain log, so it is clear
what the migration is doing rather than only red errors appearing later.
Thanks to xet7.
Every per-collection mongoexport failed with 'failed: undefined' because the error
only logged (r.stderr || r.error): an empty stderr with a non-zero/killed status
(e.g. a SIGSEGV, where spawnSync reports status=null, signal='SIGSEGV', stderr='')
printed as 'undefined', hiding the real cause. Log a full describe(r) instead
(status, signal, error code, stderr AND stdout snippets), and probe
'mongoexport --version' / '--help' once at startup so the next run shows whether the
bundled mongoexport binary itself is broken (dies on --version too → an ABI/bundling
problem) or only the export invocation is. The mongo shell on the same libs works
(listCollections succeeds), so this narrows it precisely.
Also make the progress dashboard obviously live: a CSS spinner while running (✅/❌
when done), a server 'updated' timestamp that changes on every 2s auto-refresh, and
an error counter — the previous page refreshed but showed no sign of activity.
Thanks to xet7.
Same CommonJS/ESM interop issue as the bson import: with { EJSON } fixed, the
importer next threw 'Named export MongoClient not found. The requested module
mongodb is a CommonJS module'. The bundled mongodb driver is CommonJS under Node
24's ESM loader, so import the default and destructure MongoClient. These are the
only two third-party imports; the rest are node: builtins.
Thanks to xet7.
With the WiredTiger cache fixed, mongod 3.0 now starts and the migration importer
runs, but it crashed immediately: 'import { EJSON } from "bson"' threw
"SyntaxError: Named export 'EJSON' not found. The requested module 'bson' is a
CommonJS module". bson (as bundled in WeKan's server node_modules) is CommonJS, so
Node 24's ESM loader exposes no named exports on it. Import the default and
destructure EJSON from it, as Node's own error message advises. Shared by the Snap
migration too (same Node 24).
Thanks to xet7.
mongod 3.0.7 parses --wiredTigerCacheSizeGB as an integer number of GB, so the
0.25 from the previous commit failed at startup with 'Error parsing option
wiredTigerCacheSizeGB as int: Bad digit "." while parsing 0.25' and the migration
still crash-looped. Use 1 (GB). It is a cache cap, not a preallocation, so a short
migration of a normal-sized grain never actually uses that much.
Thanks to xet7.
Importing an existing WeKan grain crash-looped in the one-time MongoDB 3 -> FerretDB
migration: mongod 3.0 forked and its child aborted with exit code 14. Two bugs:
1. WiredTiger cache_size=0G. mongod 3.0 sizes the WiredTiger cache from detected
RAM (RAM/2 - 1GB), but inside a Sandstorm grain sandbox RAM detection returns 0,
so it computes cache_size=0G and WiredTiger refuses to open (minimum is 1MB),
logging 'Value too small for key cache_size' and 'Fatal Assertion 28561' to
/var/migration-mongod.log before aborting. Pass an explicit
--wiredTigerCacheSizeGB 0.25 (256MB) to both mongod invocations (the niscu ->
3.0 stage, which writes new WiredTiger data, and the 3.0 -> FerretDB stage) so
the cache size never depends on RAM detection. The data itself is fine (turtle
file: WiredTiger 2.5.3, i.e. written by mongod 3.0; 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' (the niscu stage reads/writes 'meteor', and a
real grain's WiredTiger catalog shows meteor.* collections), 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.
Two grain-navigation regressions vs 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. useraccounts' ensureSignedIn route trigger and 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 All Boards list renders and reactively
fills in once the platform 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
(sandstorm shell/imports/client/grain-client.js). The sync was a bare top-level
Tracker.autorun that could run before flow-router-extra's reactive path tracking
was initialised and then never re-run. Restore v6.15's event-driven
FlowRouter.triggers.enter (fresh entering path, no dependency on init order) and
additionally keep a watchPathChange() autorun wrapped in Meteor.startup as a
backup. setTitle now also re-runs on route change.
Thanks to xet7.
On Sandstorm the grain download route returned 403 for private boards, so
attachment thumbnails, minicard covers and the slideshow all showed broken
images even though the upload succeeded and the file was on disk. The download
handler (server/routes/universalFileServer.js) authorizes private-board files
via 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 reaching WeKan is an authenticated grain user; trust it. Both
isAuthorizedForBoard() and isAuthorizedForAvatar() now short-circuit to 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.
Link the fix that switches attachment uploads to DDP transport on Sandstorm, since
the bridge strips Meteor-Files' custom x-* HTTP upload headers.
Thanks to xet7.
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. The Meteor-Files HTTP
upload protocol 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 (web-session.capnp) does not include those, so the sandstorm-http-bridge
strips them: the server never sees x-start, treats every request as a chunk
continuation, cannot find the per-fileId session and returns 408. Use
transport: 'ddp' on Sandstorm (detected via Meteor.settings.public.sandstorm) so
uploads go over DDP method calls instead of custom HTTP headers; HTTP transport is
kept everywhere else (it avoids the Safari DDP-reconnect stall).
Thanks to xet7.
Attachment uploads in the grain fail with HTTP 400 "Can't continue upload, session
expired [408]": the upload start succeeds but the per-fileId session is gone by the
time a chunk arrives (both the in-memory _currentUploads entry and the
__pre_attachments pre-collection doc are missing), which points at the polling
observe (FerretDB has no oplog) firing a spurious removed event and aborting the
upload. The Attachments FilesCollection had debug: false, so nothing about the
upload path is logged. Enable Meteor-Files debug on Sandstorm only (gated on
Meteor.settings.public.sandstorm) so the grain debug log shows the start /
createStream / observer / continueUpload steps and pinpoints where the session is
lost. TEMPORARY: revert to debug: false once the upload is fixed.
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. Sync it from a reactive
Tracker.autorun on FlowRouter.watchPathChange() instead (the same mechanism the
setTitle sync already uses), so every route change posts setPath to the shell and
the grain URL becomes /grain/<id><path>.
Thanks to xet7.
Opening a board in the grain fails with "MongoServerError: unknown operator: userId"
(BadValue) - FerretDB rejecting a query MongoDB accepts - but the driver stack trace
has no WeKan call site, so the offending selector is unknown. This wraps the raw
mongodb Collection.find() to log the collection name and exact selector whenever a
cursor iteration throws, to pinpoint the query. TEMPORARY: to be removed once the
query is rewritten FerretDB-compatibly.
Thanks to xet7.
The Sandstorm login was actually succeeding - Meteor.userId() gets set (confirmed:
Meteor.connection._userId held a valid id, Meteor.loggingIn() false) - but the grain
stayed on the sign-in page. WeKan's home route (renderBoardList) checks
Meteor.userId() once and, because the Sandstorm header login is asynchronous and
uses connection.setUserId() (bypassing accounts-base, so no Accounts.onLogin fires),
finds it still null on first render and redirects to 'atSignIn' - where the user is
stranded even after login completes moments later. Add a Sandstorm-only reactive
autorun that 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.
Link the fix that rewrites ROOT_URL to the grain's real URL so DDP, dynamic
imports and the Sandstorm auto-login stop failing cross-origin.
Thanks to xet7.
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>)
via sandstorm-http-bridge, so the client sent its DDP connection and dynamic-import
fetches to 127.0.0.1:4000 - cross-origin and unreachable from the browser - and the
header-based login handshake (a DDP method call) never completed. Add a
WebApp.addRuntimeConfigHook that rewrites ROOT_URL to the grain's real base URL
(X-Sandstorm-Base-Path) per request, and re-asserts the SANDSTORM flag, so the
client talks to the same origin it loaded from. DDP, dynamic imports and the
Sandstorm auto-login now work.
Thanks to xet7.
Link the fix that sets process.env.SANDSTORM=1 in the launcher so the
Sandstorm header-based auto-login runs and pages stop showing "Must be logged in".
Thanks to xet7.
WeKan loads 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 (start.js set
MONGO_URL/ROOT_URL/PORT/WRITABLE_PATH but not SANDSTORM, and the pkgdef env didn't
either). The launcher now sets process.env.SANDSTORM = '1' before loading the WeKan
bundle, so the package enables the runtime flag and the client auto-logs-in the
Sandstorm user from the X-Sandstorm-* headers. (App code detects Sandstorm via a
separate Meteor.settings.public.sandstorm flag from the pkgdef METEOR_SETTINGS,
which already worked.)
Thanks to xet7.
Link the change that stops auto-creating a board on a new grain and maps the
grain's Sandstorm permissions to the user's global WeKan role.
Thanks to xet7.
WeKan on Sandstorm is multi-board now, so a new grain/user no longer gets a
hard-coded 'sandstorm'/libreboard board auto-created - the user creates their own
boards from the All Boards page. The Users.after.insert hook no longer inserts that
board + Default swimlane. 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 instead - 'configure' (grain owner) becomes a WeKan admin, everyone else is a
regular user who can create and manage their own boards. Dropped the now-unused
Boards/Swimlanes imports.
Thanks to xet7.
WeKan on Sandstorm originally opened a single hard-coded board
(/b/sandstorm/libreboard) and redirected "/" to it. It now supports many boards and
that libreboard is no longer the right destination, so redirecting to it is wrong.
Remove the WebApp.handlers.get("/") redirect entirely: "/" now falls through to
WeKan's normal serving, whose client "home" route (config/router.js) renders the
All Boards list - the right landing page for a multi-board grain. This also removes
the server-side redirect that browsers rejected as a Corrupted Content Error
(FlowRouter.path does not resolve on the server + Content-Length mismatch).
Thanks to xet7.
Link the fix that builds the Sandstorm board redirect path directly and sends a
body with a matching Content-Length, so the grain's "/" stops failing with a
browser Corrupted Content Error.
Thanks to xet7.
The grain's "/" served a broken 301: 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). Build the board path directly (/b/:id/:slug, the
'board' route) and send a real HTML body (meta-refresh + link) with a matching
Content-Length, so the redirect to the hard-coded Sandstorm board works. Together
with the Accept-Encoding strip (keeps Content-Length valid) and the modern bridge.
Thanks to xet7.
Link the fix that bundles a modern sandstorm-http-bridge (from the Sandstorm
install) so the grain stops serving Corrupted Content on WeKan's "/" redirect.
Thanks to xet7.
The grain boots, but the page failed with a browser "Corrupted Content Error"
(NS_ERROR_NET_CORRUPTED_CONTENT) on WeKan's "/" redirect (0 bytes, ~8.5s, then
failed). 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).
Sandstorm is amd64-only so one binary covers it. The sandstorm.yml workflow now
installs Sandstorm before assembling the deps so the bridge is available on the CI
runner. Complements the app-side Accept-Encoding strip.
Thanks to xet7.
Link the fix that strips Accept-Encoding in the Sandstorm grain so Meteor serves
uncompressed responses and the browser stops showing a Corrupted Content Error.
Thanks to xet7.
The grain now 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. Strip
Accept-Encoding in a WebApp.rawHandlers middleware (which runs before Meteor's
static/boilerplate serving) so responses go out uncompressed; bandwidth is a
non-issue behind the local bridge.
Thanks to xet7.
Link the fix that makes the services.sandstorm.id unique index use boolean
options so FerretDB accepts it and the Sandstorm grain boots past index creation.
Thanks to xet7.
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. Use real booleans (unique: true, sparse: true).
Thanks to xet7.
Link the fix that imports the Users/Boards/Swimlanes/Activities collections and
drops the removed-HTTP-package monkey patch, so the Sandstorm grain boots past
the capnp guard.
Thanks to xet7.
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): (1) it referenced the Users, Boards,
Swimlanes and 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 (2) it monkey-patched `HTTP.methods` from the meteor/http package, which
was removed in the Meteor 3.x migration, so `HTTP` was undefined. Import the
collections (and Accounts) explicitly, and remove the obsolete HTTP.methods patch
(WeKan's REST API no longer uses it - it uses WebApp/JsonRoutes with header auth).
Thanks to xet7.
Link the release-workflow change that builds amd64/arm64 natively on GitHub and
moves the exotic arches to a non-blocking per-arch Launchpad matrix, so the
release no longer hangs hours on riscv64.
Thanks to xet7.
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. Split it 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.
Link the fix that stops capnp.node's Node 24 ABI mismatch from crash-looping
the Sandstorm grain; the grain now boots and core WeKan works via the
sandstorm-http-bridge headers.
Thanks to xet7.
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. Load Cap'n Proto lazily in a try/catch and degrade 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 the Sandstorm activity
notifications - and they log a clear warning. These can be restored by rebuilding
node-capnp for Node 24, or reimplemented over the bridge's HTTP/JSON API (see the
Sandstorm CHANGELOG: use Cap'n Proto APIs without Cap'n Proto).
Thanks to xet7.
Link the fix that points FerretDB's --state-dir to writable /var so the
Sandstorm grain starts instead of crash-looping on a read-only /state.json.
Thanks to xet7.
FerretDB persists a state.json (version/UUID) via its state provider even
when telemetry is 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 the
FERRETDB_STATE_DIR env) in startFerret(), covering both the migration and the
steady-state FerretDB launches.
Thanks to xet7.
List the glibc-loader grain crash-loop fix, the Sandstorm build-workflow
userns/ref fix, and the Meteor unit tests __dirname server-boot fix in the
Upcoming release section, each linking to its commit.
Thanks to xet7.
server/lib/tests/dependencies.openapi.tests.js is an ES module (top-level
import) that referenced the bare __dirname global. Under Node 24 / Meteor 3.5
the compiler injects "const __dirname = fileURLToPath(import.meta.url)" for
ESM files that use __dirname, which collides with the __dirname the CommonJS
module wrapper already provides, so the whole 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`, and the
suite skips gracefully otherwise).
Thanks to xet7.
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. Also added
a "ref" workflow_dispatch input and check out that ref instead of a hardcoded
main, so a fix branch can be built and tested before it is merged to main.
Thanks to xet7.
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
into the deps so the loader and libc are the same glibc, and adds a [verify]
gate that fails the build if the bundled libc and loader glibc versions
differ or the bundled node cannot run under them - turning a silent grain
crash-loop into a loud build failure.
Thanks to xet7.
Dependabot #6451 bumped lib-storage to ~3.1085.0, whose peer requires
client-s3 ^3.1085.0, but client-s3 was left at ^3.1071.0 — breaking
meteor npm install / npm ci with an ERESOLVE peer conflict.
- Drop the ~300 MB of modern MongoDB Database Tools (wekan/mongo-tools) from the
Sandstorm build: they are unused there (Sandstorm backs up/restores grains
itself; the MongoDB 3 -> FerretDB migration uses the legacy migratemongo CLIs +
the .mjs importer). They stay in the .zip bundle / Docker / Snap, which use them.
- Set PUPPETEER_SKIP_DOWNLOAD=1 for the Meteor build (puppeteer is a test-only
devDependency; its ~150 MB Chromium must never end up in the .spk).
- Pack step prints the .spk size and warns when it exceeds 100 MB.
meteor-spk pack crashed with 'open(/home/runner/.sandstorm-keyring): No such file
or directory' because the keyring restore step wrote the decoded SANDSTORM_KEYRING
secret to ~/.sandstorm/sandstorm-keyring, but spk reads the app private key from
~/.sandstorm-keyring (a file directly in $HOME). Write it to the correct path, and
fail early with an actionable message when the secret is missing (the .spk cannot
be signed without it) instead of the cryptic later crash.
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 lib that no longer exists). When step
[3/7] refreshed them with the host's newer libs, 'cp -fL' refused with 'not writing
through dangling symlink' and failed the Sandstorm build. Add --remove-destination
so cp deletes the existing destination (dangling symlink included) before copying
the host's real library. Verified: plain 'cp -fL' reproduces the error; with
--remove-destination it succeeds and writes a real file.
In the swimlanes view, boardBody.js disabled the .js-swimlanes sortable — which
also carries moving a card from one swimlane to another — with !isBoardAdmin(),
though its own comment said it should be disabled only for non-members. So a normal
board member could move a card within a swimlane but not between swimlanes (and
could not reorder swimlanes). Gate it on !Utils.canModifyCard() instead (the client
write-access predicate: board member, not comment-only/worker/read-only), matching
the server's allowIsBoardMemberWithWriteAccess.
The install page (../w/wekan.fi/install/index.html) links to Node.js downloads for
each snap/bundle arch: the OFFICIAL nodejs.org build (amd64/arm64/s390x/ppc64le)
and the UNOFFICIAL unofficial-builds.nodejs.org build (riscv64, which nodejs.org
has no binary for). release-website.sh only updated the displayed Node.js version
number, and version.sh's local website block did not touch Node.js at all, so those
download URLs went stale (404) after a Node.js bump.
Both now rewrite the version in the nodejs.org/dist/vX.Y.Z and
unofficial-builds.nodejs.org/download/release/vX.Y.Z paths and the
node-vX.Y.Z-linux-<arch> filename to the current Dockerfile NODE_VERSION.
FerretDB/ and sandstorm/ were already ignored; add /mongo-tools/ and /mongosh/ so
that temporarily cloning those wekan repos under this repo for editing never risks
committing them (they are separate git repos).
core24 allows the candidate channel (core26 does not), so the automated
release-all.yml snap job publishes to candidate + beta + edge. The stable channel
is not published by the workflow — it is done manually later once proven. Updated
the workflow, snapcraft.yaml header, CHANGELOG and CPU-platforms.md.
The default snapcraft.yaml is base: core24 (grade: stable) so it CAN be published
to the Snap stable channel, but that is done manually once it is proven stable
enough (core26 cannot go to stable). Revert the automated release-all.yml snap job
to publish to edge + beta channels (was candidate + edge). Update the workflow
header, snapcraft.yaml header, CHANGELOG and CPU-platforms.md to match.
Bundle launchers (releases/ferretdb/start-wekan.sh/.bat): run the bundle's own
per-platform binaries — FerretDB (./ferretdb[.exe]) in the background and WeKan
(./main.js on the bundled ./node[.exe]) in the foreground — inside a restart loop,
so if WeKan exits the whole stack restarts. Ctrl-C / closing the window stops both.
Snap wekan part: the wekan-<arch>.zip bundle is now the single source of every
binary. Handle all snap arches (amd64, arm64, s390x, ppc64el->ppc64le, riscv64);
use the bundle's OWN arch-correct Node.js (fixes riscv64, which nodejs.org has no
build for) instead of re-downloading from nodejs.org; move the bundle's per-arch
MongoDB Database Tools into $SNAP/bin; keep the bundle's ferretdb. Drop the
separate mongotools part (the tools already ship in the bundle), so nothing is
downloaded twice.
Previously the per-arch MongoDB Database Tools were only in the Snap and the
Windows bundle. Now every build embeds them from the wekan/mongo-tools fork's
newest release (per-arch <tool>-<arch>):
- Linux .zip bundles (amd64/arm64/s390x/ppc64le/riscv64) download their arch's 8
tools; the win64 and macOS jobs drop the inherited Linux tools and add their own
(win64 .exe, mac-arm64). The Docker image inherits them from the Linux bundle.
- Sandstorm build-deps.sh adds the amd64 tools (separate from the legacy MongoDB
3.2 migratemongo CLIs used for the one-time migration).
All from wekan/mongo-tools, none from mongodb.com.
Databases / MongoDB clients:
- Remove the mongosh binary everywhere (snap + bundles). All scripted DB access
(readiness ping, replica-set initiate/status, v8.43 schema migration) now runs
through the new snap-src/bin/db-eval (bundled Node.js 24 + the mongodb driver).
Ports wekan-control, mongodb-control, migration-control, start-wekan.sh/.bat and
migrate-schema-v843.js -> .mjs off mongosh. The legacy MongoDB 3.2 mongo shell
(migratemongo, amd64) stays for migration-time reads only.
- MongoDB Database Tools now come from the wekan/mongo-tools fork (pure Go, every
arch) instead of mongodb.com, in snapcraft and the Windows bundle. version.sh /
test-download-urls.sh no longer probe mongodb.com for mongosh/tools. The MongoDB 7
server (mongod) is still fetched from MongoDB (amd64/arm64 only).
- FerretDB v1 downloaded per-arch (ferretdb-<arch>) from wekan/FerretDB, no
ferretdb.zip: release-all.yml bundle jobs, docker-compose.yml, sandstorm build.
Snap:
- Default snapcraft.yaml is now the core24 grade:stable build (core26 variant kept
as snapcraft-core26.yaml); release publishes to candidate + edge.
- Add s390x, ppc64el, riscv64 platforms as FerretDB-only (mongod not built there);
new installs default to FerretDB v1 (snap/hooks/install already guards existing
MongoDB data), DDP_TRANSPORT=sockjs. Fix Caddy ppc64el->ppc64le mapping.
Docs: add docs/Platforms/FOSS/Snap/CPU-platforms.md; update CHANGELOG and the
Sandstorm migration doc.
Add a "Build from source & start (up -d --build)" action to the Docker
menus in rebuild-wekan.sh and rebuild-wekan.bat. It builds the wekan-app
image from the local Dockerfile, tags it as the image the chosen compose
file references (ghcr.io/wekan/wekan:latest), and starts that freshly
built container instead of a possibly-stale prebuilt image pulled from
the registry - useful when a source change (e.g. the FerretDB
Version-page detection) is not in the pulled image yet.
Remove the obsolete top-level "version:" attribute from all docker
compose files, which Docker Compose v2 warns about and ignores:
docker-compose.yml, docker-compose-ferretdb-v2-postgresql.yml,
docker-compose-multitenancy.yml, .devcontainer/docker-compose.yml, and
docs/Databases/ToroDB-PostgreSQL/docker-compose.yml.
Thanks to xet7 !
Rename docker-compose-ferretdb-v1-sqlite.yml -> docker-compose.yml (the
new default) and the old MongoDB docker-compose.yml ->
docker-compose-mongodb-v7.yml, so "docker compose up -d" uses the light,
self-contained FerretDB v1 + embedded SQLite from
https://github.com/wekan/FerretDB by default.
Update rebuild-wekan.sh and rebuild-wekan.bat Docker menus to list
FerretDB v1 SQLite first (default) and point at the new filenames.
Update the compose files' own header comments (self-identification and
cross-references), note the new default at the top of docker-compose.yml,
and update the Docker docs (main Docker.md gets a compose-file/database
map; FerretDB2-PostgreSQL.md points at the v2 postgresql compose file).
Thanks to xet7 !
The Dev server options killed only the app port, but "meteor run" also
starts an rspack dev server on 8080 that can outlive the meteor parent.
A leftover one made restarting a dev server crash with
"Error: listen EADDRINUSE ... :8080". The kill now frees both the app
port and the rspack port 8080 (Meteor.devServerPort || 8080), matching
the rspack watcher by its devServerPort env.
Port detection now checks the listening socket directly (ss/lsof with a
bash /dev/tcp fallback that needs no external tools; netstat on .bat)
instead of an HTTP probe, so it also catches a server that is still
building and not yet serving. Fixes a hang where lsof did reverse-DNS
without -nP.
Add a new "Dev server -> Kill all dev servers" menu option that frees
every dev/test port the scripts use at once: dev app 3000 + Mongo 3001,
Mocha test server 3100 + Mongo 3101, Sandstorm standalone dev 4000 +
Mongo 4001, and rspack 8080. It kills meteor, the rspack watcher and
Meteor's bundled --replSet meteor Mongos, never a production/system
Mongo. Both scripts escalate to SIGKILL if a port does not free up.
Update CHANGELOG and Build-from-source.md docs.
Thanks to xet7 !
Every "Dev server" menu option now stops any Meteor dev server already
listening on its port before starting a fresh one, so re-running a dev
option no longer fails because the port is taken. .sh adds a reusable
kill_meteor_on_port helper called by all six dev options; .bat funnels
them through :runlog, which calls a new :kill_meteor_on_port (netstat +
taskkill). Both wait for the port to free up and escalate to SIGKILL.
Also update the build-from-source docs (README.md, Build-from-source.md,
Build-and-Create-Pull-Request.md, Emoji.md, and the two Sandstorm
developer docs) to the new two-level menu (Setup -> Install dependencies,
Setup -> Build WeKan, Dev server -> localhost:3000), fix a stale
dev-server port (localhost:4000 -> 3000), and fix the README anchor link
to the renamed heading. Add a CHANGELOG entry.
Thanks to xet7 !
Use the Finnish term jyva for Sandstorm grain in the sandstorm-migration
strings: Sandstorm-jyvassa, jyvan hakemistoihin, kayttavat jyvassa, jyvan
levytilan.
Translate the 12 sandstorm-migration-* strings in fi.i18n.json, matching the
existing WeKan Finnish terminology (siirto, Liitetiedostot, Profiilikuvat,
tiedostojärjestelmä, Poista, Tallennustila). The proper noun Sandstorm and the
literal paths/DB names are kept as-is.
Remove the en.i18n.json key sandstorm-migration whose value was the bare
proper noun 'Sandstorm' (the https://sandstorm.org project name), and hardcode
'Sandstorm' in the Admin Panel / Attachments tab label and panel title instead.
The other sandstorm-migration-* keys are real translatable strings and stay.
Replace the long flat menu with a short top-level menu (Setup / Dev server /
Tests / Docker / Tools / Quit); each opens a small submenu with 0) Back, so
only a few items show at once and labels are shorter (category gives context).
Docker becomes a two-stage submenu: pick backend, then Start (up -d) / Follow
logs (logs -f) / Stop (down) -- removing 12 near-identical flat entries.
All action handlers are unchanged; only the front-end dispatch is regrouped:
.sh keeps every case handler and reaches them via a choose() 'short|full' map
(dispatch wrapped in 'for _once in 1'); .bat routes category submenus to the
existing :labels. Verified: .sh bash -n clean + all 23 menu labels map to a
handler; .bat has no orphan gotos.
Expands the docker-compose menu so each backend (MongoDB docker-compose.yml,
FerretDB v1 SQLite, FerretDB v2 PostgreSQL, MongoDB Multitenancy) has three
grouped entries -- Start (up -d), Follow logs (logs -f) and Stop (down) --
instead of just Start. The .sh uses a generalized wekan_docker helper that
auto-detects 'docker compose' vs legacy 'docker-compose'.
New menu entries run 'docker compose -f <file> up -d' for each backend:
MongoDB (docker-compose.yml), FerretDB v1 SQLite, FerretDB v2 PostgreSQL,
and MongoDB Multitenancy. Each prints follow-logs + stop commands. The .sh
auto-detects 'docker compose' vs legacy 'docker-compose'.
The MONGODB_LOG_PATH/TOPOLOGY/SERVER_SELECTION/CONNECTION=debug vars were
temporary mongodb-driver diagnostics that got committed by accident; they
flood wekan-app logs with topology JSON. Remove them from the example compose.
Driver debug logs showed a 2nd, TLS-enabled Mongo monitor connection
retrying every ~0.5s against the plaintext FerretDB port; FerretDB logged
each rejection at WARN. Harmless (WeKan uses the real plaintext connection)
but noisy. Start FerretDB with --log-level=error everywhere it is launched
(Docker entrypoint, snap ferretdb-control, release start-wekan.sh, the
v1-sqlite compose example).
Also remove the dead, unused MongoDB Driver System (server/mongodb-driver-startup.js
and models/lib/{meteorMongoIntegration,mongodbConnectionManager,mongodbDriverManager}.js)
- an abandoned MongoDB 3.0-8.0 auto-detect/driver-select experiment whose
driver packages were never installed. WeKan uses the mongodb-7 driver via Meteor.
gitignore the local FerretDB/ reference clone.
The caddy part fetched Caddy from the Cloudsmith apt repo
(curl dl.cloudsmith.io | gpg --dearmor), which fails on Launchpad remote
builders (restricted network via a fetch proxy): gpg got no key
('no valid OpenPGP data found') and override-build failed with code 2 on
both arches. Download the official prebuilt vanilla Caddy static binary from
GitHub releases instead (per-arch, latest stable + pinned fallback). WeKan
uses only built-in Caddy directives, so no apt repo, gpg, or xcaddy needed.
Applied to both snapcraft.yaml and snapcraft-core24.yaml.
The wekan/FerretDB v1 fork's buildInfo reports a top-level ferretdbVersion
string (e.g. v1.24.2-60-gb5523566) + ferretdbFeatures, and its commit in
gitVersion -- not a ferretdb sub-document. Detection only checked
buildInfo.ferretdb, so the Version page showed Database type: MongoDB and
hid the FerretDB rows. Handle both shapes: top-level ferretdbVersion/
ferretdbFeatures and the ferretdb sub-document. Also confirm in the Sandstorm
doc that FerretDB writes <dir>/wekan.sqlite (+ -shm/-wal).
- start.js: chain niscu (2.x) -> MongoDB 3.0 -> FerretDB; keep niscud + old
bundled driver for the niscu->3.0 stage. Migration from old versions is
permanent (not dropped).
- build-deps.sh (new): assemble a modern meteor-spk.deps on top of upstream
meteor-spk 0.6.0 from dl.sandstorm.io (already has mongod 3.0 + niscud);
swap in Node 24, add FerretDB + Mongo 3.x CLIs + launcher/importer, keep
niscud. Extra binaries from GitHub releases. Nothing needed from projects.7z.
- sandstorm.yml: replace the dead releases.wekan.team/projects.7z download with
build-deps.sh.
- sandstorm-pkgdef.capnp: WRITABLE_PATH -> /var/files.
- docs: keep-niscu + build-source corrections; migration support is permanent.
CJS meteor-spk.deps launcher: on grain start, if old MongoDB 3.0 data exists and
migration is not yet done, start mongod 3.0 (wait for ready), start FerretDB v1
(SQLite), run migrate-mongo3-to-ferretdb (text -> FerretDB, GridFS attachments/
avatars -> /var/files), mark done (old data kept); then run WeKan (Node 24) on
FerretDB steady-state. Paths resolve from __dirname (grain mount root). Update
the design doc to point at the canonical file and mark the in-app panel done.
projects/ (unarchived meteor-spk fork binaries) and sandstorm/ (clone of
sandstorm-io/sandstorm) are large, machine-specific working copies used only
when building the Sandstorm .spk; never commit them.
When isSandstorm, show a new Sandstorm section in Admin Panel / Attachments:
one-time MongoDB 3 -> FerretDB migration status, disk space used by the raw
MongoDB 3 files / FerretDB SQLite / attachments / avatars in the grain, and a
guarded button to delete the redundant raw MongoDB files (only after a
confirmed-successful migration, behind a confirm) to free grain disk space.
- server/methods/sandstormMigration.js: admin-gated sandstormMigrationStatus
+ sandstormDeleteRawMongo (isSandstorm-gated, env-overridable grain paths).
- client Attachments: new Sandstorm tab (jade + js), shown only when isSandstorm.
- imports/i18n/data/en.i18n.json: sandstorm-* UI strings.
- migrate-mongo3-to-ferretdb.mjs: optional STATUS_FILE with the final migration
state, which the panel reads (shared by snap + the Sandstorm spk).
Existing Sandstorm docs live under docs/Platforms/FOSS/Sandstorm/; move the
new Meteor3/Migration.md there (was mistakenly at docs/Platforms/Sandstorm/),
fix its relative links (one level deeper) and the CHANGELOG path.
Add docs/Platforms/Sandstorm/Meteor3/Migration.md: how to build a modern
Sandstorm .spk (Node 24, FerretDB v1 SQLite) migrating an existing grain's
MongoDB 3.0 data on first launch, reusing the snap's migrate-mongo3-to-ferretdb
logic. Includes seccomp compatibility analysis, rewritten start.js, and a new
isSandstorm-only Admin Panel / Attachments / Sandstorm section design.
wekan.help backup/migration instructions hardcoded
/var/snap/wekan/common/files, which is wrong for a parallel snap install
(e.g. wekan_customer -> /var/snap/wekan_customer/common). Print
$SNAP_COMMON/files instead, which snapd sets per instance. Display-only;
all functional snap paths already derive from $SNAP_COMMON/$SNAP_DATA.
The .loadLanguage suite stubbed addResourceBundle on the shared
TAPi18n.i18n singleton and asserted the call count. loadLanguage()
reads this.i18n late and each test re-init()s the singleton, so
cross-test state could leave the stub on a different i18next instance
than the bundle was registered on, making the count read 0 and the run
intermittently report 'expected addResourceBundle to be called once'.
Assert on observable i18next state (hasResourceBundle/getResourceBundle
under the normalised toI18nCode) instead, and stop a leaked
Tracker.autorun in the .getLanguage reactive test.
registerCron() used the synchronous BackupSettings.findOne/upsert, which
Meteor 3 forbids on the server, so cron init threw and scheduled backups
never registered. Use findOneAsync/upsertAsync, make registerCron async,
and await it in all callers. Add tests/backupCron.test.cjs (positive +
negative + source guard) to the test:unit:node suite.
The Meteor/rspack build failed on server/methods/backup.js:
- archiver@8 is now pure ESM with no default export and no archiver('zip', …)
factory — it exports classes. Use `import { ZipArchive } from 'archiver'` and
`new ZipArchive({ zlib: { level: 6 } })` (the streaming API — directory/append/
finalize/pipe/on — is inherited from the Archiver core class).
- The S3 streaming upload requires @aws-sdk/lib-storage, which was not a
dependency (only @aws-sdk/client-s3 was), so rspack failed with
"Can't resolve '@aws-sdk/lib-storage'". Add it, pinned to ~3.1073.0 to match
the installed @aws-sdk/client-s3 (3.1073.0) and avoid the newer lib-storage's
peer requirement on a newer client-s3.
Refresh the Upcoming section: re-point every commit link to the current hash
(the earlier links referenced pre-rebase hashes that are not on GitHub), and add
bullets for the newest commits — Transifex duplicate-key fix, Finnish
translations, unit + negative tests, and the Alternative-Architectures doc.
Document which CPU architectures WeKan can run on and why, the architecture
matrix (Node 24 vs MongoDB vs FerretDB v1), why armhf/armv7l/i386/loong64 are
not supported (Node dropped 32-bit; QEMU/base-image gaps for loong64), the
JavaScript-engine alternatives (Deno/Bun cover fewer arches; QuickJS/JSC/
SpiderMonkey/JVM run on 32-bit but cannot run Meteor), and the server-rewrite
options (Go recommended, QuickJS niche, Tcl/Tk a poor fit for a web app), plus
hardware notes (ODroid-U3, Raspberry Pi OS 32-bit, ReactOS).
Extract the pure, security- and correctness-critical logic of the recent features
into Meteor-free models/lib/* modules (so production and tests share one
implementation) and add plain-Node tests with positive AND negative cases, wired
into test:unit:node:
- models/lib/mongoSelectorSafety.js hasWhere() — the windowed card publication
refuses a client selector carrying $where (server-side JS). Tests: safe
selectors pass; $where at top level / in $and / deep in arrays / in $elemMatch
is rejected. (was inline in server/publications/cardsWindow.js)
- models/lib/cardsLoading.js resolveCardsLoadingMode / parseCardsLoadingEnv /
windowCountId — CARDS_LOADING maps to 'lazy' only for exactly "lazy" (garbage
never enables the experimental mode); a falsy swimlane id collapses to one
count-doc id (listBody uses undefined, listHeader uses ''). (used by
server/cards-loading.js, server/models/settings.js, client/lib/lazyCards.js)
- models/lib/base64Chunk.js encodeAligned/encodeFinal — streaming an attachment
into the JSON export as base64 in any chunk sizes reconstructs exactly the
whole-file base64; aligned pieces never carry padding. (used by
Exporter.buildStream)
- models/lib/backupPaths.js filesRootFrom/scheduleText — WRITABLE_PATH -> files
root (no double /files suffix, Windows-safe) and the synced-cron schedule text
(daily/weekly/monthly + defaults, unknown frequency falls back to daily). (used
by server/methods/backup.js)
41 new assertions across 4 files, all passing; whole test:unit:node suite green.
en.i18n.json had two "database-migration" and two "database-migration-description"
keys, so the Transifex push failed with "Duplicate string key". The later
(block-2) copies — "Database Migration" / "Updating database structure..." — were
unused (only the Admin Panel / Attachments migration UI references these keys, and
it needs the MongoDB<->FerretDB wording in the earlier copy). Removed the unused
duplicates; JSON now parses with unique keys.
In lazy mode minimongo holds only the loaded window, so the list card-counter
badge and the WIP-limit checks (reachedWipLimit / exceededWipLimit, the add-card
gate, and setting the WIP limit to the current count) previously reflected only
the cards loaded so far. They now use lazyListCardCount(), which subscribes to
and reads the server-side count for the SAME selector list.cards(swimlaneId) uses
(listCardsSelector + the board Filter) — so the count is exactly the accurate
value list.cards(swimlaneId).length would report if every card were loaded. The
template's whole-list count uses (cards.length) are routed through a new
cardsCountWhole helper the same way. Default 'all' mode falls back to the loaded
length and is unchanged.
Adds the CARDS_LOADING=all|lazy knob everywhere WeKan is configured:
- docker-compose.yml and the two FerretDB compose files (v1-sqlite, v2-postgresql)
- releases/ferretdb/start-wekan.sh and start-wekan.bat (bundle launchers)
- releases/virtualbox/start-wekan.sh
- snap: added to snap-src/bin/config keys + triplet, so
"snap set wekan cards-loading=lazy" works, with an example in wekan-help.
All default to 'all' (unchanged behaviour).
Client side of CARDS_LOADING=lazy. In lazy mode each list's cardsWithLimit
subscribes to boardCardsWindow for just the cards it renders (growing with the
infinite-scroll limit) and to boardListCardCount for the total; showSpinner uses
that server count to decide whether more cards remain, since minimongo now holds
only the loaded window. Default 'all' mode is unchanged (helpers short-circuit on
isLazyCards()).
Adds Admin Panel / Features — a new admin section (route /admin-features, nav
entry, adminFeatures template) intended as the home for optional / performance /
future tier-gated capabilities. First control: "Card loading" (all | lazy), which
writes the cardsLoading Setting; it mirrors, and is overridden on startup by, the
CARDS_LOADING env var. Includes an experimental-note (counters/WIP limits and the
Calendar/Table/Gantt views reflect only loaded cards; reload boards after change)
and the i18n keys.
Adds an opt-in card-loading mode for very large boards. Default 'all' is
unchanged: the board publication still ships every card into minimongo.
When CARDS_LOADING=lazy (env) or Admin Panel / Features = lazy:
- The board publication no longer ships all cards, their comments/attachments,
or the board-level checklists/checklistItems (gated by a lazyCards() check).
- A new publish-composite 'boardCardsWindow' publishes only the cards of one
list/swimlane window (the client passes the exact selector it renders with,
which is ANDed with a server-forced { boardId, archived:false } scope and
refuses $where), plus each visible card's comments, attachments, checklists
and checklist items. As the user scrolls the client raises the limit and
re-subscribes, streaming more cards in on demand.
- A 'boardListCardCount' publication reactively publishes each window's total
card count into the client-only boardListCardCounts collection, so the client
knows whether more cards remain to load.
The mode is a Settings field (cardsLoading), seeded from the CARDS_LOADING env
var (authoritative on startup when set) and mirrored onto
Meteor.settings.public.cardsLoading for the publications to read; an
after.update hook keeps it in sync when an admin changes it.
The client HTML export cloned the live DOM and built the whole .zip as an
in-memory blob. Two problems on large boards: infinite scroll keeps only ~10
cards per list in the DOM, so most cards were missing from the export; and the
entire archive was buffered in browser RAM.
Before snapshotting, every list's cardlimit is now lifted so the whole board
renders (then we wait for Blaze to flush). The zip is written with JSZip's
generateInternalStream piped straight to the chosen file via the File System
Access API, chunk by chunk with backpressure, so the archive is never held
whole in memory; browsers without the API fall back to the previous blob
download.
The board export routes buffered the entire board in memory before sending:
JSON export built one object with every card, comment, activity, checklist and
base64 attachment; CSV called that same build(); Excel additionally loaded data
it never renders (activities/checklists/subtasks/rules) and did O(n^2)
result.cards.find() lookups. On big boards this peaked at gigabytes and could
exceed V8's max string length.
Now:
- Exporter.buildStream(res) writes the JSON document straight to the response a
document at a time from raw Mongo cursors, encoding each attachment file to
base64 in 3-byte-aligned chunks. Same _format/keys, so import round-trips.
- Exporter.buildCsvStream(res) keeps only the small lookup tables in memory and
streams cards from a cursor, writing one CSV/TSV row at a time.
- ExporterExcel uses the exceljs streaming WorkbookWriter, committing each row
to the response, drops the unused collections, and resolves parent/comment
card titles via an id->title map instead of scanning all cards.
Peak memory stays flat regardless of board size.
Admin Panel / Attachments / Backup no longer loads whole files or the whole
zip into memory. The backup zip is written with archiver, streaming each
attachment/avatar straight from disk (archive.directory) and each text
collection a document at a time from a Mongo cursor as NDJSON, piped directly
to the destination (filesystem or S3/Azure/GCS streaming upload) with no temp
file. Restore reads the zip with unzipper, piping each file entry to disk and
each NDJSON data entry line-by-line in 200-doc batches. A board with thousands
of cards or a 5 GB attachment now backs up/restores with flat memory.
Sandstorm packaging is not tested well enough yet, so it should not run as part of
a full release. Remove the build-sandstorm job from release-all.yml, and add a
separate, manually-triggered sandstorm.yml that ONLY builds the Sandstorm .spk and
uploads it as wekan-sandstorm-YYYY_MM_DD-HH_MM_SS.spk to the newest WeKan GitHub
Release (found via `gh release list`), plus a workflow artifact — so it can be
downloaded and tested for errors without affecting releases. Same experimental
caveats (unprivileged user namespaces, SANDSTORM_KEYRING signing secret).
Thanks to xet7.
Adds a Backup section to Admin Panel / Attachments:
- Checkboxes to select Attachments, Avatars and/or Data (all text-based
collections that are not attachments/avatars).
- Storage dropdown (filesystem, S3/MinIO, Azure, GCS).
- Backup now: the .zip is STREAMED DIRECTLY to the selected storage — no temp
file, no extra disk — as backup/YYYY/MM/DD/HH_MM_SS/backup.zip containing
YYYY_MM_DD-HH_MM_SS/{attachments,avatars,data/<collection>.json}. Filesystem
pipes to the file; S3 uses @aws-sdk/lib-storage streaming Upload, Azure
uploadStream, GCS createWriteStream (cloud creds from the storage tabs).
- Scheduler (off/daily/weekly/monthly + time/day) saved and run via synced-cron.
- List backups: table with storage, datetime, path; select one and Restore with
"Add missing data only" or "Replace all data".
Server methods (admin-only): runBackup, restoreBackup, listBackups,
getBackupSchedule, saveBackupSchedule, backupStatus (polled for live progress).
The cloud upload paths and restore are not exercised end-to-end here; the whole
zip is assembled with jszip, so very large attachment sets use notable memory.
Thanks to xet7.
Adds a "Database migration" section to Admin Panel / Attachments with two buttons:
migrate text-based data (everything except attachments/avatars, which stay on the
filesystem) to FerretDB v1 (SQLite), or back to MongoDB.
WeKan is connected to one database at a time, so the new server methods open a
SECOND driver connection to the OTHER database (both MongoDB and FerretDB v1 speak
the MongoDB wire protocol) and copy the text collections from the live database
into it, upserting by _id (idempotent, re-runnable). The target URL is
WEKAN_FERRETDB_URL (default mongodb://127.0.0.1:27018/wekan) or WEKAN_MONGODB_URL
(default mongodb://127.0.0.1:27019/wekan); both must be running. Progress is polled
via migrateTextDatabaseStatus and shown live. After it finishes, point MONGO_URL at
the other database and restart (on Snap: snap set wekan database=ferretdb / =mongodb).
Admin-only. Attachments/avatars are skipped (they live on the filesystem).
Thanks to xet7.
Per the design: a MongoDB 7 database works with newest WeKan as-is and is NOT
migrated; only the old WeKan 6.09 / MongoDB 3.2 data is migrated to FerretDB v1.
- migration-control now: if mongod 7 can open the existing $SNAP_COMMON data it is
MongoDB 6/7 -> no migration (mark done, keep MongoDB); otherwise it is MongoDB
3.x -> migrate to FerretDB. The dump/restore-into-mongod-7 hop is removed.
- New importer migrate-mongo3-to-ferretdb.mjs reads MongoDB 3.2 with the legacy
mongo CLI (mongoexport — the modern Node driver can't talk to 3.2) and inserts
into a running FerretDB with the Node driver: text data streamed directly, and
CollectionFS/Meteor-Files GridFS attachments+avatars reassembled per-file from
exported chunks straight to files/attachments and files/avatars (no duplicate
copy, no mongodump/mongorestore, no intermediate MongoDB 7). Progress at ROOT_URL.
- FerretDB SQLite now lives at <files>/db, next to attachments/avatars (the
"files/<name>" layout), in ferretdb-control, migration-control, the offline
start-wekan.sh/.bat, the Docker entrypoint and docker-compose-ferretdb-v1-sqlite.
The amd64 6.09/MongoDB-3.2 path is not yet tested against real 6.09 data.
Thanks to xet7.
The bundled Node MongoDB driver cannot connect to a MongoDB 3.2 server, and no
single driver version spans 3.2 and MongoDB 7 / FerretDB. So instead of aliasing
an old (EOL) Node driver into package.json, use the migratemongo CLI tools for the
amd64 6.09/3.2 case: migration-control now dumps the 'wekan' database with the old
migratemongo mongodump (MongoDB 3.2, old libraries), then loads it into a fresh
temporary mongod 7 with the snap's modern mongorestore. The existing driver-based
migrator then reads that mongod 7 exactly like the arm64 MongoDB-7 case (both
GridFS types -> filesystem, text -> FerretDB v1 SQLite). The MongoDB-7 path
(arm64 + amd64-on-newest-WeKan) connects the driver directly, unchanged.
Also fix a real bug: the standalone migrator script in $SNAP/bin could not resolve
its `mongodb`/`bson` imports; set NODE_PATH to the WeKan bundle's node_modules.
Thanks to xet7.
Per docs/Backup/Backup.md and https://github.com/wekan/migratemongo, running the
old MongoDB tools/server in the snap needs LC_ALL=C, the mongo binaries on PATH,
and their libraries on LD_LIBRARY_PATH ($SNAP/lib/<arch>-linux-gnu). The 2016
MongoDB 3.2 binaries additionally need old libraries (libssl/libcrypto.so.1.0.0,
libpng12, libexpat) that modern bases lack.
- Add a migratemongo snapcraft part (both snapcraft.yaml and snapcraft-core24.yaml)
that stages https://github.com/wekan/migratemongo at $SNAP/migratemongo (bin/ =
MongoDB 3.2 binaries, lib/x86_64-linux-gnu/ = the old libraries, avx/ = QEMU
wrappers for non-AVX CPUs), amd64 only. This also fills in the
$SNAP/migratemongo/avx path that mongodb-control / mongodb-backup /
mongodb-restore already referenced but was never bundled.
- Replace the naive fresh-download mongodb-old part (a bare 3.2 mongod with no old
libs) with this.
- migration-control now reads the amd64 6.09 MongoDB 3.2 data with
$SNAP/migratemongo/bin/mongod, LD_LIBRARY_PATH=$SNAP/migratemongo/lib/..., and
the legacy $SNAP/migratemongo/bin/mongo shell (mongosh cannot talk to 3.2). The
MongoDB 7 path (arm64 + amd64-on-newest-WeKan) still uses the snap's mongod 7 +
mongosh.
Thanks to xet7.
On first boot after upgrading an old MongoDB-based WeKan snap, mongodb-control now
hands off to a new migration-control before starting mongod:
- Detects existing MongoDB data in $SNAP_COMMON and opens it with the right
bundled mongod: mongod 7 for MongoDB 7 data (all arches, including the arm64
snaps already on newest WeKan), or a bundled old mongod 3.2 (amd64 only, new
mongodb-old part) for WeKan 6.09 / MongoDB 3.2 data.
- Starts a temporary FerretDB v1 (SQLite) and runs migrate-mongodb-to-ferretdb.mjs,
which migrates text data to FerretDB and BOTH CollectionFS GridFS and
Meteor-Files GridFS attachments+avatars to the filesystem, shows a live progress
counter at ROOT_URL, checkpoints to $SNAP_COMMON (resumable), and compacts the
old MongoDB when done.
- On success switches the snap to database=ferretdb.
Idempotent (migration-pending helper + completion marker), resumable, never
deletes the source MongoDB data, only switches on success. The migrator is bundled
into the snap (/bin). Progress dashboard title fixed to 'MongoDB -> FerretDB'.
NOT yet tested end-to-end against a real 6.09 snap; in particular the 2016 mongod
3.2 binary may need extra runtime libraries on a modern base (amd64 6.09 path).
The arm64/MongoDB-7 path uses the already-bundled mongod 7.
Thanks to xet7.
- docker-compose-ferretdb.yml -> docker-compose-ferretdb-v2-postgresql.yml
(FerretDB 2 + PostgreSQL/DocumentDB, unchanged database).
- Add docker-compose-ferretdb-v1-sqlite.yml: FerretDB v1 with the embedded SQLite
backend, no PostgreSQL/MongoDB. Its ferretdb service fetches the v1 binary for
its architecture from the newest wekan/FerretDB release
(https://github.com/wekan/FerretDB/releases), caches it on the volume, and runs
it with --handler=sqlite.
Both compose files now carry the FULL wekan service from docker-compose.yml
(every documented environment variable and feature); the ONLY differences are
database-related: the ferretdb service replaces the mongodb service, MONGO_URL
points at FerretDB, MONGO_OPLOG_URL is dropped and METEOR_REACTIVITY_ORDER is
polling (FerretDB has no MongoDB change streams / replica-set oplog).
Thanks to xet7.
When upgrading from an old WeKan snap, $SNAP_COMMON/Caddyfile may still be in
Caddy v1 format, which Caddy 2 cannot parse (so caddy would fail to start).
caddy-control now runs migrate-caddyfile-v1-to-v2.sh before 'caddy run' when
caddy is enabled. It is safe: a no-op if the file already parses as Caddy 2;
otherwise it backs up the original, converts the common v1 directives (drop the
http:// scheme, 'proxy / TARGET' -> 'reverse_proxy TARGET', drop the v1
'websocket'/'transparent' presets that Caddy 2 does by default, 'gzip' ->
'encode gzip'), validates the result with 'caddy adapt', and only keeps it if
valid — falling back to the shipped Caddy 2 template otherwise, so caddy always
starts with valid config.
Thanks to xet7.
Two additions to the MongoDB -> FerretDB / GridFS -> filesystem migrator used by
the Snap and Sandstorm migrations:
- Resumable: progress is checkpointed to $WRITABLE_PATH/migration-progress.json
(atomic write) after every collection and file phase. On restart the migrator
loads the checkpoint and SKIPS collections it already finished, so an
interrupted migration (snap refresh, Sandstorm grain restart, power loss)
continues instead of starting over. Safe because every document is upserted.
- Compact after success: once the migration is complete (fresh run, or a later
boot that finds the completion marker), it runs 'compact' on each source
MongoDB collection so WiredTiger returns the now-duplicated disk space to the
OS. Runs once (tracked by a 'compacted' flag on the marker) and is best-effort.
The existing ROOT_URL progress dashboard and disk-space checks (statfsSync) are
kept; the dashboard is restored from the checkpoint on resume.
Thanks to xet7.
Mirrors releases/release-sandstorm.sh + releases/install-sandstorm.sh: installs
Meteor, meteor-spk 0.6.0 (from the WeKan projects.7z) and a dev Sandstorm, then
'meteor-spk pack' produces wekan-<version>.spk and attaches it to the GitHub
Release. Decoupled from the release job so it never blocks the core release.
EXPERIMENTAL in CI: Sandstorm needs unprivileged user namespaces (GitHub's Ubuntu
VMs allow them), and meteor-spk signs the .spk with the app private key from the
Sandstorm keyring -> provide it as the SANDSTORM_KEYRING secret. 'spk publish' to
the app market and the scp upload stay manual, as in release-sandstorm.sh.
Thanks to xet7.
Each wekan-<version>-<arch>.zip is now fully offline: its bundle/ directory
contains the WeKan server, a Node.js binary for that platform, a FerretDB v1
(SQLite) binary, and a start-wekan.sh (start-wekan.bat on Windows) that by
default runs WeKan on the bundled Node against the bundled FerretDB SQLite,
storing data and attachments/avatars on the filesystem under WRITABLE_PATH
(like docs/Platforms/Propietary/Windows/Offline.md). Override with WEKAN_DB /
MONGO_URL to use an external database.
- build-amd64/arm64/mac copy the runner's own Node 24 (matching arch); the
emulated ppc64le/s390x/riscv64 builds copy the target-arch Node they already
download; win64 bundles node.exe. Each overwrites the base bundle's node.
- start-wekan.sh supersedes start-wekan-ferretdb.sh (removed).
- Docker and snap have their own Node + entrypoint/wekan-control, so they strip
the redundant bundled node + launchers (keeping the ferretdb binary), saving
~80 MB per image/snap.
Thanks to xet7.
The main snapcraft.yaml uses base core26, which needs build-base devel + grade
devel until core26 is released, so it can only go to Snap Beta/Edge. This adds a
base core24 variant (a released base, grade stable) that builds the SAME newest
WeKan (Meteor 3.5, Node.js 24, FerretDB v1, MongoDB 7, Caddy 2), so the Stable
channel can be updated from the old 6.09 snap. Only base/build-base/grade differ
from snapcraft.yaml; migration wiring is added separately.
Thanks to xet7.
FerretDB is now built and released separately in the wekan/FerretDB repo (its
build.sh cross-compiles every platform into ferretdb.zip and attaches it to a
release there). The WeKan release workflow no longer sets up Go or compiles
FerretDB: build-ferretdb just downloads the newest ferretdb.zip from
https://github.com/wekan/FerretDB/releases/latest and republishes it as a
workflow artifact, and every WeKan build embeds its per-arch binary from that.
ferretdb.zip is no longer attached to the WeKan releases, since it already lives
on the wekan/FerretDB releases.
Thanks to xet7.
Under a sub-path deployment (ROOT_URL like https://host/wekan, typically behind a
reverse proxy that strips the prefix), language selection and other lazy-loaded
features failed with:
Error serving static file ENOENT ... /programs/server/build-chunks/build-chunks/<id>.js
rspack's client runtime builds each chunk URL as __webpack_public_path__ + chunkName,
and chunkName already includes the 'build-chunks/' prefix (u = e => 'build-chunks/'+e+...).
The default public path is '/', so at the site root chunks resolve correctly to
/build-chunks/<chunk>. But client/00-startup.js set the sub-path public path to
_rootPath + '/build-chunks/', so rspack appended a second 'build-chunks/', yielding
/wekan/build-chunks/build-chunks/<chunk> — which 404s. Set the public path to
_rootPath + '/' and let rspack add 'build-chunks/' itself.
Thanks to xet7.
Adds a build-ferretdb job that cross-compiles FerretDB v1 (wekan/FerretDB, pure-Go
SQLite backend, CGO off, no QEMU) for every platform Go + modernc.org/sqlite
support — not only the arches Node.js runs on — and packs them into ferretdb.zip:
ferretdb/<arch>/ferretdb-<arch> (Linux/macOS/BSD, executable)
ferretdb/<arch>/ferretdb-<arch>.exe (Windows only)
ferretdb/README.md (links to https://github.com/wekan/FerretDB)
Targets that do not compile on a given platform are skipped, so the zip contains
exactly what builds. ferretdb.zip is attached to the GitHub Release, and every
WeKan build (amd64, arm64, ppc64le, s390x, riscv64, win64, mac-arm64; and via the
bundle the docker image and snap) now extracts its FerretDB binary from that same
ferretdb.zip, so there is one source of truth. Windows/macOS bundles now include
FerretDB too (previously stripped), tolerant of an arch that FerretDB can't build.
Thanks to xet7.
getStatistics now reports, in Admin Panel / Version:
- Database type: MongoDB or FerretDB (detected from buildInfo.ferretdb).
- MongoDB-compatible version and the server git commit (buildInfo.gitVersion).
- FerretDB version and commit, when the server is FerretDB.
- Storage engine: WiredTiger for MongoDB, SQLite for FerretDB.
- Reactivity mode currently in use: changeStreams / oplog / polling (from
Meteor's oplog handle; FerretDB has no oplog so it shows polling).
Thanks to xet7.
Adds a 'database' snap setting (mongodb|ferretdb). A new ferretdb service runs
FerretDB v1 (SQLite) on the same port MongoDB would use; only one database runs
at a time. The configure hook flips the two services when the setting changes,
mongodb-control disables itself when ferretdb is selected, and wekan-control
drops MONGO_OPLOG_URL for FerretDB (which has no replica-set oplog, so WeKan
uses polling) and waits on a plain ping instead of rs.status().
The FerretDB binary ships inside the WeKan bundle the wekan part already
downloads, so no extra build is needed. New installs default to FerretDB on all
platforms via the install hook (fresh installs only; upgrades keep MongoDB, and
a pre-existing MongoDB data dir is detected and kept). Switch with
'snap set wekan database=mongodb'.
mongosh collects anonymized usage analytics by default and the snap invokes it
several times; disable it (writable HOME + disableTelemetry) so nothing phones
home. mongod itself has no phone-home telemetry (Free Monitoring is opt-in).
Thanks to xet7.
The extra-arch bundle build ran node:24-slim under QEMU, but the official
node:24 image publishes no linux/s390x manifest (only amd64/arm64/ppc64le),
so the s390x leg failed with 'no matching manifest for linux/s390x'. Build
the emulated native-module rebuild on an ubuntu:26.04 base (which publishes
every arch) and install the Node.js binary from nodejs.org instead; riscv64
uses unofficial-builds.nodejs.org (nodejs.org ships no riscv64).
MongoDB Community only ships amd64/arm64 server binaries, so on ppc64le,
s390x and riscv64 WeKan now bundles FerretDB v1 (the wekan/FerretDB fork with
its embedded pure-Go SQLite backend, MongoDB wire protocol). The FerretDB
binary is cross-compiled once for all five arches (CGO off, static, no QEMU)
and embedded in every .zip next to main.js, so amd64/arm64 users can opt in
too via WEKAN_DB=ferretdb. The Docker image now covers all five arches and
auto-starts FerretDB on the MongoDB-less ones. FerretDB telemetry is disabled
and locked (--telemetry=disable, plus DO_NOT_TRACK). armv7l is still excluded:
no Node.js 24 build exists for it anywhere.
Thanks to xet7.
The swimlanes CRUD e2e test (23-rest-api-more.e2e.js:209) regressed on all
browsers. Root cause: on the server ReactiveCache.getSwimlanes is async, so
board.swimlanes() returns a Promise in the REST handler. The #3624 change read
board.swimlanes().map(s => s.sort); .map on a Promise throws, the insert never
ran, the error was swallowed by the handler's catch (returned as 200 with no
_id), and the test read .title off a null swimlane.
The earlier "move the require to a top-level import" commit was not the real
cause (the same module.exports import pattern works server-side, e.g.
ruleDeletePermission in rulesButton.js). The actual fix is to await
board.swimlanes() before mapping. This also means API-created swimlanes now get
a real max(existing sort)+1 sort — previously the un-awaited `.length` yielded
undefined, so they were stored with no sort at all, which is the #3624 symptom.
Verified: the swimlane test passed in every kept local run through
2026-07-09_02-38-07 and failed starting 09-52-25 (right after the #3624 change),
confirming the regression window; the tests/swimlaneSort.test.cjs unit test
still passes.
Two e2e tests failed across Chromium/Firefox/WebKit after this release's changes:
- 23-rest-api-more.e2e.js:209 (swimlanes: create, get, edit, delete): the
#3624 change referenced models/lib/swimlaneSort via a function-scoped
require('/models/lib/swimlaneSort'); the new module was not reliably bundled/
resolved that way, so POST /api/boards/:id/swimlanes threw, was caught, and
returned an error object with no _id — the test then read title off a null
swimlane. Import nextSwimlaneSort at the module top level, matching every
other import in server/models/swimlanes.js, so it is statically bundled.
- 02-cards-open-view.e2e.js:93 (editing the card title does not break the card):
#4236 intentionally made plain Enter insert a newline in the card title
(consistent with the description), with Ctrl/Cmd+Enter saving. The CardPage
page object still saved with plain Enter, so the title never persisted and the
read timed out. Save with Control+Enter (sends ctrlKey on every platform,
which the save handler accepts).
Server-side Mocha, import regression, and Node E2E jobs already passed; this
makes the Playwright jobs green too.
In an RTL language (e.g. Arabic) the board root is dir="rtl". Both the minicard
title (a dir="auto" .viewer) and the add-card composer textarea are dir="auto"
but had no bidirectional isolation, so they shared the surrounding bidi context.
Typing a strong RTL character into one list's composer re-resolved that shared
context and visibly reflowed the displayed minicard titles of the other lists
(no underlying data change — it reverted on refresh).
Each minicard title and the composer textarea now use `unicode-bidi: isolate`,
making them self-contained bidirectional runs that cannot perturb one another.
The isolation is locked in (positive + negative) by tests/minicardBidiIsolation.test.cjs;
full browser RTL behavior is covered by tests/playwright/specs/18-rtl-layout.e2e.js.
Thanks to xet7.
List bodies used overflow-y:auto, so on platforms/browsers with overlay
scrollbars (macOS, iOS, Android, Firefox) the scrollbar auto-hid when idle and
there was no persistent affordance that a list is scrollable.
The list body now shows a scrollbar across all engines: overflow-y:scroll to
always reserve and show the track, ::-webkit-scrollbar width + thumb/track for
Chrome/Safari/Edge and mobile WebKit/Blink, scrollbar-width + scrollbar-color
for Firefox/Gecko (desktop and Android), and scrollbar-gutter:stable so content
does not shift. The cross-browser rules come from a Meteor-free builder
models/lib/scrollbarCss.js and are applied in client/components/lists/list.css;
both the builder contract and the applied CSS are unit tested (positive +
negative, including that no hide values sneak back in) in
tests/scrollbarCss.test.cjs.
Thanks to xet7.
When a card was copied — including generating a card from a template — each
subtask was inserted as a bare card document. The parent card's checklists were
copied, but the subtasks' checklists (and their items) were never copied, so
the new card's subtasks came out empty.
Card.copy() now copies each subtask's checklists (via Checklist.copy, which also
copies the checklist items) onto the newly inserted subtask. The subtask copy
document is built by a Meteor-free helper models/lib/subtaskCopy.js
(buildCopiedSubtaskFields — re-homes the subtask under the new parent and onto
the destination board; subtaskCopyChildKinds declares 'checklists' must be
reproduced), unit tested (positive + negative) in tests/subtaskCopy.test.cjs.
Thanks to ramses345 and xet7.
POST /api/boards/:boardId/swimlanes set the new swimlane's sort to
board.swimlanes().length (a count). When the existing swimlanes' sort values
were not a contiguous 0..n-1 run (after deletions/reordering, or swimlanes
created top-first with decreasing sorts), the count collided with or preceded
existing sorts and the new swimlane appeared FIRST instead of last.
The endpoint now computes the sort with nextSwimlaneSort(): max(existing sort)+1
for a reliable append (0 on an empty board), and honors an optional explicit
`sort` in the request body (the enhancement the reporter asked for). The pure
logic lives in models/lib/swimlaneSort.js, unit tested (positive + negative) in
tests/swimlaneSort.test.cjs.
Thanks to tamasberesoebb and xet7.
The activity feed rendered "edited comment undefined" / "deleted comment
undefined" for comment edits and deletions. The template passed the comment's
ID into the "%s" of activity-editComment / activity-deleteComment: on older
activities the id was absent (literally "undefined"), and a deleted comment's
CardComment document is already removed so it cannot be looked up live either.
The edit and delete activities now store the comment text (commentText), and a
new Activities.commentDisplayText() helper picks the stored text, else the live
comment text (edit case), else an empty string — so the feed never renders the
word "undefined". The template shows the (sanitized) comment text. The
text-selection logic is a Meteor-free helper models/lib/commentActivity.js,
unit tested (positive + negative) in tests/commentActivity.test.cjs.
Thanks to janchuelo and xet7.
Renaming a linked card (or linked-board card) wrote the new title only to the
linked target (via getRealId()/linkedId), leaving the linking card's OWN title
field stale. Filter-by-title queries each card document's own title field, so a
linked card silently dropped out of title filters after being renamed.
Card.setTitle() now also writes the linking card's own title (in addition to the
linked target), keeping it filterable while preserving the existing mirror
behavior. The set of documents to update is a Meteor-free helper
models/lib/linkedCardTitle.js (computeTitleUpdateTargets), unit tested
(positive + negative) in tests/linkedCardTitle.test.cjs.
Thanks to Ben0it-T and xet7.
Creating a board from a template copies the template board. The copy inherited
the template's subtasksDefaultBoardId / dateSettingsDefaultBoardId verbatim.
When those pointed at the template board itself, subtasks created on the NEW
board were dropped onto the TEMPLATE board, and the subtask card linked back
across boards to the parent.
Board.copy() now repoints any subtasks/date-settings default that referenced
the source board to the new copy, and clears the paired list id so it self-heals
to a list on the new board. Defaults that deliberately point at another (shared)
board are left untouched. The remap logic is a Meteor-free helper
models/lib/boardCopyDefaults.js, unit tested (positive + negative) in
tests/boardCopyDefaults.test.cjs.
Thanks to Xilef11 and xet7.
Security: with "Self Registration" and "Forgot Password" disabled in the Admin
Panel, the Register (.at-signup-link) and Forgot Password (.at-pwd-link) links
were hidden only by a one-shot jQuery .hide() in userFormsLayout.onRendered.
When a login failed (notably the LDAP "User not Found" path), useraccounts
re-rendered the form and recreated those link nodes without the inline
display:none, so the links reappeared and exposed registration / password-reset
flows that were meant to be off.
The disable state is now also reflected as a class on the stable <body>
ancestor (registration-disabled / forgotpwd-disabled) with matching CSS in
userForm.css. Because the class sits on <body>, the rule re-hides every copy of
the links that useraccounts recreates after a failed login, instead of relying
on a single inline style that the re-render dropped.
Thanks to Alsterdetektive1 and xet7.
#4055 reported the calendar/date-badge week number was one week too high
(Mon-Sat) and two too high (Sunday) for 2021-10-25..31 (ISO week 43). That was
the old moment-based calculation. The current native, DST-safe
dateUtils.getISOWeek() computes these correctly (verified across a DST timezone).
Adds tests/isoWeek.test.cjs pinning the exact reported dates so the off-by-one/
two cannot silently return.
Thanks to marcungeschikts and xet7.
The card title textarea submitted on plain Enter (only Shift+Enter made a new
line), while the card description textarea and the shared inlinedForm insert a
new line on plain Enter and only save on Ctrl/Cmd+Enter. So Enter could not add
a new line in the title, an inconsistent experience.
The title keydown handler now uses a shared, Meteor-free rule isSubmitKey()
(models/lib/editorSubmitKey.js): submit ONLY on Enter together with Ctrl or Cmd;
plain Enter and Shift+Enter fall through to the textarea default (a new line).
This matches the description field exactly. Unit tested (positive + negative) in
tests/editorSubmitKey.test.cjs.
Thanks to listenerri and xet7.
With LDAP_UTF8_NAMES_SLUGIFY enabled, sync.js slugified the username with
limax(text, { separator: '.' }) to transliterate UTF-8 names. limax replaces
every run of non-alphanumeric characters — including hyphens — with the
separator, so an LDAP username like "p.parta-partb" was turned into
"p.parta.partb". The generated Wekan username no longer matched and the user
could not log in.
slug() now slugifies each hyphen-separated segment on its own and rejoins
them with '-', so hyphens (and existing dots) survive while UTF-8 characters
in each segment are still transliterated. The hyphen-preserving logic is a
Meteor/limax-free helper packages/wekan-ldap/server/usernameSlug.js
(slugifyPreservingHyphens, with the transliterate function injected), unit
tested (positive + negative) in tests/ldapUsernameSlug.test.cjs.
Thanks to RowhamD and xet7.
In the board Calendar view the week-number column was numbered from Sunday
regardless of the user's "start day of week" setting: setting Monday moved
the grid (via firstDay) but the week numbers still referred to Sunday-start
weeks. FullCalendar's default weekNumberCalculation is locale-based, so it
ignored firstDay.
The calendar now passes weekNumberCalculation that computes the number with
weekNumberByFirstDay(date, firstDay) from the same firstDay used to lay out
the grid, so the number matches the displayed week. The Meteor-free week math
lives in models/lib/weekStart.js and is unit tested (positive + negative,
including a case where Monday-start and Sunday-start must differ) in
tests/weekStart.test.cjs.
Thanks to helioguardabaxo and xet7.
The "Due this week" date filter selected the wrong week (it showed next
week's cards) and ignored the user's configured start day of week.
Root cause: relativeWeek() derived its window from startOf(now(), 'week'),
but the native dateUtils.startOf() has no 'week' case, so it returned the
date unchanged. The window therefore started at "today + startDayOfWeek"
(next week) instead of the beginning of the current week, and never took the
configured start weekday into account.
Fix:
- New Meteor-free helper models/lib/weekStart.js computes startOfWeek(),
weekRange() and weekNumberByFirstDay() for an arbitrary start day of week
(0=Sunday..6=Saturday, default Monday). Unit tested (positive + negative)
in tests/weekStart.test.cjs, including a guard that "this week" must
contain today.
- client/lib/filter.js relativeWeek() now uses weekRange(now(), weekStartDay,
0|1) so "this week" and "next week" are the correct, non-overlapping
Monday..Sunday (or configured) windows.
- The this/next-week buttons now toggle per week: clicking the active one
clears it, clicking the other switches to it (the old code reset on either
state, so you could not switch directly from this week to next week).
Thanks to mimZD and xet7.
Switching directly from one board to another using the favorites bar reused
the same boardBody template instance (currentBoard went A -> B, never null),
so boardBody.onRendered never fired again and the one-shot
Utils.setBackgroundImage() call never re-ran. The previous board's inline
background:url(...) on .board-wrapper stayed on screen. Switching via the
"all boards" list worked only because it destroys and re-creates boardBody.
Two-part fix:
- boardBody.onRendered now calls Utils.setBackgroundImage() inside a reactive
this.autorun(), so it recomputes on every board switch (and background edit).
It performs no DB writes, so there is no autorun write loop.
- setBackgroundImage() now clears any stale inline background when the new
board has no image, instead of only ever setting one. The decision is a
Meteor-free helper models/lib/boardBackground.js (computeBoardBackground),
unit tested (positive + negative) in tests/boardBackground.test.cjs. Board
color keeps being applied reactively via the .board-wrapper colorClass.
Thanks to dasarne and xet7.
The rules move-card-to-top/bottom (on another board) and link-card-to-another-board
actions failed in two ways for boards the rule creator did not own:
- The action showed BLANK after creating the rule: the wizard inserted the
trigger/action/rule with three optimistic client Collection.insert() calls
that landed in minimongo limbo once the wizard subscription stopped (and the
client allow/deny rules rejected them outright for non-owner members). These
now create the rule through the server rules.createRule method, which keeps
the action's own destination boardId.
- Execution crashed with a generic Internal Server Error: the destination
swimlane fallback dereferenced ._id on a possibly-undefined swimlane titled
exactly Default, which does not exist when the destination board's default
swimlane was renamed, translated, or the board had no such swimlane.
Resolution now uses the board's real default swimlane and a Meteor-free
resolver (models/lib/ruleActionResolve.js) that returns empty string instead
of throwing. The same guard is applied to the createCard and linkCard actions.
Unit tested (positive + negative) in tests/ruleActionResolve.test.cjs.
Thanks to DarthKillian and xet7.
Translate the strings that were still in English (mostly keys added this
release: the Rules Workflow trigger/action palette, the relative-date
unit selector, the custom color-wheel label, the Activities hide toggle
and the changed-description activity), using the terminology already used
in the existing Finnish translations.
The Organization setting "Automatically add users with the domain name"
(org.orgAutoAddUsersWithDomainName) was never read at sign-up, so a user whose
email domain matched an organization was never added to it.
Add a pure helper models/lib/orgAutoAddByDomain.js (orgsToAutoAddForEmail) that
returns the ids of orgs whose configured domain exactly matches an email domain
(case-insensitive, exact — no subdomain, empty domain matches nothing), and wire
it into Accounts.onCreateUser so every non-admin sign-up path (password, LDAP,
invitation, new OIDC user) gains the matching org memberships using the same
{ orgId, orgDisplayName } shape used elsewhere, without duplicating existing
memberships. Add tests/orgAutoAddByDomain.test.cjs.
Replace the counterintuitive unlabeled material toggle switch on the card
details Activities panel with an eye / eye-slash icon toggle: open eye means
activities are shown, crossed eye means they are hidden. Clicking flips the
state, the icon reflects the current visibility, and the tooltip states the
action (Show activities / Hide activities). The same eye pattern from the
login/register password-visibility toggle is reused for consistency.
For consistency the board sidebar Activities toggle (same showActivities
state) is switched from the check / empty-square icon to the same eye /
eye-slash icon toggle.
The "Link to this card" popup Cards pull-down previously listed cards in
board sort order, making a card hard to find on boards with many cards.
Sort it alphabetically by title (case-insensitive, locale/numeric aware)
via a small pure helper sortCardsByTitle, with unit tests. Thanks to xet7.
The REST endpoint PUT /api/boards/:boardId/lists/:listId already accepted
title, color, starred and wipLimit, but the color was stored unvalidated. It
now validates the color with normalizeListColor (a named palette color OR a
custom #rrggbb hex) and rejects an unknown color with a clear 400 instead of
silently storing None or hanging. The pure field/validation logic is extracted
to a Meteor-free helper models/lib/listApiUpdate.js so it is unit testable
without a running server (tests/listApiUpdate.test.cjs).
api.py gains two commands mirroring editcard/editcardcolor:
editlist BOARDID LISTID NEWLISTTITLE and
editlistcolor BOARDID LISTID COLOR, with usage lines in the help block.
Thanks to C0rn3j and xet7.
Labels are embedded in the board document, not a separate collection, but the
Activities label() helper looked the label id up in the Cards collection and
always returned undefined. So the addedLabel/removedLabel webhook and
notification params never got a label value and the __label__ token in the
message text rendered as a bare, generic "label" with no name.
Resolve the label from the already-loaded board via getLabelById, and add a
pure labelDisplayName() helper (name -> color -> id fallback) so a nameless
label is shown by its color, matching the UI. Add a plain-Node unit test.
Card description changes did not create an activity, so no outgoing webhook
fired (unlike title/dueAt changes, whose Cards before.update hooks log an
activity). Log an a-changedDescription activity in the Cards before.update hook,
mirroring the title-change activity, so the existing Activities.after.insert
webhook hook fires. Fires on first-time set and later edits, not on no-op /
empty->empty saves. Pure descriptionChanged helper + tests, English i18n and
activity rendering.
The workflow trigger/action palette rendered hardcoded English labels
regardless of the UI language. Palette entries now carry an i18n labelKey
translated at render time via TAPi18n.__, reusing existing rule keys where
they fit and adding new r-w-* keys for workflow-only labels. Also routed
the slot clear tooltip through the existing r-remove key.
Deleting a rule ran three separate client-side Collection.remove() calls
(Rules + Triggers + Actions). Each is gated by a per-collection allow() rule
that resolves the board from that document own boardId via
Boards.findOneAsync(doc.boardId). When a trigger/action document has no
resolvable boardId (legacy rules created before boardId was denormalised, or
docs not published to the client), the board resolves to null and
allowIsBoardAdmin returns false, so Meteor rejects the mutation with 403
"Access denied" and the delete fails even for a legitimate board admin.
Route rule deletion through a new server Meteor method rules.deleteRule, which
authorizes ONCE (active board admin or site admin) and removes the rule, its
trigger and its action server-side (bypassing the brittle client allow/deny).
The permission decision is extracted into the Meteor-free helper
models/lib/ruleDeletePermission.js and covered by
tests/ruleDeletePermission.test.cjs. No permission is loosened: only board
admins and site admins may delete, matching the board-admin gate used to
create a rule.
Add a native color wheel (<input type="color">) alongside the existing fixed
named-color swatches in the color pickers for card labels, swimlanes, lists and
cards, so any #rrggbb color can be chosen. The schema color fields accept a
custom hex in addition to the named palette (via a validation that allows the
named values or a ^#[0-9a-fA-F]{6}$ hex), and normalizeListColor now passes hex
through, so existing named-color data keeps working. When a stored value is a
hex, elements apply an inline background-color instead of the card-details- /
swimlane- / list-header- / minicard- CSS class.
A new pure, Meteor-free helper models/lib/contrastColor.js computes a readable
text color from sRGB relative luminance (white on dark, black on light),
maps the named palette to hex, and validates/normalizes hex; it is applied as
an inline text color wherever a chosen color is a background behind text (label
chips, swimlane/list headers, minicard, card details header). Covered by
tests/contrastColor.test.cjs (20 assertions).
PUT /api/boards/:boardId/labels only wrote an HTTP response inside
`if (hasOwnProperty(req.body, "label"))` and read req.body.label.color/.name
unconditionally. Two consequences:
- A body without a `label` key fell through the `if` and NEVER sent a response,
so the request hung until the client timed out (the reported "timeout").
- A body where `label` was a bare string (e.g. { "label": "labelName" }, the
exact reported payload) produced name === undefined / color === undefined and
pushed a schema-invalid label via Boards.direct, returning 200 for garbage.
- The catch returned { code: 200, data: error }, masking real failures as
success (same anti-pattern already fixed for the board create/delete handlers).
The handler now returns a 404 for an unknown board, delegates input handling to
a new pure, Meteor-free helper models/lib/restLabel.js (buildBoardLabel), and
always sends a JSON response: 2xx for a well-formed create (documented contract
unchanged), 400 with a clear message for bad input, or the real error status in
the catch. buildBoardLabel accepts { label: { name, color } } (color defaulted
when absent, rejected when unknown) and, for convenience, a bare string taken as
the label name. Added tests/restLabel.test.cjs covering these cases.
Exporter.buildCsv resolved each card list/swimlane/owner/member/assignee/label/
customField by id and read a property directly on the result of Array.find(),
which is undefined when the referenced document was deleted. Large/old boards
often contain such dangling references, so the read threw "Cannot read property
title of undefined" and crashed the whole CSV export request. Extracted the
per-card row builder into a pure, null-safe helper models/lib/exporterCsvRow.js
(unit-testable without Meteor) that emits a blank cell for a missing reference
while keeping identical output for well-formed cards. Added
tests/exporterCsvRow.test.cjs.
The Calendar view queried cards with only a board+date selector via
Board.cardsInInterval()/cardsDueInBetween() and ignored the active board
Filter (member / assignee / due-date / label / custom-field), so it showed
every card in the interval regardless of the sidebar filter, unlike the
Board / Lists / Swimlanes views.
Extract the calendar selector building into a pure, Meteor-free helper
(models/lib/calendarFilter.js) that ANDs the Filter selector into the
date-interval selector via combineWithFilter, so the Filter is always applied
and can never collide with the interval selectors top-level $or. The calendar
events() callback now passes Filter._getMongoSelector() when Filter.isActive(),
and the onRendered autorun reads Filter.isActive() so events are refetched when
the filter changes. Add tests/calendarFilter.test.cjs.
Thanks to kerier and xet7.
Follow-up to #6439, which restored the drag preview but left the drop a
no-op: dragging a board on the All Boards page in "Custom (drag order)"
mode showed the dashed-border preview, but releasing it snapped the board
back without reordering.
The drop handler built the current on-screen order from
`el.classList[0]` for each `.js-board`. But the board list item is
`li.js-board(class="{{_id}} …")`, and Jade emits the literal `js-board`
class FIRST, so classList[0] is the string "js-board" for every board —
never the board _id. The ordered ids were therefore
['js-board','js-board',…]; computeReorderedSortIndex could not find the
dragged/target ids in that array, returned null, and nothing was written
to profile.boardSortIndex. The preview still worked because it is driven
by the dragover CSS class, independent of the id.
Read each board's _id from its Blaze data context (the same source
dragstart already uses via `this._id`) instead of the literal class, so
the real display order reaches the (already correct, unit-tested) reorder
helper and the drop persists. Add a regression guard in
tests/boardSortReorder.test.cjs asserting the wrong-class extraction
("js-board" repeated) yields no mapping while real ids reorder.
On old boards a swimlane can be deleted while its cards keep the now
dangling swimlaneId (an "orphaned" card). Cards with no swimlane at all
(null / '' / missing) already surface in every swimlane, but an orphaned
card matched no existing swimlane and so appeared in NO swimlane in
swimlane view, while still showing in list view (which applies no
swimlane scope) — the reported "no swimlane" symptom where some boards
show no cards in swimlane mode but work in list mode.
Mirror the existing orphaned-LIST fallback (Swimlanes.orphanedSwimlaneLists,
which surfaces orphaned lists in the first swimlane) for cards: when a
list's cards are fetched for the board's FIRST swimlane, build the
swimlane-membership clause as a single { swimlaneId: { $nin:
<otherSwimlaneIds> } } (everything not owned by another existing
swimlane: own id, null/'', missing, or orphaned). This keeps it a single
field clause with no second $or, so the #6441 board-wide label filter
still holds. Orphaned cards therefore appear once, in the first swimlane,
without a database migration.
Threaded through the pure selector helpers (swimlaneMembershipSelector /
listCardsSelector / filteredListCardsSelector) and the in-memory sibling
filterCardsByListAndSwimlane, a new List.orphanedCardsSwimlaneIds helper,
and the cards()/cardsUnfiltered()/allCards() model methods plus the
listBody cardsWithLimit render helper. Covered by new cases in
tests/swimlaneFilter.test.cjs (18 assertions pass; #6441 guards intact).
# An AppImage that packs is not an AppImage that runs. Start it, wait
# for WeKan to answer on its port, then stop it - so a broken bundle
# is caught here rather than by whoever downloads it.
export WRITABLE_PATH="$PWD/smoke-data" PORT=8080
# A CHECK THAT CANNOT RUN IS NOT A FAILED CHECK. The 32-bit builds are
# packed on a 64-bit runner, which executes them only if the kernel and
# loader for that word size are present - GitHub promises neither. If
# the binary cannot be executed AT ALL, the AppImage is as good as
# anything here knows and the release must not be withheld for it; say
# so and move on. Anything else - it starts and does not answer - is
# the bug this step exists for and still fails.
if ! APPIMAGE_EXTRACT_AND_RUN=1 "$app" --appimage-help >/dev/null 2>&1 \
&& ! APPIMAGE_EXTRACT_AND_RUN=1 "$app" --help >/dev/null 2>&1; then
if ! file "$app" | grep -q "$(uname -m)"; then
echo "::warning::this runner cannot execute a ${{ matrix.appimage_arch }} binary, so the AppImage was packed but not started. It is uploaded unchecked."
echo "::notice::No base bundle (wekan-${{ needs.release.outputs.version }}-{amd64,arm64}.zip) is on ${{ needs.release.outputs.tag }} yet, so there is nothing to wrap - skipping. release-all.yml builds the AppImages once the base bundles are published."
exit 0
fi
echo "::error::A base bundle is published but no architecture produced an AppImage - every build job failed. Their logs say why; nothing is uploaded."
exit 1
fi
- name:Upload them
env:
GH_TOKEN:${{ github.token }}
run:|
set -euo pipefail
if ! ls assets/*.AppImage >/dev/null 2>&1; then
echo "Nothing to upload (no base bundle was published to wrap)."
exit 0
fi
# --repo, because this job does NOT check the repository out - it only
# downloads artifacts - so `gh` has no git remote to infer the repo
# from and fails with "fatal: not a git repository". Every other gh
# call in this workflow already passes it; these two did not, so the
# AppImages were built, smoke-tested and uploaded as artifacts, and
description:'Docker Hub repository under wekanteam/ to publish'
required:true
default:'wekan-gantt-gpl'
type:choice
options:
- wekan-gantt-gpl
- wekan-ondra
version:
description:'WeKan version to publish, without the v (e.g. 10.49). Empty = newest GitHub release.'
required:false
default:''
type:string
also_latest:
description:'Also move the :latest tag of the variant image'
required:false
default:true
type:boolean
permissions:
contents:read
jobs:
retag:
runs-on:ubuntu-latest
steps:
# First step on purpose: a missing or wrong credential is then ONE named
# line at the top of the log, not a failure deep inside a push.
- name:Check DOCKERHUB_AUTH is configured and works
env:
DOCKERHUB_AUTH:${{ secrets.DOCKERHUB_AUTH }}
run:|
set -uo pipefail
if [ -z "${DOCKERHUB_AUTH:-}" ]; then
echo "::error::docker-variant: DOCKERHUB_AUTH is not set - the image cannot be pushed. It is base64 of 'username:token' for docker.io."
exit 1
fi
if ! creds="$(printf '%s' "$DOCKERHUB_AUTH" | base64 -d 2>/dev/null)"; then
echo "::error::docker-variant: DOCKERHUB_AUTH is not valid base64. Set it with: printf '%s' 'user:token' | base64 -w0"
exit 1
fi
case "$creds" in
*:*) ;;
*) echo "::error::docker-variant: DOCKERHUB_AUTH decodes to something without a ':' - it must be base64 of 'username:token'."; exit 1 ;;
esac
user="${creds%%:*}"
token="${creds#*:}"
if ! printf '%s' "$token" | docker login docker.io -u "$user" --password-stdin; then
echo "::error::docker-variant: DOCKERHUB_AUTH was REJECTED by docker.io (login failed as user '$user'). The token is wrong, expired, or lacks push rights for wekanteam/${{ inputs.image }}."
exit 1
fi
echo "docker-variant: DOCKERHUB_AUTH works for docker.io (user '$user')."
- name:Work out which version to publish
id:v
run:|
set -euo pipefail
version="${{ inputs.version }}"
if [ -z "$version" ]; then
# The newest release of wekan/wekan, asked of GitHub rather than guessed.
echo "::warning::v${{ steps.plan.outputs.version }} is missing ${{ steps.plan.outputs.manual }}, which this workflow cannot build: amd64 is the Meteor build, arm64/win64/mac-arm64 each need their own runner, and the Sandstorm .spk is signed. Run release-all.yml for those."
# The six architectures nobody else builds for, repacked from the PUBLISHED
# amd64 bundle - which is what makes this possible without a Meteor build.
extra-arches:
name:${{ matrix.arch }}
needs:plan
if:${{ needs.plan.outputs.extra != '[]' }}
runs-on:ubuntu-24.04
timeout-minutes:300
strategy:
fail-fast:false
matrix:
include:
# The same table as release-all.yml's build-extra-arches, and it has
# to stay the same: `node_arch` is what the Node.js download is
# called (Node says x86 where we say i386, armv7l where we say
# armhf), `ferretdb_arch` is the asset name in the wekan/FerretDB
# release, and `image` must be a base image that PUBLISHES this
# platform - ubuntu:26.04 does not build 386, debian:trixie does.
echo "::error::SANDSTORM_KEYRING secret is not set. 'spk publish' proves ownership of the WeKan Sandstorm app with the private key from this keyring, so publishing cannot proceed without it. Add the base64 of your ~/.sandstorm-keyring file as the SANDSTORM_KEYRING repository secret (e.g. 'base64 -w0 ~/.sandstorm-keyring')."
exit 1
fi
- name:Download the newest .spk from the WeKan release and name it wekan-<VERSION>.spk
echo "::error::SANDSTORM_KEYRING secret is not set. meteor-spk pack signs the .spk with the WeKan Sandstorm app's private key, which lives in this keyring, so packing cannot proceed without it. Add the base64 of your ~/.sandstorm-keyring file as the SANDSTORM_KEYRING repository secret (e.g. 'base64 -w0 ~/.sandstorm-keyring')."
exit 1
fi
- name:Install Meteor npm dependencies
# PUPPETEER_SKIP_DOWNLOAD: puppeteer is a devDependency used only by tests,
# not by the server, so it never belongs in the packed .spk. Skipping its
# Chromium download (~150 MB) avoids any risk of it bloating the build and
echo "::warning::$SPK is $((SPK_BYTES/1024/1024)) MiB — over Cloudflare's 100 MB upload limit. Upload via a DNS-only host / SSH tunnel to Sandstorm, or trim the bundle further."
fi
ls -la "$SPK"
echo "spk=$SPK" >> "$GITHUB_OUTPUT"
- uses:actions/upload-artifact@v7
with:
name:${{ steps.build.outputs.spk }}
path:${{ steps.build.outputs.spk }}
retention-days:7
- name:Upload the .spk to the newest WeKan release
if ! NODE_META="$(bash /tmp/resolve-node-source.sh "${WEKAN_ARCH}""${NODE_MAJOR}")";then
echo"No Node.js ${NODE_MAJOR}.x for ${WEKAN_ARCH} at nodejs.org, unofficial-builds.nodejs.org or wekan/node-patches, so this image cannot be built for it. Build node-${WEKAN_ARCH} in wekan/node-patches, or drop ${TARGETARCH} from the image's platform list." >&2
exit1
fi
eval"${NODE_META}"
echo"Node.js ${node_full} for ${WEKAN_ARCH}: ${node_from} (${node_url})"
@@ -67,7 +67,7 @@ that by providing one-click installation on various platforms.
- WeKan ® is used in [most countries of the world](https://snapcraft.io/wekan).
- WeKan ® largest user has 30k users using WeKan ® in their company.
- WeKan ® has been [translated](https://app.transifex.com/wekan/) to about 105 languages.
- WeKan ® has been [translated](https://app.transifex.com/wekan/) to 154 languages.
- [Features][features]: WeKan ® has real-time user interface.
- [Platforms](https://wekan.fi/install/): WeKan ® supports many platforms.
WeKan ® is critical part of new platforms Wekan is currently being integrated to.
@@ -103,10 +103,10 @@ By working directly with WeKan ® you get the benefit of active maintenance and
## Getting Started with Development
The default branch uses Meteor 3.5-rc.2 with Node.js 24.x.
The main branch uses Meteor 3.5 with Node.js 24.x.
See [CHANGELOG.md](https://github.com/wekan/wekan/blob/main/CHANGELOG.md) for the latest runtime updates.
To contribute, [create a fork](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#2-create-fork-of-httpsgithubcomwekanwekan-at-github-web-page) and run `./rebuild-wekan.sh` (or `./rebuild-wekan.bat` on Windows) as detailed [here](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#3-select-option-1-to-install-dependencies-and-then-enter). Once you're ready, please test your code and [submit a pull request (PR)](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#7-test).
To contribute, [create a fork](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#2-create-fork-of-httpsgithubcomwekanwekan-at-github-web-page) and run `./build.sh` (or `./build.bat` on Windows) as detailed [here](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#3-install-dependencies-build-wekan-and-run-the-dev-server). Once you're ready, please test your code and [submit a pull request (PR)](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#7-test).
Please refer to the [developer documentation](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Developer-Documentation.md) for more information.
@@ -138,11 +138,17 @@ curl https://install.meteor.com/ | sh
### Building WeKan
The `rebuild-wekan.sh` script guides you through a three-stage process:
The `build.sh` script shows a two-level menu. The top level groups options into categories:
1.**Install dependencies (Option 1)** - Downloads all required Meteor packages and npm modules
2.**Build WeKan (Option 2)** - Compiles the application
3.**Run WeKan (Option 3)** - Starts the development server at http://localhost:4000
```
1) Setup 2) Dev server 3) Tests 4) Docker 5) Tools 6) Quit
```
You pick a category number, then the item number inside it (each submenu also has a `Back` entry). Building from source is a three-stage process:
1.**Setup -> Install dependencies** - Downloads all required Meteor packages and npm modules
2.**Setup -> Build WeKan** - Compiles the application
3.**Dev server -> localhost:3000** - Starts the development server at http://localhost:3000
# Press 1 (Setup) and Enter, then 2 (Build WeKan) and Enter
# Step 3: Run WeKan in development mode
./rebuild-wekan.sh
# Press 3 and Enter
# Step 3: Run WeKan in development mode (Dev server -> localhost:3000)
./build.sh
# Press 2 (Dev server) and Enter, then 1 (localhost:3000) and Enter
```
If a dev server is already running on that port, the **Dev server** options stop it automatically and start a fresh server on the same port.
### WSL Users
WSL users can use Snap Candidate. See [install docs](https://wekan.fi/install/).
The development server will start at http://localhost:4000. Any changes you make to the source code will automatically trigger a rebuild and refresh your browser.
The development server will start at http://localhost:3000. Any changes you make to the source code will automatically trigger a rebuild and refresh your browser.
@@ -10,8 +10,19 @@ because WeKan is NOT Big Tech. WeKan is FLOSS.
- **Report**: Click "New draft security advisory" at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
More info at [GitHub Docs about reporting privately](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately).
- **Proof of Concept (PoC)**: If possible, include a fix or a reproduction script/code.
-**If GitHub does not work**: Please send report to **security@wekan.fi**
- **Optional Email Encryption**: An optional PGP key is available at [security-at-wekan.fi.asc](security-at-wekan.fi.asc).
-DO NOT EMAIL [security@wekan.fi](security-at-wekan.fi.asc), because:
- Email is NOT secure or private.
- Using GitHub directly verifies that:
- You are:
- Saving my time by filling all details at GitHub, so that I can easily click request CVE at GitHub
- A correct GitHub user
- Really reading this SECURITY.md
- Knowing what you are doing
- You are not:
- Someone that tries to waste my time
- Trying to impersonate as some other GitHub user
- Spammer
- Bot
### 2. WeKan Security Team:
@@ -23,30 +34,26 @@ because WeKan is NOT Big Tech. WeKan is FLOSS.
### 3. Post-Release and Public Disclosure:
- Publicity: If you publish blog posts, give talks, or write articles about the
reported vulnerabilities, please send the links to us. We will link them
to your entry in the [Hall of Fame](https://wekan.fi/hall-of-fame/) for additional context.
- Advisories reported at GitHub are listed at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
## How Should Reports Be Formatted?
```
Name: %name
Twitter: %twitter
Bug type: %bugtype
Domain: %domain
Severity: %severity
URL: %url
PoC: %poc
CVSS (optional): %cvss
CWSS (optional): %cwss
```
- DO NOT EMAIL [security@wekan.fi](security-at-wekan.fi.asc), because:
- Email is NOT secure or private.
- Using GitHub directly verifies that:
- You are:
- Saving my time by filling all details at GitHub, so that I can easily click request CVE at GitHub
- A correct GitHub user
- Really reading this SECURITY.md
- Knowing what you are doing
- You are not:
- Someone that tries to waste my time
- Trying to impersonate as some other GitHub user
- Spammer
- Bot
## Who can participate in the program
Anyone who reports a unique security issue in scope and does not disclose it to
a third party before we have patched and updated may be upon their approval
added to the WeKan Hall of Fame https://wekan.fi/hall-of-fame/
a third party before we have patched, and is able to add
"New draft security advisory" at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
# Example (Issue #2674) - add member when card moved TO list, remove member when moved AWAY FROM list:
# python3 api.py addrule BOARDID 'Add on move to Doing''{"activityType":"moveCard","listName":"Doing"}''{"actionType":"addMember","username":"someuser"}'
# python3 api.py addrule BOARDID 'Remove on move from Doing''{"activityType":"moveCard","oldListName":"Doing"}''{"actionType":"removeMember","username":"someuser"}'
Loaded 100 of 1590 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
github-actions[bot]
Lauri Ojansivu
dependabot[bot]
cmartin