#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.
2026-07-17 04:52:30 +03:00
1012 changed files with 198984 additions and 121315 deletions
@@ -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.
@@ -106,7 +106,7 @@ By working directly with WeKan ® you get the benefit of active maintenance and
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-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).
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,7 +138,7 @@ curl https://install.meteor.com/ | sh
### Building WeKan
The `rebuild-wekan.sh` script shows a two-level menu. The top level groups options into categories:
The `build.sh` script shows a two-level menu. The top level groups options into categories:
```
1) Setup 2) Dev server 3) Tests 4) Docker 5) Tools 6) Quit
@@ -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).
@@ -295,7 +386,7 @@ REM ===========================================================================
echo Running ALL tests against ONE WeKan server on http://localhost:3000 - all jobs run IN PARALLEL (concurrently). Needs plenty of RAM (fine on 32 GB).
echo Two WeKan servers are involved:
echo :3000 - the PRECOMPILED .build\bundle run as a plain Node server (Meteor's mongod on :3001, db "meteor")
echo - serves Node E2E + Playwright browser tests. No recompile: your existing build is reused.
echo - serves Node E2E + Playwright browser tests. Built fresh above, so the tests run against the current source.
echo :3100 - Mocha via 'meteor test' (its own .meteor\local-test build; the in-process server-side tests
echo CANNOT run from a production bundle, so this one build is unavoidable).
echo Import regression is a plain Node script (no server, no MongoDB).
@@ -305,9 +396,15 @@ if not errorlevel 1 (
gotoend
)
REM Parity with build.sh: the tests ALWAYS run against a freshly built bundle. The
REM :3000 server runs the precompiled .build\bundle, so a stale bundle means the
REM suite passes or fails on code that is no longer in the working tree.
echo ==^> Running Playwright Chromium, Firefox and WebKit one at a time ^(--workers=1^) on Meteor #1 [Node.js :3000, MongoDB :3001]. Full log: %RUN_LOGDIR%\wekan-alltests-browsers.log
echo Scanning for unawaited Authentication.checkBoardAccess/checkBoardWriteAccess in server\models
node -e "const fs=require('fs'),path=require('path');function walk(d,acc){for(const e of fs.readdirSync(d,{withFileTypes:true})){const fp=path.join(d,e.name);if(e.isDirectory())walk(fp,acc);else if(/\.js$/.test(e.name))acc.push(fp);}return acc;}let found=false;for(const f of walk('server/models',[])){const lines=fs.readFileSync(f,'utf8').split(/\r?\n/);lines.forEach((ln,i)=>{if(/Authentication\.checkBoard(Access|WriteAccess)\(/.test(ln)&&!/await Authentication\.checkBoard/.test(ln)){found=true;console.log(f+':'+(i+1)+': '+ln.trim());}});}console.log(found?'WARNING: Found possible unawaited board auth checks above':'OK: No unawaited board auth checks found');"
gotoend
exit /b 0
REM ===========================================================================
:save_deps
@@ -728,6 +877,29 @@ set "WITH_API=true"
set"RICHER_CARD_COMMENT_EDITOR=false"
exit /b 0
:onelog
REM Set ONELOG to ..\log\<datetime>\wekan-%1.log - the same place every other
REM test run writes, so "the newest test logs" is one directory whichever option
REM produced them. A larger run (EVERYTHING) exports WEKAN_LOGDIR first, and then
REM the whole run stays in that one directory. The Windows equivalent of build.sh's
@@ -335,7 +342,7 @@ function install_playwright_browsers(){
echo" Install Docker, or set WEKAN_PLAYWRIGHT_DOCKER=0 to run all browsers natively."
fi
fi
echo"Done. Run a browser suite from the menu, or: WEKAN_PLAYWRIGHT_DOCKER=1 ./rebuild-wekan.sh"
echo"Done. Run a browser suite from the menu, or: WEKAN_PLAYWRIGHT_DOCKER=1 ./build.sh"
}
# Reset test-results/ ownership when an older WebKit-in-Docker run left it owned
@@ -363,7 +370,7 @@ function pw_failures_of(){
node -e 'const fs=require("fs");let r;try{r=JSON.parse(fs.readFileSync(process.argv[1],"utf8"))}catch(e){process.exit(0)}const label=process.argv[2]||"";const out=[];function walk(su,ti){const t=[...ti,su.title].filter(Boolean);for(const s of su.suites||[])walk(s,t);for(const sp of su.specs||[]){if(sp.ok)continue;const loc=sp.file?`${sp.file}:${sp.line}`:"";out.push(`[${label}] ${loc} › ${[...t,sp.title].join(" › ")}`);}}for(const s of r.suites||[])walk(s,[]);out.forEach(l=>console.log(l));'"$1""$2"
}
# Run one Playwright browser project for the "Run ALL tests" flow.
# Run one Playwright browser project for the whole-suite flows.
# Writes test-results/all-tests-<browser>.json and returns playwright's exit code.
# On Linux arm64 every browser goes through Docker (see browser_needs_docker).
function run_pw_all_browser(){
@@ -481,12 +488,24 @@ function run_playwright_parallel(){
}
# Run one Playwright browser project interactively (single-browser menu items).
# one_log <name> — a fresh ../log/<datetime>/ for a single test option, and the
# path of the file to tee into. Every option in the Tests menu writes there, so
# "the newest test logs" is one directory whichever option produced them. When a
# larger run is driving this (EVERYTHING), WEKAN_LOGDIR is already set and is used
echo"No .build/bundle or node_modules directory found - building the WeKan bundle first (meteor build .build --directory)."
build_wekan
# Tests ALWAYS run against a freshly built bundle. The :3000 test server runs
# the precompiled .build/bundle, so a stale bundle means the suite passes or
# fails on code that is no longer in the working tree - the one thing a test
# run must never do. This used to build only when .build/bundle was missing,
# which is exactly the case where the bundle is present but old.
echo"==> Deleting .build and building WeKan before running the tests (always, so the tests run against the current source)."
build_wekan
if[ ! -d .build/bundle ];then
echo"ERROR: .build/bundle is missing after building. Aborting the test run."
return1
fi
if["$RUN_MODE"= parallel ];then
echo"Running ALL tests against ONE WeKan server on http://localhost:3000 - all jobs run IN PARALLEL (concurrently). Needs plenty of RAM (fine on 32 GB)."
@@ -534,7 +560,7 @@ function run_all_tests(){
fi
echo"Two WeKan servers are involved (they do NOT run tests in parallel unless you chose parallel):"
echo" :3000 - the PRECOMPILED .build/bundle run as a plain Node server (Meteor's mongod on :3001)"
echo" - serves Node E2E + Playwright browser tests. No recompile: your existing build is reused."
echo" - serves Node E2E + Playwright browser tests. Built fresh above, so the tests run against the current source."
echo" :3100 - Mocha via 'meteor test' (its own .meteor/local-test build; the in-process server-side tests"
echo" CANNOT run from a production bundle, so this one build is unavoidable)."
echo" Import regression is a plain Node script (no server, no MongoDB)."
# Persist it, so the next boot does not go back to failing builds.
localconf=/etc/sysctl.d/60-wekan-inotify.conf
if ! "${SUDO[@]}" sh -c "printf '%s\n' '# Raised by WeKan build.sh: Meteor watches one inotify watch per directory.' 'fs.inotify.max_user_watches=$want' > '$conf'" 2>/dev/null;then
echo" Applied for this boot only - could not write $conf."
fi
# max_user_instances is the other half of the same limit family: each watcher
# process needs an instance, and editors + Meteor + chokidar add up. Only
# raised when it is at the low stock default, and never fatal.
"Update git|Update git: fetch + rebase onto origin, fix CHANGELOG hashes, show status";;
"Dev server")
choose "Dev server"\
"localhost:3000|Run Meteor for dev on http://localhost:3000"\
@@ -1118,11 +1485,13 @@ while [ -z "$opt" ]; do
"CURRENT-IP:3000|Run Meteor for dev on http://CURRENT-IP-ADDRESS:3000"\
"CURRENT-IP:3000 + MONGO_URL 27019|Run Meteor for dev on http://CURRENT-IP-ADDRESS:3000 with MONGO_URL=mongodb://127.0.0.1:27019/wekan"\
"CUSTOM-IP:PORT|Run Meteor for dev on http://CUSTOM-IP-ADDRESS:PORT"\
"CUSTOM PORT + SUBDOMAIN|Run Meteor for dev on a custom port and ROOT_URL host (asks)"\
"Kill all dev servers|Kill all dev servers (free ports 3000/3001/3100/3101/4000/4001/8080)";;
"Tests")
choose "Tests"\
"ALL tests, parallel|Run ALL tests in parallel on http://localhost:3000 (start server, jobs run concurrently, progress + summary)"\
"ALL tests, sequential|Run ALL tests sequentially on http://localhost:3000 (start server, one job at a time, progress + summary)"\
"EVERYTHING (sequential): WeKan tests + all databases + FerretDB tests|Run EVERYTHING sequentially: WeKan's own tests, then the database conformance run for every database with a Docker image for this CPU, then all of FerretDB's own tests (unit, vet, integration) - one stage at a time, all logs in ../log/<datetime>/"\
"WeKan's own tests only, parallel|Run WeKan's own tests in parallel on http://localhost:3000: Mocha, the node unit suites, import regression, node E2E and all three browsers, concurrently. No database conformance and no FerretDB tests - logs in ../log/<datetime>/"\
"WeKan's own tests only, sequential|Run WeKan's own tests sequentially on http://localhost:3000: Mocha, the node unit suites, import regression, node E2E and all three browsers, one job at a time. No database conformance and no FerretDB tests - logs in ../log/<datetime>/"\
"Mocha (server-side)|Test Mocha unit + security + API-logic tests (server-side only, no browser)"\
"Import regression|Test import regression (tests/wekanCreator.import.test.js, fast, no server)"\
"Count tests by category|Count amount of tests by category";;
"Count tests by category|Count amount of tests by category"\
"Run all FerretDB tests - SEQUENTIAL|Run all FerretDB tests - SEQUENTIAL: unit, vet and the integration suite of the FerretDB subdirectory of this repo, one at a time, logs in ../log/<datetime>/"\
"All databases (sequential)|Test all databases that have a Docker image for this CPU, SEQUENTIALLY: build newest FerretDB v1 from source, then run every FerretDB v1 query type against each database and compare that they all answer the same (results in ../log/<datetime>/)";;
"Tools")
choose "Tools"\
"Save Meteor deps list|Save Meteor dependency chain to ../meteor-deps.txt"\
@@ -1211,6 +1582,11 @@ for _once in 1; do
break
;;
"Update git: fetch + rebase onto origin, fix CHANGELOG hashes, show status")
DEFAULT_METEOR_REACTIVITY_ORDER="changeStreams,oplog,polling"DDP_TRANSPORT=uws DEBUG=trueWRITABLE_PATH=.. WITH_API=trueRICHER_CARD_COMMENT_EDITOR=falseROOT_URL="$DEV_ROOT_URL" meteor run --port "$DEV_PORT" 2>&1| tee ../log/wekan-log.log
"Run Meteor for dev on http://CUSTOM-IP-ADDRESS:PORT")
ensure_rspack_public_dirs
ip address
@@ -1316,34 +1706,39 @@ for _once in 1; do
break
;;
"Run ALL tests in parallel on http://localhost:3000 (start server, jobs run concurrently, progress + summary)")
"Run WeKan's own tests in parallel on http://localhost:3000: Mocha, the node unit suites, import regression, node E2E and all three browsers, concurrently. No database conformance and no FerretDB tests - logs in ../log/<datetime>/")
run_all_tests parallel
break
;;
"Run ALL tests sequentially on http://localhost:3000 (start server, one job at a time, progress + summary)")
"Run WeKan's own tests sequentially on http://localhost:3000: Mocha, the node unit suites, import regression, node E2E and all three browsers, one job at a time. No database conformance and no FerretDB tests - logs in ../log/<datetime>/")
run_all_tests sequential
break
;;
"Test Mocha unit + security + API-logic tests (server-side only, no browser)")
LOG="$(one_log mocha)"
echo"Running Mocha tests: meteor test --once --driver-package meteortesting:mocha --port 3100"
echo"(server-side unit/security/API-logic tests; browser/client tests are covered by Playwright options)"
meteor test --once --driver-package meteortesting:mocha --port 3100
echo"Log: $LOG"
meteor test --once --driver-package meteortesting:mocha --port 3100 2>&1| tee "$LOG"
break
;;
"Test import regression (tests/wekanCreator.import.test.js, fast, no server)")
echo"Running import regression test (node, no server needed)."
node tests/wekanCreator.import.test.js
LOG="$(one_log import)"
echo"Running import regression test (node, no server needed). Log: $LOG"
node tests/wekanCreator.import.test.js 2>&1| tee "$LOG"
echo"OK: Rule @typescript-eslint/no-floating-promises is configured in .eslintrc.json"
else
echo"WARNING: Rule @typescript-eslint/no-floating-promises is NOT configured in .eslintrc.json"
echo"Suggested: add @typescript-eslint/eslint-plugin and set '@typescript-eslint/no-floating-promises': 'error'"
fi
echo"Quick note: @typescript-eslint/no-floating-promises is a type-aware rule and may require further parser/project setup for full enforcement in all files."
echo
echo"Scanning for unawaited Authentication.checkBoardAccess/checkBoardWriteAccess in server/models"
echo"OK: Rule @typescript-eslint/no-floating-promises is configured in .eslintrc.json"
else
echo"WARNING: Rule @typescript-eslint/no-floating-promises is NOT configured in .eslintrc.json"
echo"Suggested: add @typescript-eslint/eslint-plugin and set '@typescript-eslint/no-floating-promises': 'error'"
fi
echo"Quick note: @typescript-eslint/no-floating-promises is a type-aware rule and may require further parser/project setup for full enforcement in all files."
echo
echo"Scanning for unawaited Authentication.checkBoardAccess/checkBoardWriteAccess in server/models"
if rg -n "$AUTH_CALL_PATTERN" server/models | rg -v "$AUTH_AWAIT_PATTERN";then
echo"WARNING: Found possible unawaited board auth checks above"
else
echo"OK: No unawaited board auth checks found"
fi
else
if grep -RInE "$AUTH_CALL_PATTERN" server/models | grep -vE "$AUTH_AWAIT_PATTERN";then
echo"WARNING: Found possible unawaited board auth checks above"
else
echo"OK: No unawaited board auth checks found"
fi
fi
} 2>&1| tee "$LOG"
break
;;
@@ -1439,78 +1838,105 @@ for _once in 1; do
break
;;
"Run all FerretDB tests - SEQUENTIAL: unit, vet and the integration suite of the FerretDB subdirectory of this repo, one at a time, logs in ../log/<datetime>/")
# FerretDB is a subdirectory of this repo; releases/db-conformance.sh clones it
# when it is not there, and its own build.sh installs Go and the modules.
if[ ! -x FerretDB/build.sh ];then
echo"FerretDB/build.sh is missing. Clone it first:"
echo" git clone git@github.com:wekan/FerretDB"
echo"(or run Tests -> All databases, which clones it before building.)"
else
(cd FerretDB && ./build.sh test-all )
fi
;;
"Run EVERYTHING sequentially: WeKan's own tests, then the database conformance run for every database with a Docker image for this CPU, then all of FerretDB's own tests (unit, vet, integration) - one stage at a time, all logs in ../log/<datetime>/")
run_everything
;;
"Test all databases that have a Docker image for this CPU, SEQUENTIALLY: build newest FerretDB v1 from source, then run every FerretDB v1 query type against each database and compare that they all answer the same (results in ../log/<datetime>/)")
# Everything this needs - the FerretDB source, the Go toolchain, the module
# dependencies - is fetched or built by the script itself; see the note at its
# top for why it is sequential and why SAP HANA is opt-in.
Loaded 100 of 1012 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]